> Zig is truly compatible with C and will compile C code directly, since its compiler is actually written in C++.
I assume this was intended to say something else?
> Here's the brutal truth: I can't find anyone under the age of 41 in my field to say a single positive thing about D
IIRC the presence of the GC in D was (is?) its Achilles heel. Because the GC is infectious. As soon as your dependency needs it (and IIRC even parts of the standard library did/do), it becomes painful if not impossible for you to avoid it. Had it not had this fatal flaw, D might've fared much better.
> Because the GC is infectious. As soon as your dependency needs it (and IIRC even parts of the standard library did/do), it becomes painful if not impossible for you to avoid it.
Isn't this the same for Nim? The standard library doesn't provide pure functions for parsing strings, it provides functions which generate exceptions. Exceptions use the heap, it's hard to get programs to compile with the garbage collector turned off, so everyone just recommends using ARC.
I don't know Nim, maybe it's the same? If it is I guess that would probably also explain why Nim hasn't replaced C or C++ either.
Though do note that (academic discussions notwithstanding) refcounting is not what people usually mean by GC in these contexts. Having to put up with refcounting is one thing (people already do it manually anyway), but having to put up with a generational or other complex GC is quite something else.
The issue with D is it still feels unpolished. Every time I try it - which is maybe once a year or so - the experience still feels weird and edge casey.
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. But go has slick tooling.
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.
> 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.
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.
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.
I assume this was intended to say something else?
> Here's the brutal truth: I can't find anyone under the age of 41 in my field to say a single positive thing about D
IIRC the presence of the GC in D was (is?) its Achilles heel. Because the GC is infectious. As soon as your dependency needs it (and IIRC even parts of the standard library did/do), it becomes painful if not impossible for you to avoid it. Had it not had this fatal flaw, D might've fared much better.