6 ms·

FTA "Based on our findings we can conclude that Rust is a very well-suited programming language for writing network drivers. It is not only a fast and safe sys

by delta1 8y ago

FTA "Based on our findings we can conclude that Rust is a very well-suited programming language for writing network drivers. It is not only a fast and safe systems programming language but was also voted most beloved programming language in 2016, 2017 and 2018 [15, 16, 17]. Writing more drivers in Rust would certainly lead to safer and more reliable computer systems." Working link to their code: https://github.com/ixy-languages/ixy.rs https://github.com/ixy-languages/ixy.rs

Xophmeister 8y ago
How is “most beloved” a prerequisite to writing network drivers? Don’t get me wrong, if Rust is a good technical fit, then that’s great, but so convince me on those objective measures.
- specializeded 8y ago
  As a human who’ll be writing X, I sometimes enjoy the perspective of other humans who write X.
- nothrabannosir 8y ago
  Popularity influences ecosystem which influences programs written in the language. A language is more than just its spec. Larger mind share improves availability and quality of 3rd party libs, features, performance and quality of the compiler, brain power to guide the language forward, etc. It's the second order effects that matter.
- simias 8y ago
  "Most beloved" is a weird way to put it but if it's a way to gauge the state of the language's ecosystem I'd say it's a very practical concern. For instance these past few days I've been writing a small bootloader for some embedded ARM chip. I pondered going with Rust but ended up using C for two main reasons: - I know that if it's doable in Rust it's doable in C but the opposite is not always true (or straightforward). In particular bare-metal/very low level Rust is still somewhat experimental, you can't use stable Rust if you want to be able to use inline ASM or other advanced features. I have very tight constraints regarding code size and memory use and I was concerned that I might not control that as effectively with Rust code than with C. - There's already a bunch of C code written for this chip that I can reuse without any friction (no binding generation, no ffi etc...). The vendor even provides a huge header file with the full memory map and some code to init the PLLs. If you're coding in a vacuum then how "beloved" a language is is mostly irrelevant but if you want to benefit from the ecosystem then having a language that people want to use and support is extremely important. The tooling will mature and stabilize as more and more people use Rust to write bare-metal code and device drivers, which will eventually make my first point above irrelevant. Then if the language becomes popular enough it will be easier to find Rust code or pre-made crates to do what you want which will hopefully eventually solve my 2nd issue.
  - hra5th 8y ago
    What ARM chip are you considering this for? Is it a Cortex M?
    - simias 8y ago
      No, Cortex A in an Arria10 SoC. The boot process is tedious because you have to load the FPGA before you can access the external RAM so the stage 1 bootloader has to fit 256KB code+data. Currently I'm using a multi-stage U-Boot but for simplicity and robustness I'd like to cram everything in a single stage loader. Since I can't get u-boot to create a small enough image with all the features that I want (and also because I want to add vendor-specific customizations on top) I decided to try and rewrite a small, single purpose loader from scratch. I considered Rust but then that meant that I'd have to port or rewrite all of u-boot's code I want to reuse (especially the vendor code contributed by Altera mentioned in the previous post). So C it is.
- rsynnott 8y ago
  "People like it" is a major positive. Compare to C++, which often gets neglected in favour of C even in cases where it would probably be better, because most people _hate_ it.
  - lenocinor 8y ago
    I don't think most people hate C++. They certainly didn't at my last job, especially with the awesome new additions to the language (which granted aren't any good if you can't use them, but we could). Still, I do think you're right that a significant number of people hate C++, so I think your point is still valid.
    - rsynnott 8y ago
      Most peoples' experience of C++ is from long before C++17 or even C++11 were usable. I'd agree that someone encountering modern C++ for the first time today, or willing to give it a second chance, might end up quite liking it, but if your first exposure was to an older code-base, that would put you off very easily.
- coldtea 8y ago
  Objective measures aren't the only ones that matter when one does a job. Heck, in some industries, like aviation, even something subjective like boredom can kill.
masklinn 8y ago
Somewhat related: Brian Cantrill's "Is it time to rewrite the operating system in Rust?" (https://www.slideshare.net/bcantrill/is-it-time-to-rewrite-the-operating-system-in-rust https://www.slideshare.net/bcantrill/is-it-time-to-rewrite-t...), whose conclusion is (following Betteridge's) "no": > An OS kernel — despite its historic appeal and superﬁcial ﬁt for Rust — may represent more challenge than its worth However it suggests more hybrid approaches: * asm/C kernel with Rust kernel components like drivers and filesystems, Rust can be used for new developments and enable an incremental introduction, mentions a prototype example in freebsd * Rust for non-kernel OS components: an OS is not just a kernel and utilities, daemons, management facilities, debuggers, … bundled as part of the system tend to be more prone to run-time failures than the kernel itself (and more commonly face hostile interactions), making them excellent candidates for Rust * Rust-based firmwares: firmware is "a sewer of unobservable software with a long history of infamous quality problems", some areas of firmware (and kernel) development are weak in rust (e.g. dealing with allocation failure) but that aside it looks amenable to Rust
- ianlevesque 8y ago
  Not worth it to him maybe. I wish someone would. Just this week we found out macOS brought back the “ping of death” due to C’s memory unsafety.
  - masklinn 8y ago
    The issue is in the network layer, which would more than likely fall under hybrid approach 1: kernel modules in rust.
  - coldtea 8y ago
    And you think a macOS written in Rust wont waste tons of money, slow down feature development (until it reaches parity), and introduce new bugs (perhaps not memory safety bugs, but functional and business logic bugs)...
    - wtetzner 8y ago
      I mean, sometimes I wish feature development would slow down. Lately it seems like each release of macOS is worse than the last one. Also, it really comes down to whether or not it's a long-term win. Apple certainly has the capital to make it happen if they decided it was worth it.

by delta1 8y ago

Xophmeister 8y ago

How is “most beloved” a prerequisite to writing network drivers? Don’t get me wrong, if Rust is a good technical fit, then that’s great, but so convince me on those objective measures.

specializeded 8y ago
As a human who’ll be writing X, I sometimes enjoy the perspective of other humans who write X.
nothrabannosir 8y ago
Popularity influences ecosystem which influences programs written in the language. A language is more than just its spec. Larger mind share improves availability and quality of 3rd party libs, features, performance and quality of the compiler, brain power to guide the language forward, etc. It's the second order effects that matter.
simias 8y ago
"Most beloved" is a weird way to put it but if it's a way to gauge the state of the language's ecosystem I'd say it's a very practical concern. For instance these past few days I've been writing a small bootloader for some embedded ARM chip. I pondered going with Rust but ended up using C for two main reasons: - I know that if it's doable in Rust it's doable in C but the opposite is not always true (or straightforward). In particular bare-metal/very low level Rust is still somewhat experimental, you can't use stable Rust if you want to be able to use inline ASM or other advanced features. I have very tight constraints regarding code size and memory use and I was concerned that I might not control that as effectively with Rust code than with C. - There's already a bunch of C code written for this chip that I can reuse without any friction (no binding generation, no ffi etc...). The vendor even provides a huge header file with the full memory map and some code to init the PLLs. If you're coding in a vacuum then how "beloved" a language is is mostly irrelevant but if you want to benefit from the ecosystem then having a language that people want to use and support is extremely important. The tooling will mature and stabilize as more and more people use Rust to write bare-metal code and device drivers, which will eventually make my first point above irrelevant. Then if the language becomes popular enough it will be easier to find Rust code or pre-made crates to do what you want which will hopefully eventually solve my 2nd issue.
- hra5th 8y ago
  What ARM chip are you considering this for? Is it a Cortex M?
  - simias 8y ago
    No, Cortex A in an Arria10 SoC. The boot process is tedious because you have to load the FPGA before you can access the external RAM so the stage 1 bootloader has to fit 256KB code+data. Currently I'm using a multi-stage U-Boot but for simplicity and robustness I'd like to cram everything in a single stage loader. Since I can't get u-boot to create a small enough image with all the features that I want (and also because I want to add vendor-specific customizations on top) I decided to try and rewrite a small, single purpose loader from scratch. I considered Rust but then that meant that I'd have to port or rewrite all of u-boot's code I want to reuse (especially the vendor code contributed by Altera mentioned in the previous post). So C it is.
rsynnott 8y ago
"People like it" is a major positive. Compare to C++, which often gets neglected in favour of C even in cases where it would probably be better, because most people _hate_ it.
- lenocinor 8y ago
  I don't think most people hate C++. They certainly didn't at my last job, especially with the awesome new additions to the language (which granted aren't any good if you can't use them, but we could). Still, I do think you're right that a significant number of people hate C++, so I think your point is still valid.
  - rsynnott 8y ago
    Most peoples' experience of C++ is from long before C++17 or even C++11 were usable. I'd agree that someone encountering modern C++ for the first time today, or willing to give it a second chance, might end up quite liking it, but if your first exposure was to an older code-base, that would put you off very easily.
coldtea 8y ago
Objective measures aren't the only ones that matter when one does a job. Heck, in some industries, like aviation, even something subjective like boredom can kill.

masklinn 8y ago

Somewhat related: Brian Cantrill's "Is it time to rewrite the operating system in Rust?" (https://www.slideshare.net/bcantrill/is-it-time-to-rewrite-the-operating-system-in-rust https://www.slideshare.net/bcantrill/is-it-time-to-rewrite-t...), whose conclusion is (following Betteridge's) "no": > An OS kernel — despite its historic appeal and superﬁcial ﬁt for Rust — may represent more challenge than its worth However it suggests more hybrid approaches: * asm/C kernel with Rust kernel components like drivers and filesystems, Rust can be used for new developments and enable an incremental introduction, mentions a prototype example in freebsd * Rust for non-kernel OS components: an OS is not just a kernel and utilities, daemons, management facilities, debuggers, … bundled as part of the system tend to be more prone to run-time failures than the kernel itself (and more commonly face hostile interactions), making them excellent candidates for Rust * Rust-based firmwares: firmware is "a sewer of unobservable software with a long history of infamous quality problems", some areas of firmware (and kernel) development are weak in rust (e.g. dealing with allocation failure) but that aside it looks amenable to Rust

ianlevesque 8y ago
Not worth it to him maybe. I wish someone would. Just this week we found out macOS brought back the “ping of death” due to C’s memory unsafety.
- masklinn 8y ago
  The issue is in the network layer, which would more than likely fall under hybrid approach 1: kernel modules in rust.
- coldtea 8y ago
  And you think a macOS written in Rust wont waste tons of money, slow down feature development (until it reaches parity), and introduce new bugs (perhaps not memory safety bugs, but functional and business logic bugs)...
  - wtetzner 8y ago
    I mean, sometimes I wish feature development would slow down. Lately it seems like each release of macOS is worse than the last one. Also, it really comes down to whether or not it's a long-term win. Apple certainly has the capital to make it happen if they decided it was worth it.