[quicknir]

If you can tolerate GC then like 20 languages (as or less obscure than D) enter the conversation. If you can tolerate GC and the performance implications that go with it, then using C or C++ is rarely a good choice to begin with (well, other than legacy, which is a valid and common reason).

[mhh__]

D isn't defined by performance or memory management, however. There are many D features which are just blisteringly professional in how they approach software development: Using D is conducive to writing good software.

Metaprogramming, for example, in D is obvious and almost fun. The compile times are ridiculous compared to C++, i.e. I can build the main D compiler in three different configurations in about 5sec on my machine.

[quicknir]

I'm not saying that D is defined by that. I'm simply saying that if you're comparing to C or C++, you are talking about use cases that are defined by performance and/or memory management (or else, they are being used for legacy reasons). If you have a green field project that doesn't have massive performance concerns, and doesn't have to be specifically in C or C++ for other reasons (toolchain availability, available developer resources, etc), you probably aren't using C or C++.

Some people would argue that you can use D for equally high performance things to C++, and make sure you use the GC very selectively, etc. However, you don't appear to be making that argument. If you aren't, then there's just no real point comparing C++ and D. If you don't have any of those requirements, and you are ok with obscurity, you have much stiffer competition from many other languages like Haskell, Kotlin, etc.

[WalterBright]

There are people who specifically use D for writing high performance applications. They find it faster than C++ for a rather subtle reason - D code is more plastic, meaning it is easier to refactor D code trying out different algorithms looking for a faster one.

[quicknir]

I'm sure these people exist but they're the exception rather than the rule. The two biggest industries in SG14, the C++ low latency study group, are games and HFT. In both these areas, D penetration is pretty much zero. And in HFT at least while many features would be nice (especially reflection), I can't imagine it would be anything but a performance hit. Just the fact that the best D implementation for performance is llvm based, and most people do not find that llvm produces assembly as good as gcc or icc, is already an instant global hit.

[WalterBright]

D reflection is at compile time, not runtime, so no performance hit.

[quicknir]

I didn't intend to imply otherwise but I see my wording was unclear. I meant that D generally would be a hit, though it's only really speculation either way.

[GoblinSlayer]

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9.1-...

[mhh__]

LLVM and GCC are so close together these days that it makes almost no difference practically, and when it does you should start optimizing based around your code not your compiler.

Root of all evil etc. etc.

[quicknir]

Dude I mean the context in which I'm discussing this is a large organization operating on timescales shorter than microseconds with numerous people involved in optimizing every single part of the pipeline. We are waaaaaaaaaaay past the point of "premature" optimization. This is just optimization, and optimization where a few percent difference between compilers is huge.

Your comments read like you're explaining optimization to a beginner, it's a bit bad faith tbh.

[pjmlp]

Both of which use their own C++ subset, while ignoring the standard library.

So even C++ isn't good enough for them.

Yet a few vocal anti-C++ devs in the game world, from Insiomatic Games are now at Unity driving HPC# efforts, so there's that.

[quicknir]

HFT doesn't subset C++ nor does it ignore the standard library. Given you're totally wrong about one I'm not inclined to believe you on the other, and I have an examples from the standard library used in game dev eg atomics.

[scythe]

Ultimately, though, this is the real tragedy of D. It started as a C clone, and continues to be named like it's a C clone, but it is no longer a C clone. It is a general-purpose memory-aware compiled programming language inspired by C++, but it is pretty different by now! People expecting a C clone miss what else it has to offer.

(Can it be a C replacement? Sure, but so can Rust/Swift/Go/etc)

[riffraff]

I don't believe it ever was a C clone. I remember it always presented as a C _successor_, like C++, but in a different direction.

[makapuf]

Go (and some others, swift surely) cannot be used as a C replacement since they need a runtime.

[pjmlp]

Just like C does for calling into main(), doing floating point emulation if CPU not available, calling library initializers (common C extension), handling VLA allocations.

Just because it is tiny does not make it inexistent.

Then there is the whole POSIX, which is kind of runtime that wasn't made part of ISO C, but follows it everywhere.

[makapuf]

It's not necessarily tiny but it's optional (besides main() ). Linux kernel, baremetal embedded does not use this.

[pjmlp]

Linux kernel surely used it during the time they had VLAs in, they are now mostly removed thanks to Google efforts reducing memory exploits on the Linux kernel.

One just links another implementation, just like printf() vs printk().

[GoblinSlayer]

libc.so.6 is about 2MB.