I'd disagree with calling it that, but regardless: you're not trasmuting all over the place. You are using unsafe more than application-layer Rust, but the whole idea and power of Rust is encapsulating unsafety effectively. Things are a bit more transparent in these sorts of codebases, but the same principles apply: build useful abstractions of the unsafety, and then use them.
This is why I like it. Abstracting the unsafety, yes I might have to write unsafe to directly access raw hardware memory to get sensor data or something, having a good way to encapsulate these sources of failures makes it easier to write better quality code.
Ideology-driven development is bad no matter what environment you’re coding for.
I’d view it as similar to any other work in a hazardous environment: Apply layers of protection to mitigate risks to an acceptable level. There are so many unavoidably tricky things about embedded development that if you can easily rule out the avoidable ones, it’s worth it.
‘Unsafe’ isn’t a synonym for ‘bad practice’, it’s just a hint to ‘look here first’.
> Ideology-driven development is bad no matter what environment you’re coding for.
Isn't that statement kinda cutting both ways? How is a culture of safety checks and risk mitigation not part of an ideology itself? I mean sure it is a good and sane ideology with the goal of saving people's lives and reducing the occurance of unwanted, unplanned freak accidents, but I'd rather have my airplane's code written by an fanatic follower of that ideology than by e.g. a pragmatic corner cutter that values their own time or the resources of their company more than the fulfillment of checks and rituals.
If we are looking at the typical way code is written for safety critical applications I'd argue that 99% of the work stems from a safety and check culture that many of the "move-fast-and-break-things"-crowd would definitly call an ideology.
Of course it can be bad if ideology starts to inform a developer's decisions without any rational connection to the real world, but I wonder: what kind of development process would be completely without ideology? After all if our code is meant to impact the real world it will always be informed by our image of the world, the way we relate to society. Someone who hacks up a companies web framework in a horrible manner that endangers the data of their customers certainly has an ideology. Someone who makes soundness checks and proofs on open source software in their spare time also certainly has an ideology.
Maybe I put too much into the word here, but I have yet to meet and unideological person.
Fair point and a good distinction to make. I should rather have said "software development ideology driven development" since as you say, all decisions ultimately stem from value judgements.
I'm certainly OK with software development decisions being driven by an ideology of "this code shouldn't be able to injure anyone", just not with it being driven by an ideology of "everything must be an object" or "tests must always be developed before code, and any code which passes the tests is OK" or "code which uses the 'unsafe' keyword is bad".
He's referring to the fact that Rust programmers try very hard to avoid using `unsafe` blocks. Which is a good thing, but he's trying to make it sound like it's just people being snooty or something.
A better way to put it would be "how does the frequent need to use unsafe code in embedded square with Rust programmers' general desire to avoid unsafe code?"
But then it's a boring question and the answer is obvious - they still try to avoid it.
Surely you're transmuting all over the place.