BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM.

The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

But as a language doesn't betterC provides lots more useful features than C (the module system, meta-programming (imagine C with generics), scope() and many other useful things) that make it really a better language than C while still keeping C interop. I agree that it is in an awkward spot though -- and would have benefited from being it's own separate programming language. It would have been a killer feature if it could also compile standard C at the same time!

It would have been a killer feature if in betterC mode it could compile standard C programs and be a drop-in replacement for GCC/Clang :-).

You might find Atila's project dpp interesting: https://github.com/atilaneves/dpp

Zig is doing this, an interesting feature.

I don't disagree with anything you say :-) but it bears pointing out that D already lets you call into C libraries without glue.

This means you can write C and use the entire wide C ecosystem, but use D for the parts of the program which make sense in D, painlessly.

> if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

If you can be bothered to use betterC then that's probably not true. To be argumentative, C is fucking horrible. BetterC still gives you a decent chunk of D's features - templates alone make it worth the switch. No more macro spam for example.

Can you imagine how much boilerplate you'd have to write to mimic this: https://d.godbolt.org/z/3XNBFW

I wish betterC had associative arrays :(