6 ms·

I think this is a valid question. They're pretty different languages in terms of design, but they're definitely worth comparing—their problem domains do overlap

by PeCaN 10y ago

I think this is a valid question. They're pretty different languages in terms of design, but they're definitely worth comparing—their problem domains do overlap in spite of design differences. I've used both, but can't claim to be much of an expert in either. Similarities: • Compile to fast, easy-to-deploy native code • Abstraction continuum ranging from very low-level C-like style to a high-level more functional style • Very easy to call C libraries from • Type inferred and generally less syntactically noisy than C++ Neutral differences: • D is garbage collected; Rust has a novel memory management system based on linear types. This means D can never compete with Rust in performance and real-time or soft-real-time systems. On the other hand, it means with Rust you will spend more time thinking about memory ownership and other important-but-eliminated-by-GC concerns. Both are easier to deal with than C or C++. • Syntax: Rust's syntax is not-quite-C-like; D's is very C-like. It comes down to personal preference. I prefer Rust's. D advantages: • Metaprogramming: D's metaprogramming is more or less unmatched, though I haven't experimented with Rust compiler plugins at all. You can probably do some funky stuff with Rust, but it doesn't feel as integrated into the language as with D. • Compiles super fast. Rust advantages: • Type system. Rust's type system is ML-esque and generally much more powerful. I suppose this might not be an advantage to everyone, but personally I love how ML-y Rust feels. • Concurrency. • Ecosystem? I think ultimately my choice is that if I'm going to use a compiled GC language, I may as well just use OCaml. D's memory management, or lack thereof, kills it for me personally, but it's a well designed language otherwise IMO.

jjnoakes 10y ago
For some, D's garbage collection isn't quite neutral. Rust, for example, can be used to write a C-like loadable or linkable module for some other system (JNI, Ruby, Python, etc) with a very tiny or nonexistent runtime required. Having a GC makes this a little less seamless.
FraaJad 10y ago
I wouldn't be very sure about the claim that "D can never compete with Rust in performance and real-time or soft-real-time systems". If anything, due to much better metaprogramming (as you mention), you can have D programs that ARE faster than Rust (eg: see JSON parsing benchmark [1]). You can write programs in D that have ZERO garbage collection. In fact, the core libraries (phobos) are being actively rewritten to remove GC altogether. [1]: https://github.com/kostya/benchmarks#json https://github.com/kostya/benchmarks#json
- PeCaN 10y ago
  Last I checked, JSON parsing is not a typical (soft-)real-time workload. Heck, GC probably doesn't even kick in in that JSON benchmark. And yes, I'm aware that Phobos is being rewritten to remove GC. I'll reevaluate D when that's complete.
- steveklabnik 10y ago
  The D "fastjson" version is not a general solution: > I think it is not necessary to validate data you are not using. So basically > I only scan them so much as to find where they end. Granted it is a bit of > optimization for a benchmark, but is actually handy in real-life as well. > After all you could still raise the validation level to maximum if you really > cared or call one of the validation functions. https://github.com/kostya/benchmarks/pull/46#issuecomment-147932489 https://github.com/kostya/benchmarks/pull/46#issuecomment-14...
  - yawniek 10y ago
    shameless plug, you can use https://github.com/tamediadigital/asdf https://github.com/tamediadigital/asdf it should offer comparable performance to fastjson while having all the nice features.
dikaiosune 10y ago
> it means with Rust you will spend more time thinking about memory ownership and other important-but-eliminated-by-GC concerns. Both are easier to deal with than C or C++. I think an important wrinkle here is that Rust's ownership model helps prevent many runtime-errors other than memory safety. I'm not sure how D handles problems like iterator invalidation, but I've found it really nice to always know what's able to mutate the state when in a given variable.
- WalterBright 10y ago
  D offers type modifiers that include the notion of transitive immutability. This is very useful in function signatures in determining what a function may be modifying without needing to rely on comments.
steveklabnik 10y ago
Extremely minor nit: Rust has affine types, not linear.
pjmlp 10y ago
D's GC really could use some love, but they are working on it this year's GSoC. As for using GC in a systems programming language, even last a few days ago we had the links from Xerox Star. Originally developed in Mesa, which eventually became Cedar, that made use of GC. Also the whole set of ETHZ Oberon workstations. And many other experiences. The oldest I can find is a Flex computer system developed by the UK Royal Navy in Algol-68RS. I am pretty convinced, that just like e.g. JavaScript performance, there needs to be someone with enough money to bully the industry with such technologies until they stop being tabu. I still remember reading from C guys on Usenet that C++ would never be usable for writing OSes. Yet there are quite a few of them now.
- PeCaN 10y ago
  I didn't say D wasn't suitable for writing OSes. Might as well throw Singularity into the list of GCed operating systems. I did say D is unsuitable for real-time and soft-real-time programs, OS or otherwise. You can't write an RTOS in D.
  - pjmlp 10y ago
    Sure, I was just kind of brainstorming how much better GCed operating systems could be. As for RTOS, maybe you eventually could assuming future major improvements and compilers like the Atego JDK, but there is little to gain versus what Ada, SPARK and eventually Rust already offer today.
  - Matthias247 10y ago
    For hard realtime systems most kinds of dynamic memory allocations are a no-go. A lot of programs with such requirements have everything statically allocated, others use some static memory pools and custom allocators that those. I think that should also work with D - with the problem of losing lots of the standard library. I think the most problematic area is somewhere in between: Applications that want a mostly realtime performance without having to put too much work on guaranteeing it (e.g. Games, Low Latency Audio Processing, ...).
  - WalterBright 10y ago
agumonkey 10y ago
Which projects use D as the main language ? Rust has Servo. Redox got some light. But D has always been a language's language.
- unsignedqword 10y ago
  http://vibed.org/ http://vibed.org/ Facebook uses D a lot internally IIRC, although I'm not sure if many of the tools they made have been open-sourced.
- gver1 10y ago
  Areas of D usage: http://dlang.org/areas-of-d-usage.html http://dlang.org/areas-of-d-usage.html Organizations using D: http://dlang.org/orgs-using-d.html http://dlang.org/orgs-using-d.html
  - agumonkey 10y ago
    I should have tried harder. No, I should have tried.
- bachmeier 10y ago
  I use D for econometrics. The ability to easily call C libraries and interoperate with R (D embedded in R and vice versa) is very handy.
  - agumonkey 10y ago
    The article makes a good case for D as a sweet spot between low level, integration, ease of ues and abstract concepts.
unsignedqword 10y ago
Personally I find D a much more comfortable option. I tried Rust a few times, and it contains a few nice features ('match', expressional if-else, built-in tuples/multiple return) which would be cool to see in something like D, but I found the overt emphasis in Rust on safety to be entirely too aggravating to work with. Perhaps I might try it again in the future, though, who knows. To any Rust pros here, I'm curious: how long did it take for you to really get to grips with the language, coming from say, a C/C++ background?
- bjz_ 10y ago
  Once you internalise the rules, it clicks and becomes second nature, and you learn to really appreciate the explicitness. Lifetime/ownership errors go way down, and the ones you do get are usually trivial to fix. In saying that, as with any powerful type system there are always going to become some confounding cases, but for me the trade-off is worth it. It also makes the complexity of your domain more evident up front with shifts experimentation to the compile time phase as opposed to the run-time phase. I prefer the former though, because it is always a joy to have your code compile after a big refactor, and have it run pretty much as you expect.
gmfawcett 10y ago
Re: concurrency, D's concurrency story is really quite good. It may not be built upon as sound a logical model as Rust's (few languages can compete there), but it has very good ergonomics, and offers a nice range of concurrency strategies. See std.concurrency, std.parallelism, and vibe.d: - http://dlang.org/phobos/std_concurrency.html http://dlang.org/phobos/std_concurrency.html - http://dlang.org/phobos/std_parallelism.html http://dlang.org/phobos/std_parallelism.html - http://vibed.org/ http://vibed.org/ std.parallelism and vibe.d in particular are absolute pleasures to work with. As a framework, vibe.d is well designed to avoid unnecessary allocation and runs very efficiently. D's current GC is quite poor, that's a common complaint. But the recent and forthcoming "nogc" changes are making a significant difference -- it's increasingly easy to avoid the GC altogether.
WalterBright 10y ago
Although the GC is there and is the default, often D projects use various other memory management schemes in critical places. You can use malloc/free, custom allocators, stack allocators, and RAII in the usual ways as required.
gver1 10y ago
Additions & corrections: 1) While the majority of all users will profit from the convenience of the GC, it's not a big deal to use D without a GC. (apart from this kernel, another famous example is the next-level large-scale storage company Weka. They have had such real-time concerns that they invented their own Ethernet protocol - more details: http://dconf.org/2016/talks/zvibel.html http://dconf.org/2016/talks/zvibel.html) Moreover since last summer D got an amazing support of allocation building block with it's new Allocator API: http://dlang.org/phobos/std_experimental_allocator.html http://dlang.org/phobos/std_experimental_allocator.html 2) What's Rust's advantage on concurrency? This can be done quite well in D too, see e.g. this book chapter: http://www.informit.com/articles/article.aspx?p=1609144 http://www.informit.com/articles/article.aspx?p=1609144 There are a couple of advantages of D that are important to me and you didn't mention: - error-saving contracts (builtin unittests, assert, in & out blocks, invariants) - OOP (abstract classes, interfaces, ...) - mixins & code generation - compile time function evaluation and introspection (this makes your code even faster) - clean syntax & style (@property methods, lambdas, ...)

by PeCaN 10y ago

jjnoakes 10y ago

For some, D's garbage collection isn't quite neutral. Rust, for example, can be used to write a C-like loadable or linkable module for some other system (JNI, Ruby, Python, etc) with a very tiny or nonexistent runtime required. Having a GC makes this a little less seamless.

FraaJad 10y ago

I wouldn't be very sure about the claim that "D can never compete with Rust in performance and real-time or soft-real-time systems". If anything, due to much better metaprogramming (as you mention), you can have D programs that ARE faster than Rust (eg: see JSON parsing benchmark [1]). You can write programs in D that have ZERO garbage collection. In fact, the core libraries (phobos) are being actively rewritten to remove GC altogether. [1]: https://github.com/kostya/benchmarks#json https://github.com/kostya/benchmarks#json

PeCaN 10y ago
Last I checked, JSON parsing is not a typical (soft-)real-time workload. Heck, GC probably doesn't even kick in in that JSON benchmark. And yes, I'm aware that Phobos is being rewritten to remove GC. I'll reevaluate D when that's complete.
steveklabnik 10y ago
The D "fastjson" version is not a general solution: > I think it is not necessary to validate data you are not using. So basically > I only scan them so much as to find where they end. Granted it is a bit of > optimization for a benchmark, but is actually handy in real-life as well. > After all you could still raise the validation level to maximum if you really > cared or call one of the validation functions. https://github.com/kostya/benchmarks/pull/46#issuecomment-147932489 https://github.com/kostya/benchmarks/pull/46#issuecomment-14...
- yawniek 10y ago
  shameless plug, you can use https://github.com/tamediadigital/asdf https://github.com/tamediadigital/asdf it should offer comparable performance to fastjson while having all the nice features.

dikaiosune 10y ago

> it means with Rust you will spend more time thinking about memory ownership and other important-but-eliminated-by-GC concerns. Both are easier to deal with than C or C++. I think an important wrinkle here is that Rust's ownership model helps prevent many runtime-errors other than memory safety. I'm not sure how D handles problems like iterator invalidation, but I've found it really nice to always know what's able to mutate the state when in a given variable.

WalterBright 10y ago
D offers type modifiers that include the notion of transitive immutability. This is very useful in function signatures in determining what a function may be modifying without needing to rely on comments.

steveklabnik 10y ago

Extremely minor nit: Rust has affine types, not linear.

pjmlp 10y ago

D's GC really could use some love, but they are working on it this year's GSoC. As for using GC in a systems programming language, even last a few days ago we had the links from Xerox Star. Originally developed in Mesa, which eventually became Cedar, that made use of GC. Also the whole set of ETHZ Oberon workstations. And many other experiences. The oldest I can find is a Flex computer system developed by the UK Royal Navy in Algol-68RS. I am pretty convinced, that just like e.g. JavaScript performance, there needs to be someone with enough money to bully the industry with such technologies until they stop being tabu. I still remember reading from C guys on Usenet that C++ would never be usable for writing OSes. Yet there are quite a few of them now.

PeCaN 10y ago
I didn't say D wasn't suitable for writing OSes. Might as well throw Singularity into the list of GCed operating systems. I did say D is unsuitable for real-time and soft-real-time programs, OS or otherwise. You can't write an RTOS in D.
- pjmlp 10y ago
  Sure, I was just kind of brainstorming how much better GCed operating systems could be. As for RTOS, maybe you eventually could assuming future major improvements and compilers like the Atego JDK, but there is little to gain versus what Ada, SPARK and eventually Rust already offer today.
- Matthias247 10y ago
  For hard realtime systems most kinds of dynamic memory allocations are a no-go. A lot of programs with such requirements have everything statically allocated, others use some static memory pools and custom allocators that those. I think that should also work with D - with the problem of losing lots of the standard library. I think the most problematic area is somewhere in between: Applications that want a mostly realtime performance without having to put too much work on guaranteeing it (e.g. Games, Low Latency Audio Processing, ...).
- WalterBright 10y ago

agumonkey 10y ago

Which projects use D as the main language ? Rust has Servo. Redox got some light. But D has always been a language's language.

unsignedqword 10y ago
http://vibed.org/ http://vibed.org/ Facebook uses D a lot internally IIRC, although I'm not sure if many of the tools they made have been open-sourced.
gver1 10y ago
Areas of D usage: http://dlang.org/areas-of-d-usage.html http://dlang.org/areas-of-d-usage.html Organizations using D: http://dlang.org/orgs-using-d.html http://dlang.org/orgs-using-d.html
- agumonkey 10y ago
  I should have tried harder. No, I should have tried.
bachmeier 10y ago
I use D for econometrics. The ability to easily call C libraries and interoperate with R (D embedded in R and vice versa) is very handy.
- agumonkey 10y ago
  The article makes a good case for D as a sweet spot between low level, integration, ease of ues and abstract concepts.

unsignedqword 10y ago

Personally I find D a much more comfortable option. I tried Rust a few times, and it contains a few nice features ('match', expressional if-else, built-in tuples/multiple return) which would be cool to see in something like D, but I found the overt emphasis in Rust on safety to be entirely too aggravating to work with. Perhaps I might try it again in the future, though, who knows. To any Rust pros here, I'm curious: how long did it take for you to really get to grips with the language, coming from say, a C/C++ background?

bjz_ 10y ago
Once you internalise the rules, it clicks and becomes second nature, and you learn to really appreciate the explicitness. Lifetime/ownership errors go way down, and the ones you do get are usually trivial to fix. In saying that, as with any powerful type system there are always going to become some confounding cases, but for me the trade-off is worth it. It also makes the complexity of your domain more evident up front with shifts experimentation to the compile time phase as opposed to the run-time phase. I prefer the former though, because it is always a joy to have your code compile after a big refactor, and have it run pretty much as you expect.

gmfawcett 10y ago

Re: concurrency, D's concurrency story is really quite good. It may not be built upon as sound a logical model as Rust's (few languages can compete there), but it has very good ergonomics, and offers a nice range of concurrency strategies. See std.concurrency, std.parallelism, and vibe.d: - http://dlang.org/phobos/std_concurrency.html http://dlang.org/phobos/std_concurrency.html - http://dlang.org/phobos/std_parallelism.html http://dlang.org/phobos/std_parallelism.html - http://vibed.org/ http://vibed.org/ std.parallelism and vibe.d in particular are absolute pleasures to work with. As a framework, vibe.d is well designed to avoid unnecessary allocation and runs very efficiently. D's current GC is quite poor, that's a common complaint. But the recent and forthcoming "nogc" changes are making a significant difference -- it's increasingly easy to avoid the GC altogether.

WalterBright 10y ago

Although the GC is there and is the default, often D projects use various other memory management schemes in critical places. You can use malloc/free, custom allocators, stack allocators, and RAII in the usual ways as required.

gver1 10y ago

Additions & corrections: 1) While the majority of all users will profit from the convenience of the GC, it's not a big deal to use D without a GC. (apart from this kernel, another famous example is the next-level large-scale storage company Weka. They have had such real-time concerns that they invented their own Ethernet protocol - more details: http://dconf.org/2016/talks/zvibel.html http://dconf.org/2016/talks/zvibel.html) Moreover since last summer D got an amazing support of allocation building block with it's new Allocator API: http://dlang.org/phobos/std_experimental_allocator.html http://dlang.org/phobos/std_experimental_allocator.html 2) What's Rust's advantage on concurrency? This can be done quite well in D too, see e.g. this book chapter: http://www.informit.com/articles/article.aspx?p=1609144 http://www.informit.com/articles/article.aspx?p=1609144 There are a couple of advantages of D that are important to me and you didn't mention: - error-saving contracts (builtin unittests, assert, in & out blocks, invariants) - OOP (abstract classes, interfaces, ...) - mixins & code generation - compile time function evaluation and introspection (this makes your code even faster) - clean syntax & style (@property methods, lambdas, ...)