Hacker News Reader

Comment by qznc | Hacker News Reader

D is easier than Rust and safer than C++. That is a valuable point IMHO.

And it also interfaces very nicely with C/C++ libraries and code.

There's a wide range of possibilities int that statement that include the case where you would almost always want D over Rust, and the case where you would almost never want D over Rust.

The question is, how much easier is D than Rust, and how much safer is D than C++.

D recently has been substantially upgraded to prevent memory corruption bugs. I'll be talking about how that works at DConf in 3 weeks.

There is no quantitative metric for safety and easyness.

If you can afford a garbage collector, D easily wins over Rust. If you really need the safe manual memory management, Rust wins. In between is still a large grey area.

There are plenty of reasons why Rust could win outside of requiring safe manual memory management. It is an expression based language with ad-hoc polymorphism, algebraic data types, hygienic macros, first class functions, and race-free concurrency.

I don't use rust because I don't need manual memory management and I require subtype polymorphism for a lot of things, but I choose Scala over D.

Neither Rust nor Scala hold a candle to D in terms of compile-time introspection. You can do things with it that are near unbelievable - "you must ask yourself if some law of nature was broken" quoted from memory in http://dconf.org/2015/talks/alexandrescu.html

Scala developers can do whatever they want or need at compile-time.

> race-free concurrency

Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.

Could you give an example of a kind of race conditions allowed in Rust?

(Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)

The "data race" term is jargon (i.e. means more than just "race on data") that specifically refers to unsynchronised concurrent accesses to a piece of memory/resource (where at least one of the accesses is a write), while a race condition is a higher level thing, where things aren't ordered the way one intends, even if they have the appropriate "low-level" synchronisation to avoid data races. http://blog.regehr.org/archives/490

Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).

Rust does not prevent all race conditions because doing so would be impossible. It would be akin to solving the halting problem.

Deadlocks, and other synchronization issues are just some 'general race conditions' Rust can't solve.

Rust's prevents 'data races' defined as:

-two or more threads concurrently accessing a location of memory

-one of them is a write

-one of them is unsynchronized

https://doc.rust-lang.org/nomicon/races.html

I recently (past few years) invested in learning Clojure, enough to get some practical things deployed, but I am far from being a Clojure advanced developer. I wanted to learn a Lisp dialect and am glad I chose Clojure. Rich Hickey is a guru. I don't have any gripes with Clojure but I'm not too deeply invested. Several years ago I was also enamored with Julia, which I was investigating for CPU intensive programs, but never had the time to commit and I was concerned about Julia being too youthful and possibly not getting enough traction. Should I learn D for CPU intensive programs? Also, with Clojure I can make use of the many Java libraries for I/O due to Clojure's good Java interop. Does D have the analogous benefit of tried and tested I/O libraries? Thanks for any suggestions, D has my intrigued.

Is the GC mandatory in D? I was under the impression some time ago that D could run GC-free, but the standard library still widely used GC. Did I just misunderstand?

In my understanding, you're overall correct, but they've also been working on reducing that need, making more and more of it work without a GC.

Currently working on making the Exception handling system usable without the GC. Expect it soon.

Great! (and, congrats on the re-licensing.)

You can go easier on the GC or avoid it altogether. See this article and the discussion:

https://news.ycombinator.com/item?id=13914308

You can tag a block @nogc, if you just need to avoid it for a specific part of your program. This can be done with the whole program, but quite a lot of the standard library requires the GC. I should point out that the GC has no problems that affect day to day usage, the stuff people complain about is when it's running for a while (it's conservative atm so it leaks).

If you can tag the entire program @nogc, great.

> If you can afford a garbage collector, D easily wins over Rust.

This is the "the only point of the ownership/borrowing model is to avoid GC" myth that I've been working to kill. Rust's model also gets you data race freedom, to name just one other benefit.

> how much easier is D than Rust

https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hel...

D gets tricky for resource management and avoiding GC.

> how much safer is D than C++.

Bounds checking and default initialization alone fix most memory errors you may have in C++.

I agree it is valuable.

But I still think there are better alternatives now. Depending on your priorities and constraints, OCaml, Go, F#, Scala, and Swift all fit the same description (easier than Rust, safer than C++) and they're in the same realm for performance (slower than C, C++, Rust, etc., but not by much). D could have been there if they had a decade or so with a bigger community.

Sure, but it's not just about whether you fit in the range or not, it's about language design and tradeoffs. Not everyone will appreciate D, but I really think it hits a sweet-spot of language features that I haven't found elsewhere.

I've enjoyed programming in Ocaml, Rust, C++, Haskell, many Lisps, etc. -- they are all excellent languages. But I find (to my own surprise) that I often come back to D when playing with a new design, exactly because of that sweet-spot. I highly recommend giving it a try if you haven't already.

That's fair. I love Scala but hate the JVM and all the compromises Scala has made to shoehorn itself into the JVM. Even though there is now a scala-native, I'd still probably not use it until it matures to the level that D is at, and D (or OCaml) would probably be a better choice for me for those usecases.

D certainly has made a few mistakes and having a non-free backend in dmd was one of them. I doubt this could have been avoided though. It was just technical debt, which Symantec now graciously payed off. I have great respect for the Rust people, because it seems they do everything right so far.

I am a sucker for language discussions, so let me explain what my problems are with your suggestions.

Ocaml: No support for parallelism, community is even smaller than D, do they have a package manager, yet?

Go: I like generics/templates. If I throw away type safety, I might as well use Python.

F#: I use Linux. The .NET ecosystem is not strong here.

Scala: I don't like the JVM. Also, the Scala compiler is slow.

Swift: Solid ideas, but held back by Object-C compatibility. I don't build iOS apps, so why bother.

yes, ocaml has opam as a package manager now. the community has also grown quite a bit recently.

There are many languages that fit certain general descriptions, but that doesn't mean that the experience of using them will lead me to think they are at all comparable in terms of how well they help me solve the kind of problems I face. Go and Scala - I somehow dont think they are close substitutes for each other. The kind of person that likes D's generics will not be the kind that is ultra happy with Go. The kind that likes the short learning curve and plethora of network libraries in Go might not be thrilled by D early experience. It all depends.

I recently invested in learning Clojure, enough to get some practical things deployed, but I am far from being a Clojure advanced developer. I wanted to learn a Lisp dialect and am glad I chose Clojure. Rich Hickey is a guru. I don't have any gripes with Clojure but I'm not too deeply invested. Several years ago I was also enamored with Julia, which I was investigating for CPU intensive programs, but never had the time to commit and I was concerned about Julia being too youthful and possibly not getting enough traction. Should I learn D for CPU intensive programs? Also, with Clojure I can make use of the many Java libraries for I/O due to Clojure's good Java interop. Does D have the analogous benefit of tried and tested I/O libraries? Thanks for any suggestions, D has me intrigued.

Reply on news.ycombinator.com