4 ms·

> Our choice of D was based on three criteria: syntax similarity to the C programming language, interoperability with C programs and high performance generated

by emccue 4y ago

> Our choice of D was based on three criteria: syntax similarity to the C programming language, interoperability with C programs and high performance generated code. I'm a bit perplexed tying to figure out how any of these criteria is a reason to choose D over rust

estaniloiu 4y ago
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.
- spease 4y ago
  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.
  - alphaglosined 4y ago
    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.
  - ttkciar 4y ago
    > 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.
  - 1980phipsi 4y ago
    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).
  - ediblelint 4y ago
    Apparently D is in the middle of adding an ownership system that would not require GC for safety: https://dlang.org/spec/ob.html https://dlang.org/spec/ob.html
    - destructionator 4y ago
      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.
  - destructionator 4y ago
    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.
    - petre 4y ago
      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.
  - gallier2 4y ago
    Tell me you haven't read the paper without saying you haven't read it.
Shorel 4y ago
I'm a bit perplexed the first comment in any D-lang post is always about Rust or about Nim.
- klyrs 4y ago
  Don't forget zig! (which is, coincidentally, the language I'd do this in -- but I see little value to such nitpicking)
- ttkciar 4y ago
  Rust has a very enthusiastic following, and D is perceived as interloping on "their" territory because it is good at a lot of the same things.
  - deleted 4y ago
    [deleted]
cesarb 4y ago
> I'm a bit perplexed tying to figure out how any of these criteria is a reason to choose D over rust The first one (syntax similarity to the C programming language) is obviously a valid reason to prefer D over Rust for Linux kernel programming (which mostly uses a dialect of C). The other two (interoperability with C programs and high performance generated code) are a necessity for a programming language to be considered for Linux kernel programming (and Rust scores highly on both). So the first criteria would favor D, while the other two would be neutral between D and Rust. (There probably are other criteria, outside these three, which favor Rust over D, given that Rust support has already been tentatively merged into the Linux kernel.)
- 8jy89hui 4y ago
  It has taken huge amounts of work to get the Rust ecosystem to where it is. Even still, it has huge regions where it is immature. Is anyone in the D community able to talk about how mature the ecosystem is? I had always assumed (perhaps naively) that not many people used D and that it was a bit esoteric…? Not to offend anyone. Kind of like F. Should developers be investing time into learning D?
  - ttkciar 4y ago
    D has been around for 21 years. It has had a compiler in the gcc project (gdc) for four years. It debugs easily enough under gdb. Several editors support D syntax (including geany and vscode). It has quite a few libraries (though its interoperability with C libraries has muted native D library development somewhat), centralized at https://code.dlang.org/ https://code.dlang.org/ Are there specific parts of the ecosystem you worry about not being mature? As for it being a bit esoteric, yes, it's not a very widely known language, though I'm not sure why. I fell in love with it in 2018, and it has thoroughly spoiled me for writing C.
    - Conscat 4y ago
      One big issue with D compared to Rust for performance-oriented code is the lack of move semantics. Rust and C++ idiomatically almost never rely on copy-on-write, whereas D so far has a lot of it. I'm not sure how much this matters for kernel modules, but I imagine that it is something users would consider. I had seen some proposals for move semantics in D, so for all I know this is under works right now.

by emccue 4y ago

estaniloiu 4y ago

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.

spease 4y ago
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.
- alphaglosined 4y ago
  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.
- ttkciar 4y ago
  > 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.
- 1980phipsi 4y ago
  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).
- ediblelint 4y ago
  Apparently D is in the middle of adding an ownership system that would not require GC for safety: https://dlang.org/spec/ob.html https://dlang.org/spec/ob.html
  - destructionator 4y ago
    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.
- destructionator 4y ago
  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.
  - petre 4y ago
    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.
- gallier2 4y ago
  Tell me you haven't read the paper without saying you haven't read it.

Shorel 4y ago

I'm a bit perplexed the first comment in any D-lang post is always about Rust or about Nim.

klyrs 4y ago
Don't forget zig! (which is, coincidentally, the language I'd do this in -- but I see little value to such nitpicking)
ttkciar 4y ago
Rust has a very enthusiastic following, and D is perceived as interloping on "their" territory because it is good at a lot of the same things.
- deleted 4y ago
  [deleted]

cesarb 4y ago

> I'm a bit perplexed tying to figure out how any of these criteria is a reason to choose D over rust The first one (syntax similarity to the C programming language) is obviously a valid reason to prefer D over Rust for Linux kernel programming (which mostly uses a dialect of C). The other two (interoperability with C programs and high performance generated code) are a necessity for a programming language to be considered for Linux kernel programming (and Rust scores highly on both). So the first criteria would favor D, while the other two would be neutral between D and Rust. (There probably are other criteria, outside these three, which favor Rust over D, given that Rust support has already been tentatively merged into the Linux kernel.)

8jy89hui 4y ago
It has taken huge amounts of work to get the Rust ecosystem to where it is. Even still, it has huge regions where it is immature. Is anyone in the D community able to talk about how mature the ecosystem is? I had always assumed (perhaps naively) that not many people used D and that it was a bit esoteric…? Not to offend anyone. Kind of like F. Should developers be investing time into learning D?
- ttkciar 4y ago
  D has been around for 21 years. It has had a compiler in the gcc project (gdc) for four years. It debugs easily enough under gdb. Several editors support D syntax (including geany and vscode). It has quite a few libraries (though its interoperability with C libraries has muted native D library development somewhat), centralized at https://code.dlang.org/ https://code.dlang.org/ Are there specific parts of the ecosystem you worry about not being mature? As for it being a bit esoteric, yes, it's not a very widely known language, though I'm not sure why. I fell in love with it in 2018, and it has thoroughly spoiled me for writing C.
  - Conscat 4y ago
    One big issue with D compared to Rust for performance-oriented code is the lack of move semantics. Rust and C++ idiomatically almost never rely on copy-on-write, whereas D so far has a lot of it. I'm not sure how much this matters for kernel modules, but I imagine that it is something users would consider. I had seen some proposals for move semantics in D, so for all I know this is under works right now.