> It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D).
I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never caught on - it wasn't that people weren't interested in a better C++ - it's that D was unsuitable for a lot of scenarios C++ was used because they decided to include GC in the language and it needed to have a runtime that supports it. This put D more in the C# alternative camp than C++ alternative, it was harder to port (I don't know if D still has a working iOS or Android ports, it didn't have them a few years ago when I last checked). And as a C# alternative it's strait out worse across the board (C# has quite string native interop so D doesn't really win much, tooling ecosystem and support is levels above).
If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction. The problem is that's a huge undertaking and I don't see who would be motivated to fund such a thing.
Rust exists because it solves a real problem and places like this BT stack seem like perfect use case due to security aspects - but the security aspect also adds a lot of complexity and there are domains that really don't care about it - they just want sane modules, modern package management and fast compile times.
Go has it's own niche in the application/network programming.
Seems like modern system languages get purpose built and general purpose ones are higher up the stack.
> If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction.
This happened recently (in D timeframe) and is still a hack that basically creates a different language that's a subset of D - which is the dirtiest way to fix an initial design mistake. If D came out as betterc from the go I guarantee you the adoption would have been much better - this way you're stuck with legacy decisions of a language that was never really that popular to begin with (unlike C - C++ story).
Also back when it launched LLVM wasn't really a thing (GCC was probably the closest thing to having a portable backend but it wasn't nearly as clear cut especially with the licensing and all that anti-extensibility attitude), and D having it's own custom backend was also an issue.
I applaud the effort but at this point I think it will never get mainstream popularity like Rust. I'm sure it's useful to people but it had it's time in the spotlight, I don't see how they get the momentum shift.
I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never caught on - it wasn't that people weren't interested in a better C++ - it's that D was unsuitable for a lot of scenarios C++ was used because they decided to include GC in the language and it needed to have a runtime that supports it. This put D more in the C# alternative camp than C++ alternative, it was harder to port (I don't know if D still has a working iOS or Android ports, it didn't have them a few years ago when I last checked). And as a C# alternative it's strait out worse across the board (C# has quite string native interop so D doesn't really win much, tooling ecosystem and support is levels above).
If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction. The problem is that's a huge undertaking and I don't see who would be motivated to fund such a thing.
Rust exists because it solves a real problem and places like this BT stack seem like perfect use case due to security aspects - but the security aspect also adds a lot of complexity and there are domains that really don't care about it - they just want sane modules, modern package management and fast compile times.
Go has it's own niche in the application/network programming.
Seems like modern system languages get purpose built and general purpose ones are higher up the stack.