8 ms·

Over the last couple of months I've been slowly, but steadily playing with Rust. I work on embedded systems and while it's gaining traction only slowly, it feel

by alxlaz 7y ago

Over the last couple of months I've been slowly, but steadily playing with Rust. I work on embedded systems and while it's gaining traction only slowly, it feels to me reasonably likely that we'll be seeing non-trivial applications in the next 8-10 years. I doubt that we'll see it used for low-power/resource-constrained firmware, but lots and lots of embedded systems are now bulky Linux boxes with years of uptime, and I can see Rust making inroads there. It's not a bad idea to be ready for this, just in case it turns out to be a revolution. Honestly, I like it, and for all the non-hyped reasons. Like ownership. Lots of us in the embedded space aren't so impressed by the extra memory safety because, if you allocate all your memory statically, there are fewer ways to screw things up with references, and it's a lot easier to do bounds checking, so fewer bugs slip in. Not that "even fewer" isn't good, it's just that the impact is less dramatic than in application code. But: the borrow checker still pesters me about something I've written every once in a while. And every once in a while, what it pesters me about is a data race that would have definitely bit me in the back sooner or later. It has no security implications, I guess, and it wouldn't crash my program, but it's still wrong. Yay! Or like traits, which are just so refreshingly sane. Lots of people are hung up on security and segfaults, and spend far less time talking about a far less categorical property: the conventions that Rust enforces make it easier to write correct code. Sometimes it's not straightforward code, mind you, but "works right" trumps "fits in a single line" in my book... In many ways, Rust is what C++ could have been if it had not been designed by saying yes to everything. I guess it's not there yet, but there's a chance it might be. On a more, uh, philosophical note, I think it's pretty cool that our industry has been granted a second chance in this regard. We've already been given Ada, and we missed the chance to adopt it on a wide enough scale to make a difference. Maybe we won't miss this chance.

dorfsmay 7y ago
> I doubt that we'll see it used for low-power/resource-constrained firmware I'm curious what your reasoning is for saying this?
- zozbot234 7y ago
  Are you going to use Rust on a PIC12 with 32 bytes of data memory and max 256 code instructions? Of course not. Assembly is still king in this low-powered embedded class and will stay as such for the foreseeable future.
  - brohee 7y ago
    At the 10 year horizon the grandparent was using, the ultra low end of MCU may be substantially more powerful, with possibly lowend AM or RISC V being the smallest thing you can find. At some point, packaging will dominate cost over silicon for such small MCU so a better silicon won't cost much more...
    - zozbot234 7y ago
      Packaging will dominate silicon costs? I see plenty of silicon chips directly soldered onto PCB's for the smallest and cheapest applications, i.e. no packaging whatsoever.
      - brohee 7y ago
        The entity that solders it received it on a tape most likely, in 10 year I can totally see a small 32 bit core costing less that that.
  - wtetzner 7y ago
    Maybe I misread it, but it sounded like the OP was comparing Rust to C or C++ on low-powered/resource-contrained firmware, not assembly.
  - derefr 7y ago
    In that specific case, I’d probably still not use ASM directly, but rather probably a Lisp DSL for machine-code generation (and a Lisp emulator for the ISA it generates), so that I could in turn write some genetic algorithm or somesuch to explore the space of such ASTs (and thereby the space of max-256-byte machine-code programs) to find the optimal way to pack instructions to solve my problem (where “solve my problem” is specified in terms of what the emulator’s registers and memory should look like on a given cycle.) ASM is for the use-case where you're optimizing code in terms of using specific instructions or intrinsics; but it's not really for the case where you're concerned with specific opcode encodings (as ASM abstracts that away, grouping multiple different opcode encodings—some short, some very long—behind a single friendly instruction name.) In that case, you have to work with the machine-code directly—or, at least, through data structures that contain machine-code at the base level, and so can tell you exactly what machine-code they contain.
pron 7y ago
I think that Rust's approach to safety -- soundly eliminate UB in safe code -- comes at the high cost of complexity. This affects how easy it is to write custom compilers (very important in the embedded space), but it is also not necessarily the best way to reduce bugs. For some, this cost is acceptable, and I'm sure some people may even welcome the high-level-looking code [1] that Rust and C++ support, but I think there are better ways, ones that are more appealing in low-level ("systems") programming in general and the embedded space in particular: https://news.ycombinator.com/item?id=21970987 https://news.ycombinator.com/item?id=21970987, https://news.ycombinator.com/item?id=22021237 https://news.ycombinator.com/item?id=22021237 Rust is without a doubt a (much) "better C++" but I'm not sure a better C++ is necessarily what systems programming needs most. [1]: Not that writing that code is as easy as in a high-level language, nor does it offer the same level of abstraction as high-level languages, where changing the details of the implementation does not affect the API and its clients, but it looks high level, or "expressive", on the page.
- alxlaz 7y ago
  > Rust is without a doubt a (much) "better C++" but I'm not sure a better C++ is necessarily what systems programming needs most. I agree but if better C++ is what the PL industry can give me, then I'll take it, thank you very much! (Frankly at this point I'll take anything that isn't C++...)
  - pron 7y ago
    There are alternatives that more appeal to my taste in the works. Given the cost of changing language, any language, I'll wait and see how they turn out before making decisions.
    - jeltz 7y ago
      Which ones are more to your taste? For me it is mostly Zig which seems closer to what I want to see in a language. Crystal also looks promising but I prefer languages without GC. Rust is a good language but it is a bit too complex and restrictive at times.
ComputerGuru 7y ago
We’re already using it in production for embedded development (on stm32 MCUs). So are a lot of other people. It lets you target a niche between spaghetti code on bare metal and structured and full-blown runtime/framework, making something along the lines of reusable libraries for bare metal without a runtime or OS possible via its zero-cost types.
DCKing 7y ago
As someone who never much got into systems programming, Rust feels like a breath of fresh air. It makes systems programming way more accessible for me personally, coming from non-systems languages. Learning to write C well is just not something that appeals to me at all. From mostly an outsiders' perspective, I just don't think C is a very nice programming language. It looks easy to to pick up and it probably is (for some definitions of "pick up"), but I don't think that's a good thing. The language gives you almost nothing. Pointers, structs, arrays, control flow. Not much else. I'm barely exaggerating when I say that all the C code I see looks like a chaotic pointer juggle fest for precisely that reason. The few features and library that it does have come with non-obvious gotchas that will punish you later. Rust is probably much harder to "pick up", and way more complicated in general, but it's just, uh, more language. I'll take pattern matching, encouraging immutability, functional style programming, trait programming over C's simplicity any day of the week. The safety is extremely nice, but I think Rust's biggest eye-opener for me is that all these "higher level" features are just possible at (close to) the performance of C. That makes it very appealing to me.
- pron 7y ago
  > As someone who never much got into systems programming, Rust is a breath of fresh air. I think that's part of the problem :) Because Rust looks high level it appeals to people used to high-level programming. But once you get into systems programming, the issues are different from high-level programming, and you're less happy to pay for features that solve other problems. What I'm saying is, obviously, a matter of taste, and some people doing low-level programming do prefer C++'s high-level feel, which is also found in Rust. I hope it goes without saying that just programming in Rust -- or C++ -- doesn't mean you're doing systems programming unless you're, say, writing a device driver, a kernel, a GC, a game framework etc.
  - orclev 7y ago
    Part of the problem is that "systems programming" is an overloaded term that means a number of different things. Is writing a web browser "systems programming"? What about a CLI utility like grep? Kernel module? Bare metal on a STM32? Depending on who you ask most of those will get both a yes and a no answer. On a related note, some language are more or less suitable for each of those. Can you write an OS in Java? Yes. Should you? Probably not. I think one of the previous comments, and others on other forums have things right when they say that Rust is a better C++. Anything you would consider using C++ for is a good candidate for using Rust for. Rust is not a better C though, it's just a bit too high level for that. There are languages that are aiming to be a better C (Zig is REALLY interesting, but very very new right now), but Rust isn't really one of them. I could very easily see something like an OS aimed at x86 desktops being written in Rust. Desktop systems are beefy enough and the problem space is complex enough that the extra overhead involved in Rust (similar to C++) makes sense. On the other hand if you're doing some bare metal work on something like an Arduino you just don't have enough there to justify the extra overhead and something very basic like C (or assembly, or Zig once it matures a bit more) is probably a better fit. If you're doing anything higher level than kernel programming, Rust is just as viable as anything else, at that point it's mostly down to personal preference on whether you can deal with not having conveniences like garbage collection or not.
ekidd 7y ago
Yeah, some of the nice things about Rust aren't immediately obvious. Professionally, I use Rust for a few specific things: 1. Rust is surprisingly great for making cross-platform CLI tools and shipping static Linux binaries. Everybody can just install a single executable and they're ready to go. (Go is good at this, too.) 2. Rust is great for anything where I ask, "How big a cluster do we need for this?" I get roughly the same speed as C++, except there are far fewer footguns. And I can add threading support to existing code in an afternoon, and I can expect it to just work. 3. Rust's very new async support is powerful in some very interesting ways, and I have a couple of programs that it has worked beautifully for. (I'm working on an upcoming open source release of one of them.) 4. Rust's algebraic data types (aka "enum" and checked "match") are a joy for any software involving lots of special cases and complex logic. I think every typed, high-level language should steal this feature. However, I have mixed experience using Rust for business logic. Yes, item (4) above does help with business logic. But business logic changes a lot, and it needs to be accessible to many developers within an organization. So on my recent team projects, Rust often winds up doing the heavily lifting. But the rapidly-changing business logic will often get deferred to a GCed language. So far, this is working nicely.
- sammorrowdrums 7y ago
  From my experience it's quite a good language for fun experiments and coding challenges, at the very least. I grew to love it quickly during advent of code. The iterators, enums and no Null types lend themselves to interesting solutions. The crate ecosystem is also developing fast, and there are decent browsable docs and bootstrapping the env and development environment are all easy. SDL2 support makes it really easy to make rectangle based games like classic pong and experiment with keyboard and controller inputs etc. (never mind further possibilities of 3D etc). TTY apps and games are also easy to make with the termion crate. I think it's just kind of worth learning in a way that (for example) Python, C and Haskell are complementary options for learning different ways of thinking about of coding. Rust feels like a different flavour of programming. It's borrow checker and branch checking etc. they really are likely to lead to better programming in other languages too. Understanding ownership and considering the transfer of ownership are valuable.
Const-me 7y ago
> lots and lots of embedded systems are now bulky Linux boxes These systems have the resources to run managed runtimes. I’ve shipped embedded software running .NET core 2.2 on ARM Linux (RK3288 with custom set of peripherals), only a minor part of the software being unsafe (a shared library written in C++). Over the last 20 years, desktop GUI software, web servers, and mobile software migrated from C++ towards managed languages, and they never looked back. I’m pretty sure the majority of embedded software gonna follow the same path.

by alxlaz 7y ago

dorfsmay 7y ago

> I doubt that we'll see it used for low-power/resource-constrained firmware I'm curious what your reasoning is for saying this?

zozbot234 7y ago
Are you going to use Rust on a PIC12 with 32 bytes of data memory and max 256 code instructions? Of course not. Assembly is still king in this low-powered embedded class and will stay as such for the foreseeable future.
- brohee 7y ago
  At the 10 year horizon the grandparent was using, the ultra low end of MCU may be substantially more powerful, with possibly lowend AM or RISC V being the smallest thing you can find. At some point, packaging will dominate cost over silicon for such small MCU so a better silicon won't cost much more...
  - zozbot234 7y ago
    Packaging will dominate silicon costs? I see plenty of silicon chips directly soldered onto PCB's for the smallest and cheapest applications, i.e. no packaging whatsoever.
    - brohee 7y ago
      The entity that solders it received it on a tape most likely, in 10 year I can totally see a small 32 bit core costing less that that.
- wtetzner 7y ago
  Maybe I misread it, but it sounded like the OP was comparing Rust to C or C++ on low-powered/resource-contrained firmware, not assembly.
- derefr 7y ago
  In that specific case, I’d probably still not use ASM directly, but rather probably a Lisp DSL for machine-code generation (and a Lisp emulator for the ISA it generates), so that I could in turn write some genetic algorithm or somesuch to explore the space of such ASTs (and thereby the space of max-256-byte machine-code programs) to find the optimal way to pack instructions to solve my problem (where “solve my problem” is specified in terms of what the emulator’s registers and memory should look like on a given cycle.) ASM is for the use-case where you're optimizing code in terms of using specific instructions or intrinsics; but it's not really for the case where you're concerned with specific opcode encodings (as ASM abstracts that away, grouping multiple different opcode encodings—some short, some very long—behind a single friendly instruction name.) In that case, you have to work with the machine-code directly—or, at least, through data structures that contain machine-code at the base level, and so can tell you exactly what machine-code they contain.

pron 7y ago

I think that Rust's approach to safety -- soundly eliminate UB in safe code -- comes at the high cost of complexity. This affects how easy it is to write custom compilers (very important in the embedded space), but it is also not necessarily the best way to reduce bugs. For some, this cost is acceptable, and I'm sure some people may even welcome the high-level-looking code [1] that Rust and C++ support, but I think there are better ways, ones that are more appealing in low-level ("systems") programming in general and the embedded space in particular: https://news.ycombinator.com/item?id=21970987 https://news.ycombinator.com/item?id=21970987, https://news.ycombinator.com/item?id=22021237 https://news.ycombinator.com/item?id=22021237 Rust is without a doubt a (much) "better C++" but I'm not sure a better C++ is necessarily what systems programming needs most. [1]: Not that writing that code is as easy as in a high-level language, nor does it offer the same level of abstraction as high-level languages, where changing the details of the implementation does not affect the API and its clients, but it looks high level, or "expressive", on the page.

alxlaz 7y ago
> Rust is without a doubt a (much) "better C++" but I'm not sure a better C++ is necessarily what systems programming needs most. I agree but if better C++ is what the PL industry can give me, then I'll take it, thank you very much! (Frankly at this point I'll take anything that isn't C++...)
- pron 7y ago
  There are alternatives that more appeal to my taste in the works. Given the cost of changing language, any language, I'll wait and see how they turn out before making decisions.
  - jeltz 7y ago
    Which ones are more to your taste? For me it is mostly Zig which seems closer to what I want to see in a language. Crystal also looks promising but I prefer languages without GC. Rust is a good language but it is a bit too complex and restrictive at times.

ComputerGuru 7y ago

We’re already using it in production for embedded development (on stm32 MCUs). So are a lot of other people. It lets you target a niche between spaghetti code on bare metal and structured and full-blown runtime/framework, making something along the lines of reusable libraries for bare metal without a runtime or OS possible via its zero-cost types.

DCKing 7y ago

As someone who never much got into systems programming, Rust feels like a breath of fresh air. It makes systems programming way more accessible for me personally, coming from non-systems languages. Learning to write C well is just not something that appeals to me at all. From mostly an outsiders' perspective, I just don't think C is a very nice programming language. It looks easy to to pick up and it probably is (for some definitions of "pick up"), but I don't think that's a good thing. The language gives you almost nothing. Pointers, structs, arrays, control flow. Not much else. I'm barely exaggerating when I say that all the C code I see looks like a chaotic pointer juggle fest for precisely that reason. The few features and library that it does have come with non-obvious gotchas that will punish you later. Rust is probably much harder to "pick up", and way more complicated in general, but it's just, uh, more language. I'll take pattern matching, encouraging immutability, functional style programming, trait programming over C's simplicity any day of the week. The safety is extremely nice, but I think Rust's biggest eye-opener for me is that all these "higher level" features are just possible at (close to) the performance of C. That makes it very appealing to me.

pron 7y ago
> As someone who never much got into systems programming, Rust is a breath of fresh air. I think that's part of the problem :) Because Rust looks high level it appeals to people used to high-level programming. But once you get into systems programming, the issues are different from high-level programming, and you're less happy to pay for features that solve other problems. What I'm saying is, obviously, a matter of taste, and some people doing low-level programming do prefer C++'s high-level feel, which is also found in Rust. I hope it goes without saying that just programming in Rust -- or C++ -- doesn't mean you're doing systems programming unless you're, say, writing a device driver, a kernel, a GC, a game framework etc.
- orclev 7y ago
  Part of the problem is that "systems programming" is an overloaded term that means a number of different things. Is writing a web browser "systems programming"? What about a CLI utility like grep? Kernel module? Bare metal on a STM32? Depending on who you ask most of those will get both a yes and a no answer. On a related note, some language are more or less suitable for each of those. Can you write an OS in Java? Yes. Should you? Probably not. I think one of the previous comments, and others on other forums have things right when they say that Rust is a better C++. Anything you would consider using C++ for is a good candidate for using Rust for. Rust is not a better C though, it's just a bit too high level for that. There are languages that are aiming to be a better C (Zig is REALLY interesting, but very very new right now), but Rust isn't really one of them. I could very easily see something like an OS aimed at x86 desktops being written in Rust. Desktop systems are beefy enough and the problem space is complex enough that the extra overhead involved in Rust (similar to C++) makes sense. On the other hand if you're doing some bare metal work on something like an Arduino you just don't have enough there to justify the extra overhead and something very basic like C (or assembly, or Zig once it matures a bit more) is probably a better fit. If you're doing anything higher level than kernel programming, Rust is just as viable as anything else, at that point it's mostly down to personal preference on whether you can deal with not having conveniences like garbage collection or not.

ekidd 7y ago

Yeah, some of the nice things about Rust aren't immediately obvious. Professionally, I use Rust for a few specific things: 1. Rust is surprisingly great for making cross-platform CLI tools and shipping static Linux binaries. Everybody can just install a single executable and they're ready to go. (Go is good at this, too.) 2. Rust is great for anything where I ask, "How big a cluster do we need for this?" I get roughly the same speed as C++, except there are far fewer footguns. And I can add threading support to existing code in an afternoon, and I can expect it to just work. 3. Rust's very new async support is powerful in some very interesting ways, and I have a couple of programs that it has worked beautifully for. (I'm working on an upcoming open source release of one of them.) 4. Rust's algebraic data types (aka "enum" and checked "match") are a joy for any software involving lots of special cases and complex logic. I think every typed, high-level language should steal this feature. However, I have mixed experience using Rust for business logic. Yes, item (4) above does help with business logic. But business logic changes a lot, and it needs to be accessible to many developers within an organization. So on my recent team projects, Rust often winds up doing the heavily lifting. But the rapidly-changing business logic will often get deferred to a GCed language. So far, this is working nicely.

sammorrowdrums 7y ago
From my experience it's quite a good language for fun experiments and coding challenges, at the very least. I grew to love it quickly during advent of code. The iterators, enums and no Null types lend themselves to interesting solutions. The crate ecosystem is also developing fast, and there are decent browsable docs and bootstrapping the env and development environment are all easy. SDL2 support makes it really easy to make rectangle based games like classic pong and experiment with keyboard and controller inputs etc. (never mind further possibilities of 3D etc). TTY apps and games are also easy to make with the termion crate. I think it's just kind of worth learning in a way that (for example) Python, C and Haskell are complementary options for learning different ways of thinking about of coding. Rust feels like a different flavour of programming. It's borrow checker and branch checking etc. they really are likely to lead to better programming in other languages too. Understanding ownership and considering the transfer of ownership are valuable.

Const-me 7y ago

> lots and lots of embedded systems are now bulky Linux boxes These systems have the resources to run managed runtimes. I’ve shipped embedded software running .NET core 2.2 on ARM Linux (RK3288 with custom set of peripherals), only a minor part of the software being unsafe (a shared library written in C++). Over the last 20 years, desktop GUI software, web servers, and mobile software migrated from C++ towards managed languages, and they never looked back. I’m pretty sure the majority of embedded software gonna follow the same path.