I think that people hyperoptimize for no reason though. How many applications are there that require no GC? I feel like you can write the no-gc code in Rust and then just use it from the C ABI from any GC language.

Similar with malloc in C / new in C++, especially for short-living, repeating, in hot path. And then you hear: avoid allocations, use constant-size buffers or memory pools. Avoid spawning threads, use thread pools.

I don't think so. People love to see how far they can go in some aspect sometimes. If I had the same amount of free time 5 years ago, I'd have tried the same thing with Go, because I like the language, and love the act of programming and seeing things.

Also, I also agree that people optimize without proper testing and profiling. If there's a real bottleneck here, trying to optimize it is the right call. OTOH, optimizing without profiling opens a lot of unnecessary cans.

Lastly, Go doesn't like constant allocation and deallocation of variables, that's true, but I believe knowing this and optimizing hot-loops for that goes a very long way as a start.

That observation checks out. About a decade ago, one of my former coworkers areas of interests was making Java applications and frameworks that didn't use the any additional heap beyond app initialization. This was apparently for embedded/low power devices. It was neat to hear about as a C++ dev, but I'm not sure how much of a business or technical advantage it had beyond that.

Zero allocation is also a thing in rust. What you can learn is to reduce allocations in your critical paths.

Anti GC folks forget that these workarounds are only required in GC languages that don't offer explicit language features for stack and native heap allocations, like Cedar, Modula-3, all Oberon variants, C#, F#, D, Swift,..

Like everything else in Go, its designers have decided to ignore learnings in GC systems languages.

The end state of inappropriate use of garbage collected languages.

Go/GC are mostly fine for medium frequency medium scale mid stack problems.

It’s bad for high frequency computing. It’s bad for very small targets, for very large targets, and by association software that lives at the very bottom of the stack.

Go is a high efficiency framework for writing mid sized servers, not a systems language. The runtimes hard opinions and closed interface are the reason for this enclosing definition and the GC is one part of that.

Maybe. Go code is designed to be readable and stable. My guess is that most Go code is running fine with garbage collection. There are always edge cases and then just choose another language.