Hacker News Reader

Comment by estaniloiu | Hacker News Reader

We believe that the D programming language can be a great candidate for writing kernel device drivers in a safe programming language. D is fully compatible with C and mechanically checks, during compilation, the user code for unsafe behavior. The language also boasts powerful compile-time features that make it possible to write highly specific, high performance code.

It also has a smooth learning curve and does not force language features onto the users, allowing them to gradually improve their code base, as they become more comfortable with the language.

We were able to integrate D in the kernel with minimal effort. It took us (a team of 4) 3 months to port the driver to D. We were able to use the existing kernel build system and weren't required to add extra support in the kernel for D.

Both D and Rust are a great step forward to writing safe software. Imhmo, having multiple options to choose from helps developers.

View on HN

Doesn’t D require a GC to achieve the safety guarantees that Rust provides without one, and many third-party libraries require this GC? Just looking over a comparison between them on Reddit.

Memory safety is broken up into a bunch of different categories. It isn't just one feature.

Yes D uses the GC for lifetime issues currently, but it does not need it for doing bounds checking, escape analysis or preventing common issues surrounding pointers. All of which are very useful things to have with or without the GC.

Just those features alone would prevent some pretty big name issues that have cropped up in C code over the years.

> Doesn’t D require a GC to achieve the safety guarantees that Rust provides without one

No. The paper covers this. The authors used D's fat pointers, scope, slices, @safe, and ownership/borrowing features to improve code safety.

It is trivial to turn off D's GC, and the authors did not use it in the project described in their paper.

> and many third-party libraries require this GC?

Yes, a lot of D libraries depend on GC, which means they wouldn't be available for use for kernel development.

The D compiler will error out if D code marked with the @nogc attribute depends on GC (or depends on code dependent on the GC), which makes going GCless easier.

D has attributes @safe and @nogc. You can use @nogc to ensure that your code isn't calling the GC, and (though there are apparently a small number of holes in it) you can use @safe to ensure that your code is memory safe. Of course, if you limit yourself to @safe @nogc code, then you might have some difficulty with the standard library (as well as third-party libraries). There are things that the compiler can statically confirm are safe in Rust, that a D compiler is not yet able to match (there is some work on @live to enable somewhat similar features).

Apparently D is in the middle of adding an ownership system that would not require GC for safety: https://dlang.org/spec/ob.html

That approach is a dead end, incapable of doing anything beyond the basics (notably it doesn't compose into structs) and is likely to be abandoned.

D is realistically somewhere in a middle ground between C and Rust for kernel work. It leans more toward familiarity for C programmers with some added safety checks (indeed, you do lose something by not using a garbage collector, but you can still go a pretty long way without it thanks to auto bounds checks and such) but does not enable as much static checking - nor require as much new learning - as Rust.

D is pretty easy to pick up and get productive in, even compared to C. I imagine it's probably harder to use with @nogc and @safe, but it's still a great improvement over C. On the plus side it integrates nicely with C code and libraries.

Tell me you haven't read the paper without saying you haven't read it.

Reply on news.ycombinator.com