Comment by the__alchemist
5 months ago
It's such a surprising dichotomy! Rust tooling, language and low-level capability makes it my top choice in several domains. It strikes me as the best tool available in high-performance and low-level domains. I contrast this with your observation: most of the open-source software (libraries generally) I see in rust are of poor quality.
I'm building a structural biology ecosystem in rust, split out into several libs, and a GUI program. Molecular dynamics, file format interop, API interaction, 3D viewer/dashboard/manipulation etc. I also do embedded in rust for work and personal projects. In both of these domains (High-performance scientific programming/GUI+3D, and embedded), I have had to write my own tooling. Nascent tools exist, but they are of too poor quality to use; e.g. easier to rewrite than attempt to work around the limitations of.
I'm at a loss. When I talk to people online about embedded rust, I find people discussing design patterns I think are high-friction (Async and typestates), and few people describe projects.
I think part of the problem is that it has acquired a group of people who design APIs and write libs without applying these libs to practical problems, which would expose their shortcomings.
I can agree to an extent that API designers sometimes (often?) over engineer for imagined problems.
At the same time, I've been working on an embedded Rust project and trying Embassy for the first time and it is _amazing_.
First of all I've had good logging and debug support with probe-rs. Secondly, being able to do ergonomic DMA transfers with async/await syntax feels like cheating. The core goes to sleep until your transfer finishes and an interrupt fires which wakes up the core and continues your async state machine, which the compiler built for you from your async code.
Distinct tasks can be split up into separate async functions, the type system models ownership of singleton hardware well (you can't use Pin 8 for your SPI bus there, you already "moved" it to your I2S peripheral over there!), and it all comes together with pretty minimal RAM usage, efficient use of the hardware, and low power consumption if you're mostly waiting on data transfers.
I'd be happy to talk more about practical problems if you want to get specific.
Good observations! I think Embassy worked out because its creator built it with the goal of shipping smart door locks, so the components of it he uses for that workflow work well.
I think ownership sometimes works for the reason bring up: Catching errors. I suspect you will find cases where you are not as pleased you can't use something you moved elsewhere! In some cases the ownership semantics map smoothly to control over hardware; in others, it's not so good of a fit. I also suspect you are overestimating how difficult DMA and power management are without async. (In rust or otherwise) What you described is a ubiquitous embedded workflow, minus the state machine.
Yep, I can definitely imagine cases where ownership can get in the way of doing something esoteric, but at least there are escape hatches for that if needed.
> I also suspect you are overestimating how difficult DMA and power management are without async.
I probably am, but having ergonomic syntax to orchestrate it all feels like something I wouldn't want to give up, after experiencing it.
You're last quote hits the nail on the head. I've found that good libraries are written by people actually solving the problem and then open sourcing it. pytorch, numpy, eigen, ros, openssl, etc. these all came from being trying to actually solve specific problems.
I think rust will get those libraries, but it takes time. Rust is still young compared to languages with a large amount of useful libraries. The boost project in c++ started in the 90s for example. It just takes time.
> openssl
A library famous for collecting cruft that's irrelevant to actual use.
Boost is basically why I hate C++ but yes your point is entirely correct.
I write rust every day for a niche application that SHOULD be on paper completely trivial given advertised crates. But I constantly run into amateur hour math/correctness mistakes because nobody is using this stuff in daily user-serving production except apparently us. Some of this stuff should just be inexcusable.
One time I filed a bug report the maintainers response I got was "well I'm not familiar with X" where X was precisely what the library is advertised to do.
And yet they are fine rewriting the API every couple months.
This is early stage. The next wave of open source from companies giving back their work is going to be excellent.
PDF handling came to mind as absolutely horrible experience. If you want to make a pdf, the choices were either: 1. Very low level, getting into the nitty gritty implementation details of PDF. 2. Very High level, only suitable to make the equivalent of a word document with very little control of layout 3. Typst, which is nice externally but honestly very difficult to use as a library. 4. mupdf over C FFI can get you mid-level pdf generation. Mid level as in you control layout but aren't using an editor to inspect the generated raw instructions in a PDF. Then you have unsafe everywhere or time spent with FFI making basic wrapper/abstraction negates the benefits.
Oh and for the first 3 the relevant docs for using it in this way are out of date and you will need to look at source code.