Balanced GC: A Copying Garbage Collector for Golang - Yifei Zhang

[@felix.geisendoerfer]

Very interesting work. Was the code for this GC published?

[@user-ov5nd1fb7s]

I don't think this is a good solution. Fix your Go code, instead of trying to develop complex systems of multiple garbage collectors.

[@nikolaevkirill]

The problem appears at scale. If you have a load on an API that allocates temporary objects at a middleware stage, there's no "fix your go code" that can be done. It's an optimization that pays off if you have enough services that save you 4%. I like it that they used existing go code instead of proposing an expensive rewrite in some lower-level language.

[@user-ov5nd1fb7s]

@@nikolaevkirill it's not a viable solution to have thousands of idiots allocating memory everywhere and then a few people trying to fix these monstrosities. And btw, these are the same people that advocate for these dogmas that produce code like this. And most of them don't see the problem. It's a sad state of affairs. And people all around you will claim performance doesn't matter. Computers are so fast and have so much memory. Speed of development is most important. And all the rest of these stupid ideas. Performance is always important. People should learn to write fast code out of the box. What should have happened, instead of making another GC, all devs that wrote this stupid code should have been fired and returned all the money they took for salaries.

[@nikolaevkirill]

​@@user-ov5nd1fb7s If you need to parse input string and transform it to a structured output, you have to use memory. With the most minimalistic approach when each piece of memory is actually used, you still end up allocating memory. If the service is designed to work under high load, you end up allocating memory per each interaction (user request or event). Go as any other GC language can manage the memory for you, but the cost is allocating memory per object. I don't believe this has anything to do with what people think or what code they produce. It's just GC has it's own limits, that's why manual memory management is considered the only alternative. Usually to do so people suggest to use rust/c, but here we can see a pretty interesting take on manual memory management within go. Again, I think this is not a skill issue, as manual memory management will always be superior to GC.