Hacker News Reader

Comment by ZenoArrow | Hacker News Reader

For some languages, that distinction doesn't seem to apply. For example, it seems that the D language can be treated as both a scripting language and a system language, as the speed of compilation + execution can be comparable to that of scripting languages. For evidence of this, take a look at the first D versus Python comparison in this article, note that both scripts have comparable execution times (both finished running in under a second):

http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-sc...

It should be noted that D has a number of different compilers, offering the user the choice between compilation speed and optimisation.

View on HN

There are effectively two Ds: one that's garbage collected and one that's manually memory managed and unsafe. I don't think you can really consider them equivalent: there's always a large difference in development friction when you move from a managed environment to an unmanaged one.

> "There are effectively two Ds"

Could you not also say there are effectively two Rusts?

https://doc.rust-lang.org/book/second-edition/ch19-01-unsafe...

"Rust has a second language hiding out inside of it, unsafe Rust, which does not enforce these memory safety guarantees. Unsafe Rust works just like regular Rust does, but it gives you extra superpowers not available in safe Rust code."

By the way, I don't say this as a criticism, I admire what the Rust team are doing, and will be glad to check out the language again in the future.

You can, but there is a big difference: betterC is a subset of D, whereas unsafe Rust is a superset of safe Rust. That is, when you use unsafe, you don't lose any language features. When you drop into betterC, you do lose a bunch of stuff from D.

You don't have to restrict yourself to betterC to use manual memory management. BetterC is mainly targetted at embedded programming and to port components of existing C applications. Malloc vs. GC vs. stdx-allocator is a separate topic, though betterC doesn't link with the GC by default.

Yes, thanks. Last I checked, you still lose features if you use manual memory management, betterC or no. Has this changed recently?

You loose builtin arrays and hashes and need to use a container library instead. Same goes for newing aggegates which can be replaced with smart pointers. Escaping closures (delegates) no longer works, but you can explicitly capture context in a struct.

Those choices for builtin language features date back to the early inspiration from Java, but are increasingly being replaced with library implementations. We've added escape checking to the type system last year, and are currently working on safe aliasing (preventing use-after-free).

So yes, atm. when opting for @nogc you're somewhat at the frontier, and it's mostly a choice if you have time, hard requirements, or am very practised.

Avoiding most (but not all) GC allocations is already widely adopted in D's community though.

Thank you! I'm excited to see this stuff progress, but since I'm not involved with D anymore, it's hard to keep up at times :)

Reply on news.ycombinator.com