Ask HN: Why do you use Rust, when D is available?

* We don't have templates. Hm. Let's bad mouth them. Let's say templates are too difficult. Agreed.

* We don't have exceptions. Hm. Let's bad mouth them as well. Agreed. That one is easy.

* We don't have much abstractions. Hm. Let's convince new college graduates that they can't handle abstractions anyway. Mwahaha. But waait! New college graduates are actually smarter than us. I know... But we will convince them that they are not. Mwahaha.

There is more but I think I've just earned enough down votes with that much already. :)

But there is one sales sentence I will never forget. Go people said "No major systems language has emerged in over a decade"[1] As a person who was very much into D at that time (and I still am), and as a person who knows how "major" D is, that sentence from the Go people make me see them as either ignorant of the programming language scene or deceitful. Cheap sales tactic at best...

Disclaimer: I used Go professionally for 1 year for a product in the microservices space in 2017-2018. The only thing Go had going for it was the libraries that were already written at least for that space. Whatever we needed was already written for us; we had to wait at most 2 weeks for something that we needed to pop up. There was nothing else in the language that made me want to write in Go.

[1] https://web.archive.org/web/20091114043443/http://golang.org...

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.

I guess what I meant is "vast-majority of devs out there".

I did ~10 years of kernel/embedded myself. Generally people use C++ only when they really have to (like: they work in one of this niches, or want to get a job there). I've experienced myself many times when people would go with anything but C++ because of all it's faults, weaknesses and general infamy. And I also have seen some people that gave Rust a try and it went smoothly. They deliver a proper C++-level performance and resource control, without any of the problems and were happy about the experience.

AAA-game/kernel/embedded are all lucrative (except games, lol), important and not tiny but they are still niche.

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.

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