On Monday, 26 September 2022 at 12:41:07 UTC, jmh530 wrote:
> On Monday, 26 September 2022 at 08:32:27 UTC, Siarhei Siamashka wrote:
> [snip]
C++ and D are actually radically different. Older versions of the C++
standard are still supported via the '-std=c++98' or '-std=c++17' option
in GCC (or its equivalent in the other C++ compilers). And C++ is not
unique. For example, Rust also supports different language editions.
If Python developers decided to keep both Python2 and Python3
maintained forever, then it would be similar to C++ and Rust.
D doesn't offer anything like this right now.
[snip]
D has preview/revert switches for some individual behaviors (though to my knowledge, not all deprecations have this). What it doesn't have is a way to combine several of these together based on an individual year/period and automation to switch to a newer edition. Rust has some good tooling for that.
Rust just released v1.64 of their system. 1018 people contributed to the new release.
D has nothing like that kind of developer horsepower. So we should realize that it may be simply be beyond the project's capacity to provide things, however useful or shiny, that we see in other languages.
D is obviously not my project, but to the extent this hasn't been thought about (I'd guess it has), I'd suggest taking stock of what the project ambitions are. I think of D as kind of the OpenBSD of the programming language world. OpenBSD is not nearly as successful, measured by user count, as Linux. But it's excellent work and serves a very useful purpose in the niche it has established for itself. But they do make compromises because of the limited developer capacity, e.g., they still don't have a unified buffer cache and the file-system is ancient (no COW, no journaling, though they do still support McKusick's soft dependencies).
I see D the same way. In my view, it's a lot better than C or C++. Is it going to replace either of them? Of course not. But there is a community of D users that understands its value and what the D project has accomplished and that appears to be enough for people like Walter to keep the project going, much like the OpenBSD situation. And a major plus for D is that Walter doesn't behave like Theo de Raadt :-)
In previous posts, I've described how D has served me well personally, allowing me to turn some really disgusting C into something manageable. I won't repeat any of that. But I would like to mention that I first tried to do this work in Rust. The big problem is that my main application has some global state; it is simply unavoidable. That application is also single-threaded, because of its nature. Rust has made the decision to assume that all applications are multi-threaded and therefore mutable globals are unsafe. To use them for global state, you end up with your code absolutely littered with "unsafe" blocks. You can try to use interior mutability and/or thread_local! to get around this. Good luck. So what you get is at least as ugly as my original C and with so many unsafe blocks, what about Rust's vaunted safety claims?
I think they should instead have provided an option to state that your code is single-threaded and will remain so, relaxing the stringency about multi-threaded-ness that just doesn't apply. This would allow writing inherently single-threaded code in a much more straight-forward way. But as the language is now, I had an incredibly frustrating experience and abandoned it. I could have made it work, but it was like going from the frying pan into the fire. D was an absolute delight after this experience.
Permalink
Reply
