
Ask HN: Why do you use Rust, when D is available? - crazypython
D supports Ownership and Borrowing, just like Rust. DMD, D&#x27;s reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile.<p>I&#x27;d love to hear some reasons why so D and Rust can learn from each other.
======
dpc_pw
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.

~~~
mrfusion
I’m currently trying to get into robotics. But why does everyone want c++?
Surely robots can be programmed in other languages.

~~~
blub
Because the real world doesn't really match the expectations and statements of
the HN community. It's really rare that I see here anything pragmatic
regarding what programming languages to learn/use.

The community lives in a bubble and is out of touch with mainstream software
development.

~~~
Recurecur
I'm a _very_ senior engineer. I've had a strong desire to find a better
alternative to C++ since the 90s when I was first exposed to it (I worked with
it for about a decade, after a few years with C). Now, decades later, enough
bandaids have been applied that it's somewhat tolerable. Congratulations...?

The industry has needed good alternatives for a long time. Finally, they're
coming, and not nearly soon enough to suit me! :-)

~~~
blub
I believe you're right about those alternatives not coming soon enough. If all
things go right, by the time Rust will be (sort of) mainstream you'll be able
to set up the "Rusty Grampas League" :-)

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

~~~
lordlic
> Go had first class tooling

Eh, I would describe go's tooling as "minimalist" or, less charitably, as
"barely adequate." Pre-modules the global GOPATH approach was hacky and ugly,
and post-modules the go command is a mess of contradictions straining against
the backwards compatibility guarantee. And editor integration back in the day
wasn't much more than running go fmt and go build.

~~~
isaiahg
Arguably that's one of the things that made it easy to pick up. I remember
tons of JavaScript programmers who were suddenly systems programmers when it
came out.

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

~~~
AnimalMuppet
Case study: awk. Brian Kernighan, who (co-)wrote the book on C, designed (with
two others) another language, awk. Same organization (Bell Labs) pushing it as
pushed C. C ate the world. awk... um... was available on all Unix
installations, and got used for some things.

Sure, there are people who rave about how great awk is. I've read them here on
HN. When you've got the right kind of problem, it's a great tool. But there
are very few people for whom it is their main everyday language.

My point: Author/designer and organization can only take a language so far. At
some point, the actual usefulness of the language determines how much it is
actually used.

~~~
yesenadam
So you're saying Awk isn't "actually useful" which is why it's hardly used?!
It's an entirely different kind of tool to C. Or rather, C is a programming
language, Awk is a tool. To "get used for some things" is what it's for.
Sounds like you're talking more about what purpose things are used for than
how much they're actually used. And Awk seems a failure to you because it's
used for Awk-problems rather than C-problems? I don't understand your
negativity. Awk was and is wildly successful.

~~~
AnimalMuppet
> So you're saying Awk isn't "actually useful" which is why it's hardly used?!

I deny you the right to put words in my mouth. That is not remotely what I am
saying.

------
justinpombrio
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](https://dlang.org/spec/memory-
safe-d.html)

~~~
mhh__
D's borrow checker is only semi-documented/WIP at the moment.

[https://dlang.org/blog/2019/07/15/ownership-and-borrowing-
in...](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/)

Basically D just needs that big break to actually get things done. There are
some absolutely brilliant people working on D but there's only so much sweat
people will donate (some people are paid but I imagine rust probably has
upwards of a hundred full time staff given that Mozilla and Microsoft use it
in an official capacity)

~~~
vmchale
Also D has a gcc backend.

Which is nice but it's still missing some of Rust's features.

~~~
welkam
Its more than that. D is part of GCC - The GNU Compiler Collection. Meaning
that if you use linux and have recent GCC you already have D compiler.

~~~
datman347
Don't know anyone that uses the D GCC compiler, it is still playing catch up.
The frequency of new D releases with intended and unintended breaking changes,
usually source only ever compiles for a very narrow range of versions of D.
What people usually focus on is the latest, unless there is a new bug that
prevents them from using the newest version.

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

~~~
trevyn
> _Go [...] there was not much I saw the language could teach me_

Interesting that you mention this; one of the reasons I really enjoy Rust is
because of how it forces me to think through things more clearly, and how a
number of the higher-quality crates teach more advanced approaches in a
straightforward way.

~~~
fastasucan
I am a Python programmer first and foremost (data science-y stuff), but lately
I've started reading the Rust documentation. First and foremost its really an
enjoyable read. I also learn alot from it, and become a better programmer in
general. I will try to write a library that I will use for my PhD, in Rust. I
think it will teach me a lot about programming, be enjoyable and also give me
a great library for string parsing and decryption.

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

~~~
jsnell
Java, C#, Visual Basic and JavaScript all are less than 30 years old and all
started off with proprietary main implementations. The phenomenon is probably
real, but it's more recent than you suggest.

~~~
rbanffy
I can't remember one that's more recent than 20. All these languages were
introduced before open source became the clear winner it is now.

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

~~~
thrwaway69
Why did go took off then?

~~~
pengaru
It's impossible to measure how much impact just having Rob Pike and Google
behind Go has had on its adoption.

~~~
catach
Google and Pike get you in the door. Goroutines get you to sit down. The
onboarding-oriented nature of the language and ecosystem convince you to sign.

~~~
sitkack
What Go did for the tooling space cannot be underestimated, it is wonderful
and we will never go back to the before time.

~~~
pjmlp
What providing a formatter like indent has provided for decades?

Selling a Turbo Pascal/Modula-2 like compilation speed from MS-DOS days as
novelty?

Or was using IDE code refactoring tools as UNIX CLI?

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

~~~
anyfoo
That's a dangerously general statement, and it does not apply to me (an
engineer) for example. I learned a lot of languages because of the language
itself, e.g. their type system.

~~~
metrokoi
It may be dangerous to blindly trust that a language is good based on a
company's success with that language, but a large company deciding to heavily
invest resources and take a risk on a language is also evidence that the
language has the designs to succeed.

~~~
nix23
That's based on the company, tech...yes, insurance..probably no ;)

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

~~~
tastyminerals2
One of the reasons why I haven't approached Rust is its syntax. Subjectively
ugly and polluted with punctuation symbols that tell you little about their
semantics. D looks cleaner and more readable even for a person not familiar
with the language. D's readability is on par with scripting languages. Rust is
far away from that.

Type names after variable or before? When you think about declaring a
variable, do you think about its type of name first? I can't imagine you do
the latter because "Hmm, I need an array of doubles to represent my tensor" is
double[][] tensor; and not tensor: double[][]. Besides the types after names
end up being more verbose in the languages which adopt the scheme (hello
Scala).

I invite you to get familiar with D syntax to see a wider picture.

The borrow checker in D is WIP and given how much stir it created, I don't see
it's happening any time soon.

~~~
e_y_
For reading code, which arguably should happen more often than writing code,
having the variable name first makes it easier to find, since it's right near
the beginning of the line and it's a single word. If the type comes first, I
have to scan the line to figure out where the type ends and the variable name
begins.

Also, having "let" at the beginning of the line makes it immediately clear
that it's a variable definition, whereas if it starts with some arbitrary type
I haven't seen before I have to spend more time figuring out what's happening.
Good syntax highlighting helps, but I think starting with types like C/C++/D
is less elegant than starting off with a keyword that clearly identifies what
the line does.

Similar applies for function definitions. It's nice when the function names
are all lined up and not buried halfway across the screen because it has some
long return type.

~~~
tastyminerals2
Subjectively, I see no point in having "val", "var", "let", "def", "fn"
symbols which bring only noise to code. Why would you want to explicitly tell
that something is a value while all you need to do is write its type and name?

double[] arr;

bam! Simple and clear.

What about functions? It has input, name and output and D nicely presents you
with

double[] createArray(int size) {...}

This is as little typing as you can get while keeping readability.

And here is a basic Rust function

fn add_one(x: i32) -> i32 {...}

What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and
unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same
size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and
for Rust they will google. To top that, you have also -> because of the type
after the definition scheme. Needless verbosity, same thing in Scala.

What about Rust unable to drop parenthesis after a function?

self.host_addr.clone()

Should I mention Rust's UFCS?

But I am nitpicking, right. This doesn't make a language bad in any way.
However, as I said, Rust readability is pretty subpar in addition to already
steep language learning curve.

~~~
vvillena
> Subjectively, I see no point in having "val", "var", "let", "def", "fn"
> symbols which bring only noise to code.

Usually, the reason is to make parsing easier. C++ is infamous for having
undecidable grammar. Ruby is extremely pleasing to the eye, but its grammar is
a clusterfuck. Newer languages have learned from that, so they try to have
simpler grammars.

Another reason for those small syntax markers is to avoid implicit language
decisions. In Rust, having to write one of "let/let mut/const" means forcing
the programmer to make an explicit choice regarding mutability and memory
usage. In Scala, "val/lazy val/var/lazy var/def" means having to think about
mutability and evaluation times.

> What about Rust unable to drop parenthesis after a function?

In the case of Rust, the reason is uniformity. Even Scala, of all languages,
is walking back on the optional parentheses, because the language allows to
define functions with multiple argument lists, and optional parentheses
introduce ambiguity between functions with empty argument lists and functions
with no argument lists.

~~~
tastyminerals2
Yes, "make an explicit choice regarding mutability" can be done even easier by
actually writing "immutable double[] arr = [1, 2, 3];", "const double[] arr =
[1, 2, 3];". See, no Scala val/var which to a person who doesn't know the
language tell nothing. When the language grammar is unambiguous and coherent
you have faster compiling times and occasionally better readability. D hits a
nice spot in here by capitalizing on C++ mistakes.

"optional parentheses introduce ambiguity" \-- true, they do. However, I am
struggling to understand why it is necessarily a bad thing? For a user I see a
clear convenience of being able to write "double[] zeroArr = arr.zeros;" or
"double[] newArr = 6.iota.sliced(3, 2).array.reverse.dropOne.join;". And if
that is not enough, you can also inject your custom method into this chain and
it will just work. Don't know about Rust but Scala simply refuses to compile
in such cases which for a functional language looks like a limitation.

These are the D features that I really enjoy.

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

~~~
tastyminerals2
True. But unlike C++ or Rust, D is not a difficult language at all. You can
easily understand when and how not to use GC. Which data structures require
allocation and which can circumvent it. There is an ongoing work to make std a
@nogc compatible. There is an excellent community of professionals to learn
from. The problem is, it is small and resources are scarce. If only D had a
bigger company backing it up...

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

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

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

------
teleforce
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](http://erdani.com/hopl2020-draft.pdf)

[2][https://hacks.mozilla.org/2019/02/rewriting-a-browser-
compon...](https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-
rust/)

~~~
blackrock
Chrome may be using a lot of active memory, but I don’t think it’s a result of
poor programming practices. So I don’t see how switching to Rust would solve
the problem. Unless Chrome has a memory leak problem.

If anything, Chrome can just offload the contents of the unused tabs to the
hard drive, and reload it when it becomes active again. But this will require
a massive architectural change to the core program itself.

~~~
jonahbenton
Web pages have memory leaks, not Chrome itself.

Side note, but at least on linux, with both Chromium and Firefox, you can
observe exactly this behavior- tab-based segregated memory management. The
work was done on both engines over the past several years, works beautifully
now.

The content of each tab lives in a separate process. Kill the process, see the
tab marked failed in the UI. Reload the tab, see a corresponding process spin
back up.

I keep dozens of tabs open and periodically kill the ones that creep to the
top of ram use, both wired ram and virtual. Keeps me from going into swap.

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

~~~
ponce
This is really quite common thinking in D.

I was writing a library and a contributor popped out of nowhere. He didn't
knew D. The first patch it suggested was about parsing some JSON at compile-
time.

It turned out std.json the stdlib parser was able to parse at compile-time in
CTFE context. So, the contributor parsed JSON at compile-time without his
knowledge, without really knowing D, and the fact it worked was accidental
(since the parser was n't specially designed to do that, but could).

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

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

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

~~~
welkam
The language doesn't tell you what to use. You choose what to use.

~~~
gaze
for something as fundamental as garbage collection, the last thing I want is a
choice.

~~~
EvenThisAcronym
Then use garbage collection; it's an easy default.

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

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

~~~
ckcheng
Is there much choice though in terms of jobs? I mean, is it worth learning D
vs rust? I'm actually thinking about that nowadays, for what to learn next..

~~~
pjmlp
In terms of jobs I guess Rust has the edge, including all major ones in
desktop, server and mobile OSes, there are still some companies using D
though.

[https://dlang.org/orgs-using-d.html](https://dlang.org/orgs-using-d.html)

So if getting a job is your major learning motivation, then I guess Rust has
definitely the edge there.

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

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

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

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

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

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

~~~
viraptor
> Why don't we have a single language so that we can do cross platform
> development and abandon web browsers and javascript?

What does that even mean? What do you lack in regards to cross-platform from
Java / Rust / Nim / Go / Python / Ruby / Haxe / ...? (I'm assuming cross-
platform here means desktops, not microprocessors)

Specifically, yes, there are things that you may miss in every one of them,
but it's not like we don't have the option to use them. What's the point in
complete unification in the first place?

~~~
thrwaway69
He means cross platform ui frameworks. Afaik, only flutter has support for
most platforms. It supports web, desktop and mobile.

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

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

------
claudiug
\- bad or missing tooling

\- no clear direction

\- no vision

\- no ide

\- no big company

\- bad or missing documentation

~~~
tastyminerals2
* bad or missing tooling - true, it's missing but I wouldn't say it is bad

* no clear direction - agree

* no vision - there is but not well maintained unfortunately [https://wiki.dlang.org/Vision/2018H1](https://wiki.dlang.org/Vision/2018H1)

* no ide - VS Code with D plugin works pretty well these days. There is an IDE written fully in D too.

* no big company - true, but there are a bunch of successful smaller ones.

* bad or missing documentation - not true, std documentation is pretty good and is gradually improved.

And don't forget that notwithstanding the lack of people and corporate funding
(D is crowd-funded), you get a language that attempts to rival the big guys
and frequently outplay them. Now, imagine the results given the resources were
equal.

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

~~~
elygre
If that is indeed the answer (and I don’t think it is), perhaps try to answer
the question “why isn’t there a similar movement for D?”

~~~
crazypython
Because we have a movement called "Make the D compiler compatible with all C++
code" [https://wiki.dlang.org/Calypso](https://wiki.dlang.org/Calypso)

