News for hackers. Stuff that matters.

A comment on Deploying Rust in Existing Firmware Codebases. Parent comment

Re:Deploying Rust in Existing Firmware Codebases by nicce on Friday September 06, 2024 @02:32AM (#41463438)
> If interactions through safe abstractions leak unsafety into your code, that's a bug in the abstractions.

This isn't much different than saying that C safe language if you write it perfectly.

> definition of writing a safe abstraction

That definition is not guaranteeing safety, because that is usually not possible. It just about limiting risky areas.

[ Parent | on HN ]
Re:Deploying Rust in Existing Firmware Codebases by saagarjha on Friday September 06, 2024 @03:15AM (#41463713)
No, not quite. If the abstractions leak then it's Rust's fault. If you write buggy C then it's your fault.
[ Parent | on HN ]
Re:Deploying Rust in Existing Firmware Codebases by nicce on Friday September 06, 2024 @12:54PM (#41467772)
> If the abstractions leak then it's Rust's fault

It is the fault of the one who wrote the abstraction.

[ Parent | on HN ]
Re:Deploying Rust in Existing Firmware Codebases by saagarjha on Friday September 06, 2024 @03:32PM (#41469030)
Which is one of the Rust people yes
[ Parent | on HN ]
Re:Deploying Rust in Existing Firmware Codebases by lilyball on Friday September 06, 2024 @04:16PM (#41469393)
> This isn't much different than saying that C safe language if you write it perfectly.

The difference is in C, the entire language is unsafe, whereas in Rust only the bits marked `unsafe` are unsafe. Most Rust code does not need to use `unsafe` at all, and by extension most Rust developers don't need to touch `unsafe`. And for those developers who do use `unsafe`, instead of having to prove every single line of the program is safe like you do in C, you only have to prove that the tiny subset of the program contained within `unsafe` is safe.

[ Parent | on HN ]