No memory safety in D though. That's a pretty big deal for those of us coming from high-level languages who are not used to dealing with such issues.
I can deal with a fussy compiler that makes me write code in a certain way. But a langauge that compiles fine then segfaults or worse at runtime is far more trouble than it's worth (and requires me to make a big upfront time investment before I can start writing production ready code)
Not true. Even ignoring the GC we have compiler checked semantics for an increasingly large subset of features, and the language has had ways of managing code that is safe, unsafe, or trusted for years and years now.
As a newly minted employee of the D foundation, I am aiming to work to expand the memory safety features D has.
There was a proposal to do just that in our DIP (D improvement proposal) pipeline that nearly made it but it (probably correctly) received enormous backlash.
However, if you use @safe (that's the attribute) the compiler will hard-error if you call any code that you use that isn't explicitly also either @safe or @trusted.
There is also DIP1000 and DIP1021 which both loosen @safe semantics to perform semantic analysis to allow safe memory behaviour (A small borrow checker in effect, this will hopefully be bigger soon).
Try accessing a struct property that isn't in the declaration, or accessing a value after it has been freed (out of scope). You'll get a compile error.
D has lots of memory safety features. It is not the same set of features as Rust. It's wildly incorrect to suggest that Rust has a monopoly on memory safety.
I can deal with a fussy compiler that makes me write code in a certain way. But a langauge that compiles fine then segfaults or worse at runtime is far more trouble than it's worth (and requires me to make a big upfront time investment before I can start writing production ready code)