News for hackers. Stuff that matters.
Re:DConf 2019 in London by atilaneves on Friday February 15, 2019 @08:35AM (#19170764)
Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that, but now there's [DIP1000](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). D can however be used without a GC if needed.

Rust has macros, which D doesn't, but D's metaprogramming is superior.

They're both fine choices.

Re:DConf 2019 in London by Hasknewbie on Friday February 15, 2019 @01:31PM (#19173420)
> D can however be used without a GC if needed

Honest question: is it the case in practice though? Last time I checked D, you could disable the GC in theory, but in practice many things would fail to work, most importantly their standard library. As this been fixed since then?

Re:DConf 2019 in London by atilaneves on Monday February 18, 2019 @12:27PM (#19192323)
Yes, it's the case in practice: I've written a lot of @nogc code. Some parts of the standard library require the GC, but not all of it, and the parts that I usually use are fine (std.algorithm, std.range, ...).

Since allocators landed, it's been a lot easier, and I've written a library that does C++-style smart pointers for D:

https://github.com/atilaneves/automem

Re:DConf 2019 in London by jetzzz on Friday February 15, 2019 @08:46AM (#19170842)
> Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that

Isn't D memory unsafe by default?

Re:DConf 2019 in London by atilaneves on Friday February 15, 2019 @09:42AM (#19171253)
> Isn't D memory unsafe by default?

Yes, but it only takes this to guarantee it:

void main() @safe { // ... }

Re:DConf 2019 in London by earenndil on Friday February 15, 2019 @10:27AM (#19171612)
Not quite, that doesn't guard for safety in things like module constructors.