Rust on Espressif chips – 17-10-2022
mabez.devThe conference mentioned in the article:
Espressif DevCon22 - Oct 19, 2022 - Day 1 - https://www.youtube.com/watch?v=8l29cTFS27w
Espressif DevCon22 - Oct 20, 2022 - Day 2 - https://www.youtube.com/watch?v=BgRzpbZM5QY
With support for wifi. Very cool. I was looking at tinygo, but unfortunately it does not support wifi.
The issue even refers to this Rust project: https://github.com/tinygo-org/tinygo/issues/1427
Edit: added issue link
These guys are talking business. Some weeks ago I vented in Twitter about problems building an example project for ESP32 (in Portuguese), someone from Espressif side was diligent enough to translate it and answer with hints (in the end, I had messed up during toolchain installation, thanks there is espup now).
Really excited to see the progress. Love writing rust rather than I think c++ I was using?
I'm curious if anyone here has projects that already use Rust on the Espressif platform.
Not sure if you are aware of the projects mentioned here: https://github.com/esp-rs/awesome-esp-rust#projects
How does embedded programming square with the "safety shaming" rust culture?
Surely you're transmuting all over the place.
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".
Okay gotcha, I read it in a more general way than you meant it. I agree that being dogmatic with structural ideas can lead to bad code for sure.
It depends. This culture has resulted in some unergonomic and impractical APIs that fall apart when applied to firmware or non-trivial examples.
The rust language is (IMO) a perfect match for embedded. The culture you're looking at isn't universal, and can be ignored.
You hide the unsafe code in functions and the rest of the code is safe
"Safety Shaming" what a weird term... is the government safety shaming by setting speed limits, disallowing kids to drive or mandating seat belts?
What is safety shaming?
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.