4 ms·

It won't. To do anything useful on a microcontroller you would have to drop into 'unsafe' so often that any idea of safety is out of the window.

pcwalton 10y ago
> It won't. To do anything useful on a microcontroller you would have to drop into 'unsafe' so often that any idea of safety is out of the window. I don't think that's true. I'm writing an OpenGL library right now, diving into "unsafe" all the time to issue the FFI calls, and there's a measurable difference in the number of memory safety problems I've seen (zero thus far) compared to what I see in C++. I think the friction of writing "unsafe" encourages small isolated abstractions.
- milesrout 10y ago
  In other words you're just writing Rust the way anyone competent writes C in the first place: being careful. You think that the language forces you to be careful, I think what's more likely is that Rust is so difficult and aggravating to use that it discourages the sorts of morons that introduce those errors from using it in the first place.
  - pcwalton 10y ago
    The idea that people who create security flaws in C are "morons" is contrary to all the evidence. In fact, the biggest security problems are usually caused by the best programmers. That's because they write the code that people actually use a lot. To be concrete: libpng, libjpeg, FreeType, etc. are not written by "morons". Can you write a JPEG decoder faster than libjpeg-turbo?
  - pjmlp 10y ago
    Somewhere out there do exist these ideal C developers that write perfect safe code. Sadly in more than 30 years of career I never met one. Not even the BSD and Linux kernel devs, given the amount of entries on the CVE database. Even Dennis complained about this, regarding the genesis of lint. So I wonder where do they exist.
jononor 10y ago
Unsafe should only be needed at the edges of the program, in dealing with IO. These parts should always (not just with Rust) be put in some platform layer used by the application code. This allows the majority of the application code to be verified easily, with unit-tests, end-to-end tests as well as writing simulations. Done right the verification can be ran both on host and on-device. Another key benefit is that this allows to develop majority of the software before the hardware is ready. When possible, use a platform abstraction which is already tested. As verification of this code is harder, typically requiring hardware and external interactions. I hope that Rust unsafe/safe concept makes the platform/applogic boundary more visible and explicit, so people follow these practices more often.
- ghettoimp 10y ago
  /clap

pcwalton 10y ago

> It won't. To do anything useful on a microcontroller you would have to drop into 'unsafe' so often that any idea of safety is out of the window. I don't think that's true. I'm writing an OpenGL library right now, diving into "unsafe" all the time to issue the FFI calls, and there's a measurable difference in the number of memory safety problems I've seen (zero thus far) compared to what I see in C++. I think the friction of writing "unsafe" encourages small isolated abstractions.

milesrout 10y ago
In other words you're just writing Rust the way anyone competent writes C in the first place: being careful. You think that the language forces you to be careful, I think what's more likely is that Rust is so difficult and aggravating to use that it discourages the sorts of morons that introduce those errors from using it in the first place.
- pcwalton 10y ago
  The idea that people who create security flaws in C are "morons" is contrary to all the evidence. In fact, the biggest security problems are usually caused by the best programmers. That's because they write the code that people actually use a lot. To be concrete: libpng, libjpeg, FreeType, etc. are not written by "morons". Can you write a JPEG decoder faster than libjpeg-turbo?
- pjmlp 10y ago
  Somewhere out there do exist these ideal C developers that write perfect safe code. Sadly in more than 30 years of career I never met one. Not even the BSD and Linux kernel devs, given the amount of entries on the CVE database. Even Dennis complained about this, regarding the genesis of lint. So I wonder where do they exist.

jononor 10y ago

Unsafe should only be needed at the edges of the program, in dealing with IO. These parts should always (not just with Rust) be put in some platform layer used by the application code. This allows the majority of the application code to be verified easily, with unit-tests, end-to-end tests as well as writing simulations. Done right the verification can be ran both on host and on-device. Another key benefit is that this allows to develop majority of the software before the hardware is ready. When possible, use a platform abstraction which is already tested. As verification of this code is harder, typically requiring hardware and external interactions. I hope that Rust unsafe/safe concept makes the platform/applogic boundary more visible and explicit, so people follow these practices more often.

ghettoimp 10y ago
/clap