6 ms·

> The author is certainly bullish on Rust in general and in low-level development and so am I. While I share your sentiment, I've recently talked to about 5 pe

> The author is certainly bullish on Rust in general and in low-level development and so am I. While I share your sentiment, I've recently talked to about 5 people who write software for low-level, security relevant things in airplanes. Imho the best application for Rust one could think of. None of them had even heard of Rust. But this is highly anecdotal of course.

jksmith 7y ago
But they aren't using Ada?
- Random_ernest 7y ago
  They are mostly using C/C++.
  - ondravn 7y ago
    At my place of work we used to use Ada for most projects. In more recent years a move to C/C++ has been made. Now the trend is towards model-based design, where toolsets such as Simulink or SCADE provide certified code generators or code checkers to remove most of the manual element of generating code from design. Would love to be able to use Rust, but will need to wait for a COTS tool chain that provides certification evidence for DO-178C Level A. Sealed Rust looks to be going that way, but it's no small task.
    - jksmith 7y ago
      https://ferrous-systems.com/blog/sealed-rust-the-pitch/ https://ferrous-systems.com/blog/sealed-rust-the-pitch/
Rayhem 7y ago
I expect people who write low-level, security relevant things are in rather short supply and so they have a pretty hefty workload. Unfortunately, that leaves little room to explore and research new technologies. Moreover, very, very few people look to improve their efficiency by learning entirely new tech stacks.
- Random_ernest 7y ago
  > Moreover, very, very few people look to improve their efficiency by learning entirely new tech stacks. I firmly believe (against the common HN sentiment) that 99% of the developers do exactly 0 exploration of new technology and they couldn't care less (which is their good right). Also not everybody sits in a fancy startup in the Bay-Area and has even the skills or time to adapt. Most developers sit in a big company that has been doing their stuff for 10+ years and are not very susceptible to change. As an anecdotal example, I recently talked to a company that could not figure out why they could not attract talent. They claimed "we are so innovative, we even adapted PostgreSQL". Before that they used csv as their "database".
  - vbezhenar 7y ago
    Isn't your post a bit controversial? You're writing that 99% of the developers don't care about new technologies and then that some company who adapted PostgreSQL can't attract talents. Or they are not happy with those 99% of candidates?
    - Random_ernest 7y ago
      Okay when I reread it, I see your point. I used their wording, in fact they can't attract anyone but they used the word "talent" for anyone that can code.
  - naasking 7y ago
    > I firmly believe (against the common HN sentiment) that 99% of the developers do exactly 0 exploration of new technology and they couldn't care less (which is their good right). Is it though? It certainly is and should be your right to use whatever tools or language you want for your hobby projects on your own time, but in a professional setting or for production products, I think there's an argument to be made that software developers should have significant constraints on the sorts of tools and languages they should be permitted to use (domain-specific of course).
simias 7y ago
These industrial projects tend to have a massive amount of inertia (which is probably a good thing overall, you don't want people to migrate your plane autopilot to React.js because it's fashionable) so it doesn't surprise me that experienced devs who only deal with these codebases and don't lurk on HN aren't exposed to Rust. If your used to web technology standards Rust being stable since 2015 makes it a mature tool. Almost outdated really. On the other hand if at your work C99 is still new and shiny Rust is basically brand new tech which might be worth looking into in a few years. People who work on long term, critical projects want boring, reliable tools.
rapsey 7y ago
That is I assume a heavily regulated and standard-compliant industry. You can't just pick any language you want. Rust is obviously not certified for such use and I would assume they can only pick something that is. Them never hearing about Rust does not really speak to anything.
adrianN 7y ago
Wait about thirty years and Rust might be "mature" enough to enter such conservative industries.
daxfohl 7y ago
There's a number of reasons. Anything in a regulated industry like that has to have everything approved by regulators. The whole compiler toolchain, all libraries, blah blah. All have to be certified versions before you can use them. You can't just pick up github latest compiler and expect to ship a safety critical device with it. Coders in regulated industries may have never even heard of github, much less rust. Different mindset. Second, it's typically not x86 architectures. They'll have a specific CPU or SOC that they use, from a specific vendor, and other specific vendors that provide the (certified) compiler and possibly RTOS that is used to target that CPU. Those vendors have decades of investment in their C code. Some small change in the asm rust produces vs c (and I'd expect the difference to be much more than a small change) could just break everything in a finely tuned RTOS. Third (and last one I can think of offhand), there are tons of things like static analyzers and such that can be used against C code and have been developed over decades to find many of the things Rust has built in. They're not as good as Rust at some things but better in others. Oh, fourth, these companies already have huge codebases and libraries they've already written and are used to. Rewrites / refactors are less common in regulated industries because of all the documentation they require. Okay, fifth, and perhaps the biggest one, at least in my experience, we didn't ever malloc / new in the app code anyway, because of the potential for out of memory errors. We created a couple big buffers up front and used those exclusively. So rust's ownership model wouldn't even help there iiuc. I imagine most safety critical devices are similar? None of this is to say that Rust will never be useful in a regulated context, but it has a lot of hurdles to jump.
- pjmlp 7y ago
  For example Frama-C.
- Ar-Curunir 7y ago
  Rust’s ownership model isn’t useful just for heap-allocated things; it’s useful for all kinds of other safety guarantees, such as preventing unnecessary mutability.
  - steveklabnik 7y ago
    To elaborate on this, nothing about ownership or borrowing has anything directly to do with heap or stack allocation. Allocation fits into the ownership and borrowing rules, not the other way around.
zozbot234 7y ago
You may be interested in the 'Sealed Rust' initiative by Ferrous Systems GmbH, which does aim to introduce some version of Rust to traditional 'safety-critical' domains - see https://github.com/ferrous-systems/sealed-rust/tree/master/posts https://github.com/ferrous-systems/sealed-rust/tree/master/p... for details. A lot of hard work is involved.
bsder 7y ago
Sorry, but Rust is NOT ready for embedded work, yet. The Rust Embedded guys are making great strides and doing great work, but trying to shove Rust into a critical infrastructure piece right now would be counterproductive, anger a lot of people and likely set Rust back. As much as I think Rust is a good thing, the breakpoint is when the big game development companies start using it. That will tell everybody that Rust is "good enough" for actual production work.
jiggawatts 7y ago
The best language for systems like that is ADA, and it's commonly used in avionics and related systems I like to think of Rust as "memory-safe C++ 2.0", but ADA was designed for general robustness. Types like integers can have a valid range assigned to them, etc... To be a truly safe language for hard realtime or embedded purposes, Rust would need a lot of features added. Things like guaranteed maximum stack allocation for function call chains, a proper allocator system, dependent types, and integration with proof systems. Some of that is partly there or being worked on, but there's a lot of gaps. I also regularly see Rust releases with unsafety that can be triggered by safe code. The invariants are being checked (mostly) by hand and mistakes slip through. Worse still, Rust has a tiny standard library, leaving the bulk of what's needed for real software up to the "community". Unfortunately, crates have highly variable quality (coughactixcough) and it's just not a good idea to build something like a jumbo jet's avionics based on L33tHax0r's AwesomeCrate, if you know what I mean. This all goes back to an opinion I've had about programming language design for some years now: It has one of the highest returns on investment of any human endeavour imaginable. It's roughly comparable to the development of a new vaccine. For every feature or quality improvement in a language and its standard library, tens of thousands of programmers benefit, and then billions of end-users benefit indirectly from their improved productivity and higher product quality. Conversely, low investment in the core language translates to enormous inefficiency as many developers are forced to reinvent the wheel. The users then suffer from the square wheels or the round wheels that sometimes fall off. Rust is a low-investment language. Its standard library doesn't hold a candle to something like the JDK or the .NET Framework. For crying out loud, it doesn't natively do: dates, times, guids, decimal/money, TLS, HTTPS, XML, i18n, databases, or even half of what was included in .NET v1.0 back in 2002! They're working on async, which in a basic form was stable in .NET v1.1 (2003) and fully fledged in v4.5 (2012), three years before Rust v1.0! All of those features are provided by crates. Some of which are maintained by one random guy. From Russia. Or China. Or wherever. Some of which have unnecessary unsafety. Some of which have poor design, or don't interop well. Or worse, there's several competing crates and now you have to pick. Or you pick the one that looks right and it's just a wrapper around the C++ library. (There was some guy who was just spamming these out and squatting on the "crate name", forcing the real Rust crates to use less discoverable names.) I like Rust, I do. But answer me this simple question: How do I process XML with Rust? You can start here: https://crates.io/search?q=xml https://crates.io/search?q=xml Which of these many crates is the one that's equivalent to System.Xml in C#? Which one can handle encodings other than UTF-8? Which one can read and write? Which one can handle entities? Which one can validate? Against XSD and DTDs? Do they do XPath? XSLT? Yes? No? Maybe? Partial? Who the fuck knows? Back in the year 2000 I was using Apache Xerces from C++ and then 2 years later with C# v1.0 I was using System.Xml and I could do everything. It's 2020 and I don't think half that list is available from Rust, with or without third party crates. Even if I were to pick one that works now, who's to know that it wasn't written by some university student only to be dropped on the floor and become unmaintained when he gets a Real Job?
senderista 7y ago
Lots of (most?) programmers don't keep up with the field outside their daily work. It's just a job for them (and that's OK!).

jksmith 7y ago

But they aren't using Ada?

Random_ernest 7y ago
They are mostly using C/C++.
- ondravn 7y ago
  At my place of work we used to use Ada for most projects. In more recent years a move to C/C++ has been made. Now the trend is towards model-based design, where toolsets such as Simulink or SCADE provide certified code generators or code checkers to remove most of the manual element of generating code from design. Would love to be able to use Rust, but will need to wait for a COTS tool chain that provides certification evidence for DO-178C Level A. Sealed Rust looks to be going that way, but it's no small task.
  - jksmith 7y ago
    https://ferrous-systems.com/blog/sealed-rust-the-pitch/ https://ferrous-systems.com/blog/sealed-rust-the-pitch/

Rayhem 7y ago

I expect people who write low-level, security relevant things are in rather short supply and so they have a pretty hefty workload. Unfortunately, that leaves little room to explore and research new technologies. Moreover, very, very few people look to improve their efficiency by learning entirely new tech stacks.

Random_ernest 7y ago
> Moreover, very, very few people look to improve their efficiency by learning entirely new tech stacks. I firmly believe (against the common HN sentiment) that 99% of the developers do exactly 0 exploration of new technology and they couldn't care less (which is their good right). Also not everybody sits in a fancy startup in the Bay-Area and has even the skills or time to adapt. Most developers sit in a big company that has been doing their stuff for 10+ years and are not very susceptible to change. As an anecdotal example, I recently talked to a company that could not figure out why they could not attract talent. They claimed "we are so innovative, we even adapted PostgreSQL". Before that they used csv as their "database".
- vbezhenar 7y ago
  Isn't your post a bit controversial? You're writing that 99% of the developers don't care about new technologies and then that some company who adapted PostgreSQL can't attract talents. Or they are not happy with those 99% of candidates?
  - Random_ernest 7y ago
    Okay when I reread it, I see your point. I used their wording, in fact they can't attract anyone but they used the word "talent" for anyone that can code.
- naasking 7y ago
  > I firmly believe (against the common HN sentiment) that 99% of the developers do exactly 0 exploration of new technology and they couldn't care less (which is their good right). Is it though? It certainly is and should be your right to use whatever tools or language you want for your hobby projects on your own time, but in a professional setting or for production products, I think there's an argument to be made that software developers should have significant constraints on the sorts of tools and languages they should be permitted to use (domain-specific of course).

simias 7y ago

These industrial projects tend to have a massive amount of inertia (which is probably a good thing overall, you don't want people to migrate your plane autopilot to React.js because it's fashionable) so it doesn't surprise me that experienced devs who only deal with these codebases and don't lurk on HN aren't exposed to Rust. If your used to web technology standards Rust being stable since 2015 makes it a mature tool. Almost outdated really. On the other hand if at your work C99 is still new and shiny Rust is basically brand new tech which might be worth looking into in a few years. People who work on long term, critical projects want boring, reliable tools.

rapsey 7y ago

That is I assume a heavily regulated and standard-compliant industry. You can't just pick any language you want. Rust is obviously not certified for such use and I would assume they can only pick something that is. Them never hearing about Rust does not really speak to anything.

adrianN 7y ago

Wait about thirty years and Rust might be "mature" enough to enter such conservative industries.

daxfohl 7y ago

There's a number of reasons. Anything in a regulated industry like that has to have everything approved by regulators. The whole compiler toolchain, all libraries, blah blah. All have to be certified versions before you can use them. You can't just pick up github latest compiler and expect to ship a safety critical device with it. Coders in regulated industries may have never even heard of github, much less rust. Different mindset. Second, it's typically not x86 architectures. They'll have a specific CPU or SOC that they use, from a specific vendor, and other specific vendors that provide the (certified) compiler and possibly RTOS that is used to target that CPU. Those vendors have decades of investment in their C code. Some small change in the asm rust produces vs c (and I'd expect the difference to be much more than a small change) could just break everything in a finely tuned RTOS. Third (and last one I can think of offhand), there are tons of things like static analyzers and such that can be used against C code and have been developed over decades to find many of the things Rust has built in. They're not as good as Rust at some things but better in others. Oh, fourth, these companies already have huge codebases and libraries they've already written and are used to. Rewrites / refactors are less common in regulated industries because of all the documentation they require. Okay, fifth, and perhaps the biggest one, at least in my experience, we didn't ever malloc / new in the app code anyway, because of the potential for out of memory errors. We created a couple big buffers up front and used those exclusively. So rust's ownership model wouldn't even help there iiuc. I imagine most safety critical devices are similar? None of this is to say that Rust will never be useful in a regulated context, but it has a lot of hurdles to jump.

pjmlp 7y ago
For example Frama-C.
Ar-Curunir 7y ago
Rust’s ownership model isn’t useful just for heap-allocated things; it’s useful for all kinds of other safety guarantees, such as preventing unnecessary mutability.
- steveklabnik 7y ago
  To elaborate on this, nothing about ownership or borrowing has anything directly to do with heap or stack allocation. Allocation fits into the ownership and borrowing rules, not the other way around.

zozbot234 7y ago

You may be interested in the 'Sealed Rust' initiative by Ferrous Systems GmbH, which does aim to introduce some version of Rust to traditional 'safety-critical' domains - see https://github.com/ferrous-systems/sealed-rust/tree/master/posts https://github.com/ferrous-systems/sealed-rust/tree/master/p... for details. A lot of hard work is involved.

bsder 7y ago

Sorry, but Rust is NOT ready for embedded work, yet. The Rust Embedded guys are making great strides and doing great work, but trying to shove Rust into a critical infrastructure piece right now would be counterproductive, anger a lot of people and likely set Rust back. As much as I think Rust is a good thing, the breakpoint is when the big game development companies start using it. That will tell everybody that Rust is "good enough" for actual production work.

jiggawatts 7y ago

The best language for systems like that is ADA, and it's commonly used in avionics and related systems I like to think of Rust as "memory-safe C++ 2.0", but ADA was designed for general robustness. Types like integers can have a valid range assigned to them, etc... To be a truly safe language for hard realtime or embedded purposes, Rust would need a lot of features added. Things like guaranteed maximum stack allocation for function call chains, a proper allocator system, dependent types, and integration with proof systems. Some of that is partly there or being worked on, but there's a lot of gaps. I also regularly see Rust releases with unsafety that can be triggered by safe code. The invariants are being checked (mostly) by hand and mistakes slip through. Worse still, Rust has a tiny standard library, leaving the bulk of what's needed for real software up to the "community". Unfortunately, crates have highly variable quality (coughactixcough) and it's just not a good idea to build something like a jumbo jet's avionics based on L33tHax0r's AwesomeCrate, if you know what I mean. This all goes back to an opinion I've had about programming language design for some years now: It has one of the highest returns on investment of any human endeavour imaginable. It's roughly comparable to the development of a new vaccine. For every feature or quality improvement in a language and its standard library, tens of thousands of programmers benefit, and then billions of end-users benefit indirectly from their improved productivity and higher product quality. Conversely, low investment in the core language translates to enormous inefficiency as many developers are forced to reinvent the wheel. The users then suffer from the square wheels or the round wheels that sometimes fall off. Rust is a low-investment language. Its standard library doesn't hold a candle to something like the JDK or the .NET Framework. For crying out loud, it doesn't natively do: dates, times, guids, decimal/money, TLS, HTTPS, XML, i18n, databases, or even half of what was included in .NET v1.0 back in 2002! They're working on async, which in a basic form was stable in .NET v1.1 (2003) and fully fledged in v4.5 (2012), three years before Rust v1.0! All of those features are provided by crates. Some of which are maintained by one random guy. From Russia. Or China. Or wherever. Some of which have unnecessary unsafety. Some of which have poor design, or don't interop well. Or worse, there's several competing crates and now you have to pick. Or you pick the one that looks right and it's just a wrapper around the C++ library. (There was some guy who was just spamming these out and squatting on the "crate name", forcing the real Rust crates to use less discoverable names.) I like Rust, I do. But answer me this simple question: How do I process XML with Rust? You can start here: https://crates.io/search?q=xml https://crates.io/search?q=xml Which of these many crates is the one that's equivalent to System.Xml in C#? Which one can handle encodings other than UTF-8? Which one can read and write? Which one can handle entities? Which one can validate? Against XSD and DTDs? Do they do XPath? XSLT? Yes? No? Maybe? Partial? Who the fuck knows? Back in the year 2000 I was using Apache Xerces from C++ and then 2 years later with C# v1.0 I was using System.Xml and I could do everything. It's 2020 and I don't think half that list is available from Rust, with or without third party crates. Even if I were to pick one that works now, who's to know that it wasn't written by some university student only to be dropped on the floor and become unmaintained when he gets a Real Job?

senderista 7y ago

Lots of (most?) programmers don't keep up with the field outside their daily work. It's just a job for them (and that's OK!).