No memory safety in D though. That's a pretty big deal for those of us coming from high-level languages who are not used to dealing with such issues.

I can deal with a fussy compiler that makes me write code in a certain way. But a langauge that compiles fine then segfaults or worse at runtime is far more trouble than it's worth (and requires me to make a big upfront time investment before I can start writing production ready code)

> No memory safety in D though.

Not true. Even ignoring the GC we have compiler checked semantics for an increasingly large subset of features, and the language has had ways of managing code that is safe, unsafe, or trusted for years and years now.

As a newly minted employee of the D foundation, I am aiming to work to expand the memory safety features D has.

Is there a way to make it safe-by-default, such that I can't accidentally stray beyond what the compiler can prove safe?

There was a proposal to do just that in our DIP (D improvement proposal) pipeline that nearly made it but it (probably correctly) received enormous backlash.

However, if you use @safe (that's the attribute) the compiler will hard-error if you call any code that you use that isn't explicitly also either @safe or @trusted.

There is also DIP1000 and DIP1021 which both loosen @safe semantics to perform semantic analysis to allow safe memory behaviour (A small borrow checker in effect, this will hopefully be bigger soon).

Try accessing a struct property that isn't in the declaration, or accessing a value after it has been freed (out of scope). You'll get a compile error.

D has lots of memory safety features. It is not the same set of features as Rust. It's wildly incorrect to suggest that Rust has a monopoly on memory safety.

Haha. True! I knew about D, but I forgot about it[0]. (I also know extremely little about it.) ;w; I feel bad.

That code is as beautiful as it is incomprehensible.

0: https://youtu.be/_P5BOietpDY

I agree. The D program is cool, but pretty cryptic. A simple Rust version [0] is only 21 lines yet much more readable in my opinion. I'd take readability over a couple less loc anyday.

[0]: https://play.rust-lang.org/?version=stable&mode=debug&editio...

The `op.parse()` at line 7 was a little hard to understand for me at the beginning. Only a few seconds after, I understood it was `op.parse::<f64>()` with the type parameter inferred from the type of `stack`, but I think it's easier to understand with the explicit type annotation (the turbofish) than without it.

You miss the point of the original one. When I wrote it the idea was that it is functionally pure and guaranteed to be such by the compiler (the annotation was removed because readln is not pure for obvious reasons).

Most uses of loops break down to map, fold, or similar being able to use them cleanly can avoid a lot of bugs and API plasticity.

There's nothing stopping you from doing a functional style in Rust, neither: https://play.rust-lang.org/?version=stable&mode=debug&editio...

There is a function on nightly that would make line 16 a little nicer, but oh well.