11–20 of 20 posts
How does embedded programming square with the "safety shaming" rust culture? Surely you're transmuting all over the place.
The rust language is (IMO) a perfect match for embedded. The culture you're looking at isn't universal, and can be ignored.
How does embedded programming square with the "safety shaming" rust culture? Surely you're transmuting all over the place.
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.
How does embedded programming square with the "safety shaming" rust culture? Surely you're transmuting all over the place.
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 t…
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.
The issue even refers to this Rust project: https://github.com/tinygo-org/tinygo/issues/1427
Edit: added issue link
Earlier quoted context omitted.
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 t…
> 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 fan…
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".
How does embedded programming square with the "safety shaming" rust culture? Surely you're transmuting all over the place.
How does embedded programming square with the "safety shaming" rust culture? Surely you're transmuting all over the place.
What is safety shaming?
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.
How does embedded programming square with the "safety shaming" rust culture? Surely you're transmuting all over the place.
"Safety Shaming" what a weird term... is the government safety shaming by setting speed limits, disallowing kids to drive or mandating seat belts?
Earlier quoted context omitted.
> 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 fan…
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 al…