4 ms·

As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well

• tamimio 3y ago
  Spot on!
• worik 3y ago
  > Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research? I had a sense this a priority for the Rust Central Committee, so I had a quick look https://docs.rust-embedded.org/book/interoperability/c-with-rust.html https://docs.rust-embedded.org/book/interoperability/c-with-... I have not had to use it yet, looking for a reason.
• znpy 3y ago
  > As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. Maybe the mindset of the industry as well? Not sure if things have changed (and if so, how) but 9-10 years ago when i was in university I had an interview with a company that did embedded systems stuff. While talking about my competencies I mentioned I was able to create cross-toolchain if they were interested and the guy (he was kinda like the CTO iirc) abruptly interrupted me and just said: "no. just no. we always and only use the vendor's BSP (board support package). we don't care about anything else. should there be any kind of issue we want to be able to ring them and get them to fix the issue.". How do you get people (or an industry?) with such a mindset to just use something because it's trendy? My guess is that industry will wait another 10-15 years until some vendor big enough ships a rust toolchain as a BSP. Other vendors will follow. Then Rust on embedded systems will flourish.
  • navaati 3y ago
    Well lucky us, Espressif is officially providing Rust packages for the ESP32 chips :) !
  • rockdoe 3y ago
    Ah yes, then the vendor goes out of business and they have to bring in highly paid consultants to fix bugs in the vendors' gcc 2.95/Linux 2.6.x port to their SoC. You need to be in the right kind of company - the one where waiting for the external vendor to fix their shit is too slow.
• the__alchemist 3y ago
  You will probably be on your own unfortunately regarding hardware support. Even when libraries exist, they are often not worth the fork/PR/modification process to accommodate your use case. I hope you like datasheets... This sounds rough, but I will highlight two upsides: #1: You benefit from the nice tooling and language of rust #2: You are forced to learn how to use peripherals at a lower level than would otherwise be required. You will become adept at reading datasheets, and interacting with hardware, because you will write to registers directly while building your own abstractions. The easy choice is to use C or C++.
  • atoav 3y ago
    You make it sound worth a try. I will keep the thought in mind, thanks.
• adrianN 3y ago
  Interfacing C with Rust is actually a well supported use case.
  • bsder 3y ago
    Not really. The semantics as you cross the boundary are ill-defined. And you will pay dearly if the C library wants to own any of the resources (like an event loop). And "unsafe" programming in Rust is really difficult to get right--possibly harder than C. To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.
    • adrianN 3y ago
      >To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them. Yes, including C.
      • palata 3y ago
        I guess in that case, at least it's done by a C developer...
      • bsder 3y ago
        Incorrect. Two C libraries interface just fine if library 1 handles ownership and library 2 (or your program) simply operates on the resulting things being passed around. Rust, on the other hand, will go bananas and your life will be miserable. See: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
        • tialaramex 3y ago
          That 2019 blog post explains how, having made a whole series of mistakes, they're now going to rewrite everything in C and it'll go much better. The next blog post says they've abandoned the project instead. To me, it seems like they'd lost motivation years previously and were increasingly flailing around for something that would spark the same joy as initial work on an exciting new project, and Rust has little to do with that. Lots of crates exist which wrap popular C libraries, and they don't seem to run into the sort of misery you describe.
• jdiez17 3y ago
  From my experience in the embedded world, the ecosystem doesn't seem super relevant. You may depend on certain libraries for encryption, compression, etc. but you're more likely than not to be writing drivers for all of your devices more or less from scratch. Other than Arduino, which of course has pretty good support for many devices and is likely to work out of the box.
  • atoav 3y ago
    It probably depends on what you do with embedded, I can certainly imagine situations/jobs where you are correct, but I am not in that situation, unfortunately. I can't afford the time to write my own drivers unless I really need/want to. I run an electronics workshop at an artschool, so the end result counts and how we get there is more or less arbitrary unless it happens in a finite timeframe. For my own private projects I tried Rust, but also there my goal is to get things done, not to fool around forever. I like fooling around with the interesting bits, not with rewriting a thing others have written before.
    • llm_trw 3y ago
      >I like fooling around with the interesting bits, not with rewriting a thing others have written before. For some reason the rust community seems to love rewriting things others have done before and not do much new work. At this point the biggest thing holding the language back are its users.
• MSFT_Edging 3y ago
  > connect it to a popular OLED display? At least for the ssd1306 and the sh1106 there is in fact a library for it that works well. I recently started working on a rust-esp32 project because I'm far too lazy to properly deal with json in C. It was basic, some buttons, a display, an encoder, and a web api but it was a breeze. I'd really like to continue on more complex projects in the future. I've somehow avoided writing C++ in an embedded setting and now I'm afraid I might have to go back and learn that rather than continue with Rust.
  • yeeeloit 3y ago
    Why do you think you might have to go back and to C++?
    • MSFT_Edging 3y ago
      Industry is firmly in C/C++ land and I'm trying to pivot towards a more embedded career, which would put me in more junior jobs without the political sway to say "lets try embedded rust and contribute back". There's a couple forward thinking companies like memfault, but it seems to be the minority. My degree was in CE so I've always played around with embedded projects, but actual design skills have stagnated from being in my field, which trends towards only developing smaller purpose built tools for internal use over products.
• xormapmap 3y ago
  > Is there a library for that? What? Are there really people out there relying on libraries for every peripheral? I've never seen anyone use a third party library for peripherals like that, short of some prototyping on an Arduino or the like. It's always just drivers implemented from scratch.
  • atoav 3y ago
    Jup. This is my field of work. I am ot a full time embedded developer, I run an electronics workshop at an artschool. So a lot of arduino-ish things, and aometimes more sophisticated stuff. But I ain't got no time to write drivers.
• kkert 3y ago
  Honestly i have a far easier time finding working no-std libraries for anything i need on embedded Rust compared to embedded C++. Arduino ecosystem is an exception, but that's not necessarily something i'd put in production