Hacker News Reader

Comment by atoav | Hacker News Reader

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 supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC?

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 will certainly check back on the state of Rust on embedded every now and then, but as of now C++ is my goto.

View on HN

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.

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.

>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.

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++.

You make it sound worth a try. I will keep the thought in mind, thanks.

> 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.

Why do you think you might have to go back and to C++?

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.

Interfacing C with Rust is actually a well supported use case.

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.

>To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

Yes, including C.

I guess in that case, at least it's done by a C developer...

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-i...

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.

So the author tried very hard to provide a safe interface for things that are inherently unsafe and found it to be too much work. That’s similar but different to just calling C from Rust and living with unsafe code like you normally do in C.

> 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-...

I have not had to use it yet, looking for a reason.

> 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.

Well lucky us, Espressif is officially providing Rust packages for the ESP32 chips :) !

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.

Spot on!

> 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.

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.

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

Reply on news.ycombinator.com