3 ms·

how is D different from C/c++/rust/zig for system programming? what's the major selling point? is it good for embedded(no GC) use cases? what stopped it from be

how is D different from C/c++/rust/zig for system programming? what's the major selling point? is it good for embedded(no GC) use cases? what stopped it from becoming universally used?

acehreli 4y ago
> how is D different I don't know Zig yet. I had an opinion long time ago that nobody should use C anymore; I would suggest C++ at least because it has constructors and templates. D's [Better C](https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html) would be my go-to at this time. C++ is getting better but it's still very difficult to get right: It depends mainly on programmer attention e.g. to follow 400+ [guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines). Rust is "different" but it has the borrow checker as a safety tool. D's [live functions](https://dlang.org/spec/ob.html https://dlang.org/spec/ob.html) and other [memory safety](https://dlang.org/blog/2022/10/08/dip1000-memory-safety-in-a-modern-systems-programming-language-part-2/ https://dlang.org/blog/2022/10/08/dip1000-memory-safety-in-a...) features are closing the gap there. > major selling point I am copying slide 59 here: D provides competitive advantage by helping happy programmers produce correct programs pragmatically. Slide 8 lists what D does not have, which can explain why D has not gained popularity that it deserves. For example, nobody can sell D as "Google's language" or "Apple's language".
- synergy20 4y ago
  makes sense, thanks!
- no_wizard 4y ago
  Is there a way to enable safe "D" by default, rather than using the `@safe` (what looks to be) modifier?
  - acehreli 4y ago
    No. We had a very long discussion about safe-by-default on the forums but failed to reach a consensus. As I understand it, for safe-by-default to work, either all C libraries would have @trusted D bindings written, or all of them would have to be assumed to be @trusted. Most of the community wanted explicit @trusted annotations, Walter and others favored assuming them to be @trusted (or was it assumed @safe?) was the way to go. So, no safe-by-default at this time. :/
  - gavinray 4y ago
    D-lang attributes can be used like a label, so for example you can put at the top of your file: @safe nogc: auto myFunc() { // do stuff } struct Blah {} Whatever attributes you use apply to all code in the lexical scope below the colon. It's useful for structs/classes struct MyThing { auto unsafeFunc() {} @safe: auto safeFunc1() {} }
  - nicwilson 4y ago
    Kind of, mark `main` `@safe`. The transitivity of safety will ensure that you can only call safe functions, else you will get a compile error.
Decabytes 4y ago
> what stopped it from becoming universally used D had a lot of momentum in the beginning, but the license around the compiler scared away some people, then there was the whole standard library split with phobos and tango (irrelevant now and has been for over a decade), and from my understanding in the beginning (I wasn't around during that time) Walter added features by request as there wasn't a DIP process yet (D improvement proposals), and some people felt it was unfair. These have all been rectified.
- synergy20 4y ago
  so all problems are resolved (including compiler license) then, I was curious about D but never looked into seriously, now it seems about time. anything safer than C, easier than c++ and rust is interesting. i will build some code and check out its memory usage and binary size, both are important for embedded.
  - acehreli 4y ago
    > memory usage and binary size Don't forget the -betterC compiler switch please. ;)
  - arunc 4y ago
    -betterC is the way to go for embedded. Checkout this blog as well: https://dlang.org/blog/2021/06/01/driving-with-d/ https://dlang.org/blog/2021/06/01/driving-with-d/
- Keyframe 4y ago
  There was also this whole D1 vs D2 where some of us (I was involved with Tango) though D1 more of as a 'better C' (not related to actual better C) and D2 more of as a better C++. Personally, I was more interested in D1 direction. D took the D2 route with Alexandrescu onboard at a time. The whole thing then was also lacking support. Even if D was a better language (D1 was, I guess D2 might be as well - haven't dabbled in a decade with it), you had to do everything from scratch. No libraries, abandoned bindings, etc.. instead of doing work with it, you had to do the plumbing first. That's true for most niche languages. Rust was like that as well, but not seems to have a momentum going on for it and is growing / has grown out of that phase D never did. D has been around now what, 15-20 years? How sweet would it be for someone of Walter's caliber to join the ranks of Rust team? Dude is incredible, but D seems to be a dead end ultimately. Sorry to sound so harsh, but it didn't happen on a scale it needs, why would it now or ever?
WalterBright 4y ago
D is more capable as a systems programming language than C or C++ is. Not only can you do whatever you like with pointers, but it has a nice symbolic inline assembler, too. The code generator is shared with C's and C++'s, so there is no difference in code quality.

how is D different from C/c++/rust/zig for system programming? what's the major selling point? is it good for embedded(no GC) use cases? what stopped it from becoming universally used?

acehreli 4y ago

> how is D different I don't know Zig yet. I had an opinion long time ago that nobody should use C anymore; I would suggest C++ at least because it has constructors and templates. D's [Better C](https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html) would be my go-to at this time. C++ is getting better but it's still very difficult to get right: It depends mainly on programmer attention e.g. to follow 400+ [guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines). Rust is "different" but it has the borrow checker as a safety tool. D's [live functions](https://dlang.org/spec/ob.html https://dlang.org/spec/ob.html) and other [memory safety](https://dlang.org/blog/2022/10/08/dip1000-memory-safety-in-a-modern-systems-programming-language-part-2/ https://dlang.org/blog/2022/10/08/dip1000-memory-safety-in-a...) features are closing the gap there. > major selling point I am copying slide 59 here: D provides competitive advantage by helping happy programmers produce correct programs pragmatically. Slide 8 lists what D does not have, which can explain why D has not gained popularity that it deserves. For example, nobody can sell D as "Google's language" or "Apple's language".

synergy20 4y ago
makes sense, thanks!
no_wizard 4y ago
Is there a way to enable safe "D" by default, rather than using the `@safe` (what looks to be) modifier?
- acehreli 4y ago
  No. We had a very long discussion about safe-by-default on the forums but failed to reach a consensus. As I understand it, for safe-by-default to work, either all C libraries would have @trusted D bindings written, or all of them would have to be assumed to be @trusted. Most of the community wanted explicit @trusted annotations, Walter and others favored assuming them to be @trusted (or was it assumed @safe?) was the way to go. So, no safe-by-default at this time. :/
- gavinray 4y ago
  D-lang attributes can be used like a label, so for example you can put at the top of your file: @safe nogc: auto myFunc() { // do stuff } struct Blah {} Whatever attributes you use apply to all code in the lexical scope below the colon. It's useful for structs/classes struct MyThing { auto unsafeFunc() {} @safe: auto safeFunc1() {} }
- nicwilson 4y ago
  Kind of, mark `main` `@safe`. The transitivity of safety will ensure that you can only call safe functions, else you will get a compile error.

Decabytes 4y ago

> what stopped it from becoming universally used D had a lot of momentum in the beginning, but the license around the compiler scared away some people, then there was the whole standard library split with phobos and tango (irrelevant now and has been for over a decade), and from my understanding in the beginning (I wasn't around during that time) Walter added features by request as there wasn't a DIP process yet (D improvement proposals), and some people felt it was unfair. These have all been rectified.

synergy20 4y ago
so all problems are resolved (including compiler license) then, I was curious about D but never looked into seriously, now it seems about time. anything safer than C, easier than c++ and rust is interesting. i will build some code and check out its memory usage and binary size, both are important for embedded.
- acehreli 4y ago
  > memory usage and binary size Don't forget the -betterC compiler switch please. ;)
- arunc 4y ago
  -betterC is the way to go for embedded. Checkout this blog as well: https://dlang.org/blog/2021/06/01/driving-with-d/ https://dlang.org/blog/2021/06/01/driving-with-d/
Keyframe 4y ago
There was also this whole D1 vs D2 where some of us (I was involved with Tango) though D1 more of as a 'better C' (not related to actual better C) and D2 more of as a better C++. Personally, I was more interested in D1 direction. D took the D2 route with Alexandrescu onboard at a time. The whole thing then was also lacking support. Even if D was a better language (D1 was, I guess D2 might be as well - haven't dabbled in a decade with it), you had to do everything from scratch. No libraries, abandoned bindings, etc.. instead of doing work with it, you had to do the plumbing first. That's true for most niche languages. Rust was like that as well, but not seems to have a momentum going on for it and is growing / has grown out of that phase D never did. D has been around now what, 15-20 years? How sweet would it be for someone of Walter's caliber to join the ranks of Rust team? Dude is incredible, but D seems to be a dead end ultimately. Sorry to sound so harsh, but it didn't happen on a scale it needs, why would it now or ever?

WalterBright 4y ago

D is more capable as a systems programming language than C or C++ is. Not only can you do whatever you like with pointers, but it has a nice symbolic inline assembler, too. The code generator is shared with C's and C++'s, so there is no difference in code quality.