jamesmunns

Shipped to the customer, we don't offer leased/managed hardware or VM instances.

My materials probably took 4-6 hours to write the first draft (I did most of it over two evenings, maybe one more just skimming the questions to figure out what things to talk about for each question), probably 2-3 hours or so to edit, then probably another hours over an evening just skimming it too many times before I hit submit. My materials were 16 pages or so, some of that was the original document (which has been linked in this comment section).

It's a fair bit of writing to ask for, but for a mostly remote and prose-driven company, you do a lot of long-form writing in the day to day work. The public RFDs and github issues/comments/commits give a good flavor for this.

As others have said, lots of my work is open source, and I have public writings and talks, so finding those were much easier for me than it might be for someone with only closed source works.

There's no single "embassy" crate, but all the components (HALs, executor, usb, net, etc.) are all on crates io and have been for a long time.

Speaking as someone familiar with C and Rust (not so much Go!), although there's a parallel here to Rust's Traits, this actually is much closer to dyn Trait in Rust, which uses vtables and runtime polymorphism, rather than "regular" Traits in Rust, which are monomorphized versions of similar interface constraints, much closer to C++'s templates (or concepts, I'm hand waving here).

This isn't necessarily a negative, sometimes you actually prefer vtables and runtime polymorphism for various reasons like flexibility, or code size reasons. Just wanted to add some flavor for folks that aren't as familiar with Rust, that this isn't exactly how things usually work, as "regular" Trait usage is much more common than dyn Trait usage, which you have to explicitly opt-in to.

As others have mentioned, ~all of the embassy HALs support nearly 1:1 parity of blocking interfaces for drivers next to the async ones. You really can avoid async entirely while still using embassy hals. The ecosystem is not tightly integrated/locked in.

Even data structure libraries, like embassy-sync, all have `try_` methods, which would allow for polling usage outside of async.

There's no mandate to use async - and helping folks that DO see value in it (which is a LOT of folks), isn't "splitting the ecosystem" - it's people doing things the way they like to do it. Embassy still works very hard to support folks who DON'T want to use async, to avoid duplicated work. There's nothing stopping you from preferring to write and maintain your own HALs, I know you have been for a while! But it's not something that people necessarily have to do, even if they aren't interested or don't prefer async!

In safety industries, particularly aviation, "alarm fatigue" is a really big deal. You recognize that pilots have limited situational bandwidth, and you REALLY don't want to be bugging them about things you can avoid. I worked in collision avoidance systems (TAS/TCASI/TCASII), and spent nearly a whole year just working on figuring out when and how we could avoid warning pilots in cases where "we're not sure exactly what is going on, so tell the pilot just in case" could potentially annoy pilots in cases like take off and landing (where they have important OTHER things to be doing!)

It's a fun balance between "possibly don't warn the pilot about something they should know about", and "don't warn them if they are busy doing something important".

More devices should have a "squelch" switch!

Nordic's nRF family is the major other vendor I've seen doing this, almost all peripheral can be on any pin. It's definitely a big help for designing boards.

Kobzol is an absolutely wonderful person to work with. I also work in the Rust project, and any time I've interacted with him, he's been great.

Thank you for sharing, I'd never seen this before. It's an incredibly good read (and relevant for me) so far.