I'm an embedded engineer, who's been tinkering a bit with learning Rust; so far only for an application-level project, but am keen to try it out in embedded. So far, it's been fun and exciting, along similar lines as Bryan wrote about in the OP. In fact, a video of a talk he did (https://www.youtube.com/watch?v=LjFM8vw3pbU) is what pushed me to getting started.
I think you're spot on with regards to tooling being a major concern, and to me, this is one of the promising aspects of Rust, with cargo at the high level and the LLVM tools lower down. It seems like a system that's primed for open source libraries targeting specific families of chips, cleaning up the mess we've got now with each vendor having their own framework, IDE, configuration tool, etc.
Speed and size concerns though, seem to depend a lot on the specific project. In the last couple years, I've worked on systems that had neither/either/both of those as the primary challenge. Of course in embedded, where you try to save money on parts early in a project can determine the technical (and so, schedule) challenges later on.
And, I'd add safety to the list, having spent loads of time finding bugs in legacy C caused by stuff like walking off the ends of arrays, jumping to uninitialised function pointers, fun with enums and unions, etc.
James Munn gave a super interesting talk at this year's RustConf about some of the abstractions they're building for embedded systems: https://www.youtube.com/watch?v=t99L3JHhLc0
I think Rust is in a great position to become incredibly useful in the embedded space.
The promise of cargo libraries supporting various chips and hardware would be a fantastic boon. Likely it’d significantly reduce security bugs and speed up dev time. Currently I’ve started using forth as a wrapper over embedded C libs so, well, I don’t have to write C daily.
Exactly. In most embedded contexts you have CPUs which are overpowered for what you need. What matters is code size, because flash memory is really expensive and the quality of your tools.
Also, once you go beyond blinking a couple of LEDs and especially if you care about energy consumption, you quickly get mired in complexity, dealing with interrupts and resulting concurrency. If you're a seasoned embedded developer, you will have an explicit, mostly declarative state machine at this point, possibly nested, and if you have more than 15 years of experience, you will be seriously thinking about better representations and generating all that C code from a Lisp.
I'm have a lot of hope for Rust in the embedded world. I especially hope that it will get embraced by vendors. To take a practical example again, I'm thinking about Nordic Semiconductor, which has really good SDKs and is innovative.
You just have to trust that we've been doing it for thousands of years without killing ourselves. As long as you've got plenty of salt and a low pH, you'll be fine.
I've made all sorts of fermented foods over the years, pickles, beer, spirits, bread, etc. Haven't gotten sick yet.
It's really hard to get wrong. The salt kills most of the bad things and the capsaicin and garlic have potent anti-fungal properties which make it especially difficult to mess up. If you remember to turn your ferment once a day or so it'll go very well. (By turn I mean physically mixing the material at the top of the jar down into the depths of the jar and dredging up the stuff at the bottom for a while to sit at the top. This keeps "scum" from forming, but the scum won't kill you and can be safely scraped away without spoiling the batch if it does form.)
It does not. I the camera distorts the colors a bit, but when I made the reading, I had it at somewhere between 3-4. This was also confirmed by simply tasting the brine. It is very acidic.
The experience seems to be that organisms which tolerate high salt won't kill you.[0] Ditto for low pH.[1] And the bacteria in high-salt fermenting produce lactic acid.
In general if it tastes OK and doesn't have visible growths (e.g. fuzz, green or white patches) then it's fine. A lactic acid fermentation will actually kill most pathogens, so it's surprisingly safe.
The yeast and other lactic acid bacteria are coating (and usually inside) the produce, so you don't need to worry a lot about "the right culture". (If you want to be sure, you can collect a starter culture, but that's quite advanced.)
I would still call it tricky. I consider myself pretty capable but after a month of unsuccessfully tracking down DKIM/SPF/DMARC failures for some recipients I just gave up and switched to Fastmail.
I lasted just over a year of working at FastMail before I moved my personal stuff for my family over. I resisted for a bit - but I figured if I was getting in woken in the night to fix the FastMail system anyway, I might as well not be woken a second time if my family system went down!
As a parent I should make whatever arbitrary rules I consider appropriate. Be that "no screens at the table" or "Don't eat with your mouth open" or "How can you have any pudd'n if you don't eat your meat?".
Whether they'll make your family happier or "more perfect " according to someone elses yardstick is irrelevant. You set the boundaries, and live with the environment that they create. So set the ones that make you happier and stick with them. They may be just what your parents did, or they may be the opposite.
The nRF24L01 is not really a BLE radio, though the modulation is effectively the same. It supports only a very simple protocol that is proprietary to Nordic Semi. In this case it looks like they're abusing it to sniff BLE advertising packets, but it wouldn't be able to do much else.
I still agree that we shouldn't call it air-gapped, though.
