I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are using C++ over Go. In my mind it’s a half-speed language. I’m also very put off by Rob Pike’s “Look, we replaced C++!” attitude when he somehow doesn’t seem to grok zero-cost abstractions. C++ has plenty of issues, but it doesn’t have GC and it goes further, providing standard allocators: both PMR for convenience and most use cases, and statically, for truly zero runtime cost.

Rob pike said they intended to replace c++, that didn't happen to his own accord.

Right. It seems like they set out to replace some misunderstood or outdated view of C++. They’ve clearly had success, but it’s no C++ successor.

I haven't seen Go's hit larger than 25% in our production.

Usually that means we have to keep average CPU load below 70%. (Since GC cames once in several minutes, it is usually not seen in per-minute averages)

That is ok for us, since Go significantly boosts development compared to stricter language.

It is "marketplace" thing, so we have enough money to spend on additional 50% servers compared to "extremely efficient No-GC" solutions.

It all depends.

> The idea that a GC is somehow a hindrance to language adoption doesn't make any sense to me at all. Doesn't stop people loving Go.

I meant as a systems programming language. To replace C or C++ or such.

Yeah fair enough.

Though I have to say - are there really that many scenarios in 2022 where a GC is unacceptable? Hard real time systems, sure. Tight loops in a high performance game engine - I can imagine. But... web servers? Graphical apps? Daemons?

I think there is a sweet spot for natively compiled languages, with garbage collectors, but also let you have a tight control of memory layout. There's really not many in this category.

Anyone who was forced to write Java code on Android at some point suffered extremely painful performance issues due to the Garbage Collector.

I never had any problems with manual memory management, it can be done properly and safely without a GC, so for me the presence of a GC in a programming language is a net loss.

> Though I have to say - are there really that many scenarios in 2022 where a GC is unacceptable?

There are tons of C++ and C programmers who would find the introduction of a GC into their programs to be unacceptable, yes. That's why D keeps losing this battle.

Right, I guess I'm veering off topic and going into 'D in its own merits' rather than 'D as a C/C++ replacement'. Fast python vs convenient C.

> Though I have to say - are there really that many scenarios in 2022 where a GC is unacceptable?

There are more systems programming jobs (where GC is not usable) today than there was years ago. The percentage of all programming jobs that they make up is smaller, but the absolute number is bigger: https://www.toptal.com/c/after-all-these-years-the-world-is-...

Not saying the original poster is this type of person, but I actually work with a lot of recent bootcamp grads and you be surprised how many think C is totally not used anymore. To many of them, the whole world is written in python and JavaScript.