71–80 of 186 posts
Earlier quoted context omitted.
I don't think minimal compiler complexity is a real requirement as much as safe and reliable software is. CPU fabs aren't easy, yet we're fine with that.
It matters for portability. I'm not saying it's the most important requirement, of course, but it's C strongest point.
Earlier quoted context omitted.
Honestly, I believe it is much more about marketing than one might expect.
That's kind of an uncharitable way to say, "Rust has a welcoming and beginner-friendly community". It's not like there's a marketing team buying Facebook ads.
The Rust community realized early that if they wanted to succeed, they had to talk about Rust a lot, show good examples, be beginner friendly to avoid people picking it up and dropping it quikly. But that "marketing" is also things like a really good package manager, really good compiler errors, a really good VSCode extensions. Many communities don't have this (especially the new ones) and this makes developing in Rust more of a joy than in let's say OCaml or even JS.
Any reasons D never caught on more? No big tech company anchor behind it?
Not different enough to be worth switching from Java/C++ with their much bigger and more established communities. This was especially true earlier in it's history when it required GC. Now it doesn't, but it has to compete with Rust which can also offer memory safety.
Earlier quoted context omitted.
As far as I know D's original design strategy, was to be a simpler to use C++ with a GC, but with the same expressive power Over time, this proved to be a bad strategy, C++ key strength became RAII (deterministic memory management), so the GC became a failed strategy The maintainers tried to move in different directions, adding manually memory management, making the GC optional, moved D to be a C replacement, with th…
This isn't a very good summary of how the language evolved. D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1. BetterC is a nice-to-have rather than a language dialect. Having a GC is an absolute godsend for getting c…
Earlier quoted context omitted.
> such as the fact that a safe subset exists, but depends on GC, @safe works perfectly fine and exactly the same in @nogc code as in GC-enabled code.
My mistake - SafeD was introduced since I stopped using D, so I was going off this article: https://dlang.org/articles/safed.html#safed-subset > When you enter SafeD, you leave your pointers, unchecked casts and unions at the door. Memory management is provided to you courtesy of Garbage Collection. Does D provide the necessary tooling to be able to expose a safe API for something which needs to allocate memory, with…
Following that you will want to check for null ext. to make it actually @safe in practice and not just typed as such.
Earlier quoted context omitted.
This isn't a very good summary of how the language evolved. D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1. BetterC is a nice-to-have rather than a language dialect. Having a GC is an absolute godsend for getting c…
Would it be fair to say that for some time (I wouldn't know exactly when it started) D has evolved to serve the needs of the D community rather than to attract new people?
Another anecdote - Someone who hires people in D has told me definitely that D being small means that hiring for them is usually just seeing some code, i.e. there hasn't been an eternal September let's say. They can onboard people who don't know the language, but knowing D is a very good cultural (programming is easy!) filter.
Earlier quoted context omitted.
This isn't a very good summary of how the language evolved. D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1. BetterC is a nice-to-have rather than a language dialect. Having a GC is an absolute godsend for getting c…
Would it be fair to say that for some time (I wouldn't know exactly when it started) D has evolved to serve the needs of the D community rather than to attract new people?
Lots of stuff exist specifically to help with onboarding people into the community. Like the recent announcement of adding a C parser into the frontend.
I use D every day for own business and it's a pleasure. Nice work!
What for exactly you use it?
Earlier quoted context omitted.
I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Nicer syntax. The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language. Furthermore, many of the other downsides of C++ are still present: -…
I am learning Rust and SPARK2014, and I would think SPARK2014/Ada would be a better fit for high-integrity software for verifiable, embedded software than Rust. This was the older article that stimulated me to look at Ada and then SPARK2014 again: https://www.embedded.com/spark-2014-why-i-am-backing-a-predi... EDIT: Cool list of SPARK2014/Ada embedded projects: https://blog.adacore.com/tag/embedded%20development