Why do you use Rust, when D is available?

Personally, at some point Rust was just clearly better and after a while - I lost interest in D. I don't have time to keep track of D catching up, when I'm so happy with Rust, and ecosystem is growing so fast. Maybe D got much better in last few years... but I kind of don't care anymore. It's hard enough to introduce a raising star like Rust to your coworkers and D just don't have traction anymore.

I've been following D since early 2000s. 2 decades. It took it a long time to get good: make it open source, make it community driven instead of one-man show, add some really important features and focus on important things (ownership, memory-safety), get the tools to be good.

It just missed the boat, and never really had a right niche for itself. It was kind Java/C++ mix, and it wasn't all that better to dethrone anyone in that space.

Rust swooped in and executed everything perfectly in a really short time. It's a C++-killer: same strengths, none of the weaknesses. Normal people don't want to touch C++ anymore. Only people that think that CVEs are "just fault of bad developers" (LOL) can still be considering C++ a good language to start new projects in. Industry really, really needed C-like language that was memory safe, and all-round good: both low and high level. And Rust quickly delivered that, borrowing all the great aspects of other languages and addressing a lot of problems.

D is great, and I like it far more than e.g. Go, but it was an ambitious project by one individual for a long time, while Go had a whole Google behind it. There's no shame that it didn't "took over the world". Rust would possibly not do so well if it wasn't for Mozilla support. The marketing, credibility and traction a big backing company like this gives a new language is probably the single bigger reason for different outcomes.

First mover. For a long time D targeted the same abstraction level as Go, and most of its libraries were designed with that in mind. Stuff like no_std was never a major goal for most supposed "systems languages" (that are not C/C++) until Rust came along. D was too slow in gaining momentum, getting corporate sponsorship, and adding new features that pushed the boundaries of what a systems programming language was capable of. Go had first class tooling, D felt like a C++ with a Garbage Collector. It reminds me a lot of Ocaml which also had a lot of great ideas and occasionally showed up in the engineering blog of a major corporation but if you look closely then you would notice severe issues with package management and multithreading (both of which are finally getting attention and being fixed, 5 years too late). There are a lot of boring engineering that goes into making a good programming language ecosystem that many smaller languages do not have either the willpower or resources in tackling.

This is not criticism of the D language, programming languages are like startups, success often has little to do with the product itself but more the ecosystem, funding, and luck.

I know most people won't like this answer but the reason why rust is more popular now is because it had klabnik-san, mozilla, cargo and the super excited community.

The same goes for go-lang. It throws away years of research into programming languages. While rust is a great language and deserve the popularity, do you think go would have peaked in popularity if there weren't rob-pike-san and google behind it.

It's not a matter of features for programming languages popularity. It's who is backing them and doing the work to unite the community.

Programming communities also need to be aggressively cultish to take off in the beginning. You must be able to bite everyone's same repeated rehashed argument about lacking ecosystem, bad tooling and so on. You must be able to survive that and still shill the language.

It's reality. Everyone will tell you I don't care about your language when I can use my favourite language. People have invested more money than one can imagine into fixing php, js etc.

You can't easily get someone to switch from their single threaded language when they can scale it through AWS lambdas or other layers of abstractions.

This is why you don't see wide use of ML. All those communities are passive. They write their tutorials and papers in pure html on a weird forgettable domain name. They don't tell people to use the language because they are conscious of the lacking ecosystem but how would you get a good ecosystem without someone adopting it? OSS doesn't pay enough. Tooling require money. They don't focus on marketing or sponsorship.

Same applies for dlang.

As far as I know, D does not have ADTs (algebraic data types, a.k.a. tagged unions, a.k.a. Rust enums). I see that it has "enums" and "unions", but neither of these appear to be ADTs if I'm reading them correctly.

And Rust's borrow checker can give very strong guarantees that aren't present in any other mainstream language that I'm aware of. In Rust, you can pass mutable references to large data structures between threads, without copying or GC or any type of runtime checking (e.g. Mutexes), and the borrow checker will guarantee that you can't have a data race (data race = concurrent read & write). In comparison, I believe that in Haskell you'd do this with GC, in Java you'd do it with GC and a mutex, and in C you'd do it very carefully.

As another example, in Java if you modify an ArrayList while iterating over it, you'll get a ConcurrentModificationException. In Rust, you can't. The borrow checker won't let your program compile.

The cost of this borrow checker is huge: every reference in every program needs to be annotation with whether it's shared or mutable, and you often need to splatter confusing lifetime annotations all over the place. It adds a big learning curve to the language.

I don't know the details of D's ownership system, but it's not like Rust's borrow checker. Does someone who does know more want to describe it? I've just seen the language reference page here, that describes "scope" and "returns". https://dlang.org/spec/memory-safe-d.html

I remember how about 5 years ago I researched what new language to take on. I was in an unusual position to not consider job availability since I planned for a long game and was primary interested in growing my basic coding skills. It narrowed down to D, Go, Nim and Rust.

Rust won on paper based on C-like performance without GC and being not OOP-oriented in a Java way (I tried Java earlier and wondered who in his right mind would want to write that). But what convinced me was excellent basic documentation (the Book), concise and well documented standard library and nice FP-inspired idioms which I had no previous experience with.

I passed on Go due to GC and the fact that while I could probably learn the ropes quickly, there was not much I saw the language could teach me (I may be wrong here but such was an impression). Main accent was on speedy development in teams and it was orthogonal to my needs.

Nim (still Nimrod at the time) was intriguing but too fresh and lacking on documentation. It's much more intriguing now with gc:arc, move semantics and overall general momentum. I keep my eye on it.

D was the one I couldn't really find a place for. It was promising less, there was no killer feature that set it apart. To me it looked like more friendly C++ but with GC. I saw no real advantages.

I tend to think time proved my analysis to be mostly on point. At the time tooling and library ecosystem was rather poor for all four. Today even if featurewise D looks much more interesting, it needs to deliver on well-libraries to be competitive (I have no idea on its current situation on that front).

Sorry for such a long personal anecdote.

A mix of misteps by D, and some unique advantages of rust.

* Releasing D under a closed source license was a non-starter. This has killed every language that has tried in the past 30 years.

* Garbage collection was really the only memory management until recently. Manual memory management has always felt clunky and tacked on. Ownership and borrowing came really late to the game in comparison with rust.

* Rust embraced all of the best parts of ML, like algebraic data types and pattern matching and strong static typing, but combined them in a package that made for extremely fast software with low resource utilization and static memory management. They combined it with hygienic fully typed macros. They added type classes, securing the majority of the benefits of OOP while still maintaining a functional style.

Whereas Rust has taken influence from a broad range of PL research, functional programming concepts, high assurance concepts, etc., and applied them to system programming, D has always just felt like C++ with garbage collection.

The one area where I think D still has an advantage over rust is GUI development. Functional programming advocates make lots of platitudes of functional reactive programming, and there are no shortage of toy examples for it, but when it comes down to industrial use, OOP still rules the roost. And while Rust gets most of the benefits of OOP, they still don't have anything approximating inheritance, which just works too well for GUI development to give up on. Maybe Rust will address that in the future, but it's not there at the moment.

Phobos/Tango. GC, then optional-GC. Compiler support for various platforms was wonky, never sure if I was using the right one.

D as of now is a worthy competitor to Rust, it wasn't always the case, it was more like Go, with the GC. I hit some snags and moved on and didn't go back. I am sticking with Rust.

I think a question with closer alignment is, "Why use Go when D is available" ? D feels like a 5x better Go, not a Rust competitor.

Engineers learn languages because of success stories by other companies—not by the merits of the syntax or one-off tricks like compiling itself in 5 seconds.

The fact that Firefox uses Rust for the browser engine or that Dropbox uses Rust for the sync engine is the kind of thing that gets me interested.

The syntax is nicer.

Granted, I'm not very familiar with D. I didn't even know it had a borrow checker.

Rust took a lot of great features from Haskell, while keeping itself reasonably approachable from a C/C++/D/Java programmer's perspective.

Rust put type names after variable/function/parameter names, which really cleans up the syntax nicely.

Rust has very nice syntax for pattern matching, monads, and a slew of other really helpful functional language features.

Even if rust didn't have a borrow checker, it would still be a wonderful systems programming language.

It seems to me that D has been too many places and has too many features. My impression is that D sometimes uses a GC, sometimes not. I believe I can do many interesting things in D once I learn the language well enough to pick a certain subset of features, much like C++. In other words, if I want to write GC free code in D I have to learn what NOT to use.

If I want to pick a subset of features, I'd probably pick C++. Or, if I'm willing to use a GC and runtime, then there's lots of languages to choose from.

I use Rust if I want "safety" and no GC and that's all I get.

This is my impression. But I know very little of D so do not judge the language based on my impressions.

Disclaimer: I've used D for an enormous time, and I tried Rust for about one hour for the experience.

Remarks:

- build times are worse in Rust, but not _that_ much worse

- with Rust error messages are plentiful and helpful to solve the error. It is a designed user experience, which is quite novel.

- the first Rust program I built downloaded no less than 146 packages, which seems to indicate the standard library is very barebones. This was an example program. So the granularity of package seems to be smaller there. I don't really like this.

- Rust has quite visibly a stronger open-source ecosystem, with lots of crates being built before a compiler release. Good.

- Rust documentation is more aimed at beginner programmers, and there is more of it.

- I just don't like to look at Rust code at all... the styling on the car is really bad

- it seems dub and cargo are very similar. Cargo download and installs a lot more cruft inside directories. Probably there is a way to have a shared directory for that.

- Rust libraries look a bit more systematically modular with the features tags ("configurations" in DUB parlance)

- it seems Rust has comparatively more C bindings than C-to-D translations in the ecosystem (vs D)

So... I'm not sure I would take Rust if starting a codebase today. It just doesn't add up for me versus D.

I try to be someone practical and need actual measurable improvements in the daily practice.

For me the key take-away is the very consistent experience when interfacing with Rust tools, since this experience has been designed and fine-tuned to be easy. I think D can learn some UX tricks from it.

Let me throw my uneducated and biased opinion on the table.

It's amazing how Rust development and popularity progressed over the years. Uncompromising features, no trade-offs except for complexity and compilation speed but what language is ideal, right?

For me personally, D was just easier and faster to learn than C/C++/Rust. I got basically the same speed without memory management and learning curve overhead. Coming from Python land I enjoyed fast rdmd compile-and-run times that made me feel like I am working with an interpreted language while having much more control and access to the system. Nowadays, D forum, IRC is so helpful that I get an answer within minutes. I expected quite the opposite considering how smaller the community is.

So, these are my reasons for why D. You can see that I didn't care whether the language was backed up by some global company or was trendy. I got tired of Python that fallbacks to C/C++ when performance matters and if you want some real work done good luck with C/C++. JVM based languages were also not my cup of tea due to memory appetites and being comparably slower. D came as a surprise managing to be faster both in execution and compilation. It is later that I learnt about some of the shortcomings, smaller community, fewer available libraries, etc. etc.

From what I understand D ownership is based on function attributes which means it's enforced only across function calls and only as an opt-in. In Rust this is done across everything, so function basic blocks are also validated.

For those you want the context of D please check its development history [1].

If history telling us something, python only take off after 20 years and now D language is around the 20 years mark. But fortunately D has passed the growing pain similar to python 2 to 3 when it transitioned to D2.

Personally I think D just need a big breakthrough in a form of a killer application like Ruby with RoR, and Go with Kubernetes to make it more popular and gets the snow ball rolling. The killer application probably involve some kind of data science or data analytics that is currently more popular now with python. But python seems starting to reach its limits and it will be good if D can take over.

For rust since it came from Mozilla team I'd expect by now Firefox is already re-written in rust by now but it seems yet to happen, and this article probably tell us why [2]. It will be wonderful to have Firefox-rust (if it ever happened) to replace Chrome that keeps eating away my quad core CPU and 16 GB ram laptop memory once opening more than 20 tabs.

[1]http://erdani.com/hopl2020-draft.pdf

[2]https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...

I wouldn't compare a WIP borrow checker, just added some months ago, against Rust.

However, where it's the bigger and unique thing that D haves. Fast and very powerful metaprogramming. Can do things like parsing a XML or JSON at COMPILE TIME and generate code. No body catches how powerful is this ? For example, imagine parsing a gtk-build /glade XML and generating the GUI code at compile time, instead parsing it at runtime.

D was closed source when it was in the spotlight and missed its opportunity to gain mind share.

Rust enums are an amazing productivity boost because they can contain other values and data structures. This allows the type checker to help a lot more with business logic than is usually possible.

I can't tell if D is supposed to be used with or without the GC. I just know Rust is pretty close to an ML, which I like, and it has this nice borrow checker and is super popular.

I tried D some years ago, my naive program crashed as it wasn't memory safe. Being used to scala this was a surprising to me, I expected "if it compiles it works" but it turns out I had to take lifetimes into account just like c/c++. Rust has this "if it compiles it works" + quality.

Then I needed to create a program that would work both on android and Windows. Still liking D's syntax better funding rust rather verbose I decided to give it another try, but failed, I had to jump through too many hoops to make it produce a library usable on android. While with rust the experience was effortless.

After both experiences with D, I never looked back to it and rust is now my go to low level system language, the verboseness (with lifetimes and types) has grown on me.

Given the choice, I would rather use D, because experience has taught me that tracing GC are a productivy boom, even in systems programming, also D provides all the necessary tooling for doing GC free programming when required to do so.

However it lacks the commitment of a proper roadmap and big corporate support, and that sadly damages its image.

Rust on the other hand, while quite relevant for bringing affine types into mainstream, still isn't what I would like to use across the various domains I work on.

Ironically, I see Java and .NET getting the missing features (AOT, low level unsafe code, better control over memory allocation) that will eventually allow me to use them in system level programming scenarios, where I would choose D today.

This is an excellent question!

There's an old saying about natural languages: "A Language is a dialect with an army."

I think Rust's army--the one that will invade any discussion and say "use Rust!"--is simply better than D's "army."

As a D user who never used Rust, few reasons why Rust is more popular than D:

- better ecosystem, cargo has many more packages, almost every important C library has a binding available, also many C++ libraries like Qt, Bullet. D claims to have the best C++ interop capabilities of all languages, but it's not reflected in the amount of bindings to C++ libraries available

- Rust has a better foundation in form of standard library and "blessed" packages. D standard library hasn't had many updates over the years. There are packages such as std.xml that are due for replacement, but no replacement exists. There is still no standard http package, serialization package.

- adding to the above - many problems in D are solved by the way of "I made something, maybe someone will find it useful". Pieces of code are shared, but there is no organized effort to fill in the gaps, and in the effort there is, there often seems to be lack of the final push to get something included in the standard library. There has been many potential stdlib packages in form of pull requests that never get merged due to codestyle nitpicking or some design concerns, with authors never moving in to fix it.

- more IDE-friendly environment. A lot of D code is constructed in build-time, which isn't friendly towards refactoring and code completion tools. Also, many people in D community are hostile towards IDEs, considering them as bloat and that "real programmers use Vim/Emacs and don't need those fancy syntax highlighting".

- stretching the language too thin. D started as a mostly GC language. Now we have @nogc and betterC. But neither really work as well as going full GC. Now ownership and borrowing system is coming into play soon. Automatic refcounting might be implemented in the future. That's a lot of possible failure points, and ecosystem splitting points.

- Lisp curse. There aren't many syntax sugars added into the language, and many language features can be somewhat implemented with templates. Things like named arguments can be implemented as a template hack, but it looks terrible both from caller and callee side. But for many people it's "good enough" and they consider the case closed and move on to other features. As a result, D offers often many half-baked solutions. Libraries that worked for someone but never really got fully implemented, language features that somewhat work as long as you don't use that other feature that they don't work with. etc.

Obviously many of those problems in D are just a matter of lack of manpower and lack of money, it's a bit of chicken and egg problem.

D tried to be a bit like Java, because in the early 2000 Java was the popular language dethroning C++ and sadly, it succeeded.

The worst thing about all this legacy is Android.

I would love a phone OS in D, Rust, or other well-designed language.

I love D but I think the GC is a good argument for Rust

Because Rust is new and shiny.

People who use Rust aren't using it to solve real world problems, they're using it to scratch a novelty itch.

D is a tragedy in my opinion. It's an excellent language that just doesn't fit the political needs of any of the big players.

We have Swift which is a worse version of C#, we have Go, we have Java. Why don't we have a single language so that we can do cross platform development and abandon web browsers and javascript? Because politics. Every company needs to toot its own horn and suck up smart intelligent people so that they don't create a real competitor, and so we have a dozen languages that share 95% of the features and are all incompatible with one another and no one sane enough to say this is crazy, I'm going to take my FAANG money, move to a place with cheap rent and put an end to this madness.

It's only a game developer of all people, Jonathan Blow, that's doing it and his creation is a C++ replacement for games, not general purpose software. Sigh.

Helpful community. Healthy ecosystem (never want to write byte formatting libraries). Fun language. Good APIs.

I wasn't early to Rust and I won't be early to any other language. For PLs I'm solidly on the far end of the chasm.

Its my understanding that the main reason is because Rust doesn't use a Garbage Collector.

- bad or missing tooling

- no clear direction

- no vision

- no ide

- no big company

- bad or missing documentation

d does not support ownership and borrowing “just like rust”

Because there's a movement called "Rewrite everything in Rust"