For some types of high-performance infrastructure software like database engines, there really isn't a better alternative unfortunately. While there are other non-GC languages like C and Rust, equivalent software requires significantly more lines of code due reduced expressiveness, sometimes with a performance impact, and there are some types of code safety that are difficult to enforce in those languages.
Because C++ is so expressive in a systems programming context and is rapidly adding valuable features, it makes it difficult for other languages to catch up to the point where there is a direct architectural translation from the latest version of C++ to some other language. I know quite a few shops that actively pull their code bases forward when a new C++ version lands, which is usually pretty painless, to take advantage of new features/safety and added tidiness.
My problem with C++ is that writing "best practices C++" in 2019 is so different from writing "best practices C++" in 2011 that it may as well be a different language. And if it's going to be a different language, I'm going to prefer a language and toolchain that started from a cleaner slate, such as Rust. For example: C++11 got rvalue and move semantics and that was pretty awesome, but it took me a ton of mental overhead to cleanly reason about interfaces where I wanted to support move semantics. I think Rust's borrowing semantics clean up a lot of C++'s memory ownership/management issues into a simpler model that I just don't have to think as hard about.
I sometimes still use C++ because it's easier to work with existing code. For example, if I am prototyping something that requires hitting OS API's, C++ is often the best combination of easily calling into the APIs while still getting modern conveniences.
I wish I could like D but I just don't, some of the decisions it made I think were mistakes.
Go's FFI story is unfortunate, and it seems too narrow in target usage anyway.
C gets a lot of rose-tinted love, but I'd never chose it over modern C++.
And... well that's sort of it, isn't it? What else is there in this area?
Like what? D is everything I ever wanted C++ to be. The only reason I feel compelled to learn Rust is peer pressure, but if it were up to me, D would be the language everyone is getting excited about instead.
I get a general impression of D being in just too weird of a space. It's occupying a zone somewhere between C/C++ & Java/C#, and I'm not sure that's a place I ever want to be. I'd rather just use Java/C# if I need D's feature set, and if I don't I don't want to deal with the headaches that result from trying to avoid them (or use -betterC mode which seems to just be what D should have been from the start)
I mean, I do use the GC, it's just that it's never been something that I care about, just like I don't care how exactly new and delete are implemented in C++ (are they just malloc and free wrappers? Eh, who cares.)
1) Because interop with non-GC (aka, C) code is terrible from a GC'd language. D is better here than other GC'd languages as you can still build smart pointers via RAII, but it still sucks. It's a significant mindset shift in random spots in your code.
2) Custom allocators can be hugely important in achieving certain optimizations or runtime behaviors. This can either be for just performance reasons or in some cases are mandatory for correctness such as if it's a real-time thread.
It's partially why Rust and modern C++ are getting a lot of attention in that space, as they provide a lot of higher-level niceties but don't require the overhead of a GC.