Sure, that's what makes C++ one of the worst PLs. Just break for every decade or so to fix things for good.
What's D been doing meanwhile? D community and the authors know its short comings for over a decade now, which are the reasons for its lack of adoption even in the open source world. Most of the D code is yet to be written, tbh. If D can't break stuff to fix the mistakes with defaults, why was all the hatred marketing towards C++? Was it a failed strategy trying to kill C++, so let's just surrender to it via core.stdcpp?
PS: Yes, D has the best interop with C++ in the world and even better interop with C as the memory model is same!
Good talk Ali. All these talks are for people who create small, standalone programs and tools.
For history, I hated D back in 2006/7. But post Andrei joining D was fantastic. It was very easy to jump into D's standard library and understand it's inner workings. Over those years I created and maintained apps, services and microservices written in D. It was pleasure writing programs in D. Its compile time features make it pleasurable to write algorithms and refactor at ease.
But it was horribly painful to debug production issues. GC crashes day in and day out. Missing ecosystem of libraries and tools. vibe-d was unstable, so we had to create our own HTTP2 library. There's very little tooling to figure out what's going on when things go wrong. Templates in D are awesome for compile time, but it's the opposite case with GC and runtime.
D's built in attributes are like family members who don't like each other but are trying to live in a single room. What else do you expect of such programs? You try to observe/log from your transport layer, but when you get deep into BetterC layer, you can't use loggers as they use GC. OK, write your own nogc logger, but that doesn't work well with default logger. The cycle repeats for every single attribute and every single behavior during runtime. It's just a mess.
Until I read the source code of Rust standard library a year or so ago. It was not as pleasant as D, but it was easy to understand and pickup the language.
I switched jobs a year ago and instructed our teams to experiment with Rust even though I had decades of expertise with C++ and a decade with D. The immediate benefit we saw was Rust's opinionated error handling, which proved to be the right approach to most of common programming mistakes. We started using Tokio and all praises to it. No going back!
Personally, I can ask my teams to use D when it has all the sane defaults of Rust and a good ecosystem. Otherwise it is way too expensive to maintain as there's no benefit of portability as well. We now write all code in Rust and ship it across different platforms seamlessly, including Android, iOS, Windows, Linux and macOS. One language and code to rule them all.
Few recommendations to @WalterBright as he is on HN.
Personal recommendations:
1. You created D because you felt the pain of the C++ programmers. Appreciate it and thank you for that. Over the years you've built up "the curse of knowledge bias" with D. Start using D as a new programmer to the language and the ecosystem. Come out of your MicroEMACS shell and use a modern editor/IDE like VSCode and see how lacking the tooling is. WebFreak has done an amazing job with code-d[1]. But it is in no competition to Rust's IDE support.
2. Use all the features of D in a non-compiler, long running, real life ML/microservices project. You will see the pains of GC.
3. Unit testing != assert
4. Scoped exit != RAII
General recommendation: SWITCH TO SANE DEFAULTS!
1. @safe by default. Allow hiding all C interfaces under @unsafe. Retire once for all @trusted/@system. @safe => @unsafe
2. BetterC by default
3. Immutable/const by default
4. @nogc by default. That is @nogc => @gc
5. Rust like opinionated error handling and remove exceptions. At least make nothrow default and introduce throw.
7. Reduce the attribute bloat: https://dlang.org/spec/attribute.html
Feedback to D community from learnings in Rust community:
1. Learn to work on team projects to improve D ecosystem instead of shitty ideas about "Signatures", etc.
2. DIP1000 for safety is open for like 7 years and has no conclusion and still NOBODY cares. Just saying that D is alive and community is awesome are just a jokes. D has lost it's "brains" and there are just a few hanging around at the moment, unfortunately.
3. There's not even a standard dfmt template for Phobos/Druntime. Bring one and you will possibly gain contributors.
Yes, Rust code doesn't look elegant with littered angle brackets and &' across the code base, no templates, makes programmers life difficult, etc. But we can live with all that and still have peaceful nights (and weekends) without calls from production support, when compared to downtimes due to half baked features in D (I didn't mention about @live in preview yet).
In the end, a language is not great/usable by itself (that's why there's no money in writing programming languages), but by it's rich ecosystems and community. D was created for novice programmers originally (as programmer's language), but the idea is long dead. It is a mess at this point. You need to be a seasoned/experienced programmer to even maintain a large code base. Using D itself is a code smell, IMHO.
Sorry for venting out, I was the one who recommended D at my past workplace and I was just frustrated my decision and it's consequences.
> 1. Learn to work on team projects to improve D ecosystem
Criticism is right on point.
I believe if you use D in a team, you need to be extra careful to keep the same subset, and also using D is way nicer if you avoid unproven features.
To be happy with D you need the utmost restraint with features, and yes unittest helps a lot.
> GC crashes day in and day out.
Sounds like the old destruction ordering problem, and that can be solved by detecting accidental correctness. The problem is destructors called from GC. If you use the GC, you will probably need deterministic destruction in production code, and there are of course ways to achieve it systematically.
> Using D itself is a code smell, IMHO.
I don't see it as more risky than any other language. Especially as the langage is slow-moving, and you don't have to re-learn every 3 years.
Large codebase in any language becomes unwieldly. Let's reflect on your next decade of Rust once it's achieved :)
