7 ms·

How do D and Rust stack up against each other? Both seem to quite attractive as next generation compiled languages.

atilaneves 8y ago
Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that, but now there's [DIP1000](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). D can however be used without a GC if needed. Rust has macros, which D doesn't, but D's metaprogramming is superior. They're both fine choices.
- jetzzz 8y ago
  > Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that Isn't D memory unsafe by default?
  - atilaneves 8y ago
    > Isn't D memory unsafe by default? Yes, but it only takes this to guarantee it: void main() @safe { // ... }
    - earenndil 8y ago
      Not quite, that doesn't guard for safety in things like module constructors.
- Hasknewbie 8y ago
  > D can however be used without a GC if needed Honest question: is it the case in practice though? Last time I checked D, you could disable the GC in theory, but in practice many things would fail to work, most importantly their standard library. As this been fixed since then?
  - atilaneves 8y ago
    Yes, it's the case in practice: I've written a lot of @nogc code. Some parts of the standard library require the GC, but not all of it, and the parts that I usually use are fine (std.algorithm, std.range, ...). Since allocators landed, it's been a lot easier, and I've written a library that does C++-style smart pointers for D: https://github.com/atilaneves/automem https://github.com/atilaneves/automem
vaylian 8y ago
I am not completely up to date with D at the moment, but I hope the following is still accurate: Both D and Rust are fast when it comes to run time. Rust is more explicit about allocations because of the borrow checker. A typical case is string handling. In D you do not need to think much about gluing strings together. In Rust, you have to use more explicit code to say: Yes, I really want the extra allocation. Rust makes you more conscious about lifetimes. That can be a good thing. You will get better runtime performance, but I also think that it promotes simplicity which in turn makes it easier to understand the code in the future (every variable has a clear owner). D gives you speed with a pleasant syntax. Rust gives you robustness and the language-design of a community. D's design addresses the unsafety of C and C++ and makes it a lot harder to shoot yourself in the foot. Not as hard as Rust, but pretty hard. Rust feels much more like a universal language, that not only focuses on the niche of C and C++. D has a clear focus on the C/C++ world, but it is still a suitable language for scripting. I used it a while instead of Python to write file processing scripts. Why did I stop doing this? Mostly because I moved to a new place that was very biases towards Python. I did not think much about it back then but I could probably have kept writing D. Both are good languages. I think Rust is still more difficult to pick up, but the learning resources are getting better every day. If you want to use one of the two languages in a project with a team that is unfamiliar with both languages, D is probably the safer choice unless you have very strong reliability requirements. I think both languages are worth learning. And both are good choices in the domain of C and C++.
mntmoss 8y ago
I would position D on a spectrum between Go and Rust. Go is roughly where you would end up if you trimmed down D to its bare bones: a pretty fast GC language with a native runtime that can do some memory manipulation if needed, where the focus is on providing a single idiom that works for every task. D is more like the C++er's take on that idea. It has templates, it has annotations galore, lots of convenience features, lots of low level features, and it's gradually repositioning to depend less on the GC and get some similar "manual but safe" memory functionality of Rust. It can be a bit intimidating, but you can be productive with it relatively quickly if you write Go-like code, and add the extra stuff in gradually. That gives it leverage as a language that really grows with your project and lets you go into fine-grain detail where you need it. Rust is like Go in that it's at an uncompromising extreme of the memory-safety spectrum. Borrow checking(and its resulting patterns, which are typically considered idiomatic in modern C++) is in at the core and it's not going away. This makes it great for code that needs to scale out to the extremes of something like a web browser, where the codebase cannot "do one thing well" anymore and needs tight control over resources, concurrency, and safety all in the same package. There are reasons to find any of these three unfavorable - the harshest critics might say Go is "braindead", D is "a mess", Rust is "too strict". I believe all three are here to stay. I would also lump in Zig here as a second axis of the equation. Where the other languages all have ambitions about memory safety, Zig makes no bones about being unsafe: it aims to be a direct replacement to C, which cleans up every other aspect - areas where the standard is unclear, where more checks around boundary conditions are possible, and where modernization would be of immediate help, e.g. a compilation system that does not involve the C preprocessor or header files. Zig isn't hostile about memory safety - there's willingness to explore it, but the approach is conservative. This positions it as the ultimate "low-level library" language, where the programmer goes in with a straightforward goal and can reasonably expect to know what every last byte does.

Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that, but now there's [DIP1000](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). D can however be used without a GC if needed. Rust has macros, which D doesn't, but D's metaprogramming is superior. They're both fine choices.

jetzzz 8y ago
> Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that Isn't D memory unsafe by default?
- atilaneves 8y ago
  > Isn't D memory unsafe by default? Yes, but it only takes this to guarantee it: void main() @safe { // ... }
  - earenndil 8y ago
    Not quite, that doesn't guard for safety in things like module constructors.
Hasknewbie 8y ago
> D can however be used without a GC if needed Honest question: is it the case in practice though? Last time I checked D, you could disable the GC in theory, but in practice many things would fail to work, most importantly their standard library. As this been fixed since then?
- atilaneves 8y ago
  Yes, it's the case in practice: I've written a lot of @nogc code. Some parts of the standard library require the GC, but not all of it, and the parts that I usually use are fine (std.algorithm, std.range, ...). Since allocators landed, it's been a lot easier, and I've written a library that does C++-style smart pointers for D: https://github.com/atilaneves/automem https://github.com/atilaneves/automem

vaylian 8y ago

I am not completely up to date with D at the moment, but I hope the following is still accurate: Both D and Rust are fast when it comes to run time. Rust is more explicit about allocations because of the borrow checker. A typical case is string handling. In D you do not need to think much about gluing strings together. In Rust, you have to use more explicit code to say: Yes, I really want the extra allocation. Rust makes you more conscious about lifetimes. That can be a good thing. You will get better runtime performance, but I also think that it promotes simplicity which in turn makes it easier to understand the code in the future (every variable has a clear owner). D gives you speed with a pleasant syntax. Rust gives you robustness and the language-design of a community. D's design addresses the unsafety of C and C++ and makes it a lot harder to shoot yourself in the foot. Not as hard as Rust, but pretty hard. Rust feels much more like a universal language, that not only focuses on the niche of C and C++. D has a clear focus on the C/C++ world, but it is still a suitable language for scripting. I used it a while instead of Python to write file processing scripts. Why did I stop doing this? Mostly because I moved to a new place that was very biases towards Python. I did not think much about it back then but I could probably have kept writing D. Both are good languages. I think Rust is still more difficult to pick up, but the learning resources are getting better every day. If you want to use one of the two languages in a project with a team that is unfamiliar with both languages, D is probably the safer choice unless you have very strong reliability requirements. I think both languages are worth learning. And both are good choices in the domain of C and C++.

mntmoss 8y ago

I would position D on a spectrum between Go and Rust. Go is roughly where you would end up if you trimmed down D to its bare bones: a pretty fast GC language with a native runtime that can do some memory manipulation if needed, where the focus is on providing a single idiom that works for every task. D is more like the C++er's take on that idea. It has templates, it has annotations galore, lots of convenience features, lots of low level features, and it's gradually repositioning to depend less on the GC and get some similar "manual but safe" memory functionality of Rust. It can be a bit intimidating, but you can be productive with it relatively quickly if you write Go-like code, and add the extra stuff in gradually. That gives it leverage as a language that really grows with your project and lets you go into fine-grain detail where you need it. Rust is like Go in that it's at an uncompromising extreme of the memory-safety spectrum. Borrow checking(and its resulting patterns, which are typically considered idiomatic in modern C++) is in at the core and it's not going away. This makes it great for code that needs to scale out to the extremes of something like a web browser, where the codebase cannot "do one thing well" anymore and needs tight control over resources, concurrency, and safety all in the same package. There are reasons to find any of these three unfavorable - the harshest critics might say Go is "braindead", D is "a mess", Rust is "too strict". I believe all three are here to stay. I would also lump in Zig here as a second axis of the equation. Where the other languages all have ambitions about memory safety, Zig makes no bones about being unsafe: it aims to be a direct replacement to C, which cleans up every other aspect - areas where the standard is unclear, where more checks around boundary conditions are possible, and where modernization would be of immediate help, e.g. a compilation system that does not involve the C preprocessor or header files. Zig isn't hostile about memory safety - there's willingness to explore it, but the approach is conservative. This positions it as the ultimate "low-level library" language, where the programmer goes in with a straightforward goal and can reasonably expect to know what every last byte does.