Hacker News Reader

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_parallelism.html - 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.

> 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.

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.

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) 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

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

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, ...)

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.

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.

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.

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, ...).

> You can't write an RTOS in D.

Can't is a pretty strong word. You can write C-style code in D that compiles and behaves identically to C, including malloc/free.

I… I just got corrected by Walter Bright.

That's true. You actually can write an RTOS in D, and it would still be more pleasant than in C (thanks to D's excellent metaprogramming). The problem I have with opt-out GC in D is that it leaves you with very little else as far as memory safety goes—you have RAII, but nothing like Rust or Cyclone or other languages that are explicitly safe without a GC. You can leak, you can crash, you can have race conditions, etc, almost as easily as in C. Some sort of D version of unique_ptr would get you part of the way there, but it's still not as complete as Rust.

D does have @safe, which does a good job of preventing large classes of unsafe pointer issues. It is not perfect yet (we're working on it) but it is far better than "nothing like", and far better than C/C++.

For example, it does array bounds checking.

Interesting, I didn't know about @safe. I need to study D more!

At the moment I'm pretty happy with OCaml and learning Rust, but D definitely has me interested (especially when the no-GC stdlib completes).

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.

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

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.

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-14...

shameless plug, you can use https://github.com/tamediadigital/asdf it should offer comparable performance to fastjson while having all the nice features.

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?

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.

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

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.

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

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.

Areas of D usage: http://dlang.org/areas-of-d-usage.html Organizations using D: http://dlang.org/orgs-using-d.html

I should have tried harder. No, I should have tried.

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.

The article makes a good case for D as a sweet spot between low level, integration, ease of ues and abstract concepts.