3 ms·

I do wish that rust had stayed a simpler language, but I do think it started about as simple as you could while having a borrow checker. The fact that c2rust tr

I do wish that rust had stayed a simpler language, but I do think it started about as simple as you could while having a borrow checker. The fact that c2rust transpilers (for unsafe rust) popped up so soon after its release years ago, is good evidence that at least a subset of rust is only slightly syntactically different to c. Even if you only had to add lifetime notations to c, the amount of code that would have to be rewritten is vast. And a lot of the extra stiff in rust is to lower the performance cost of safety. Like avoiding runtime bounds checking or unnecessary copies while keeping the benefits. Tl;dr I don't think c with a borrow checker and bounds checking is what we want performance wise. I think that is pretty much carbon. If you want robust and well known, pick ada/spark. That language and it's culture is all about security and has been for decades. It also doesn't have quite the performance of c and rust. And about the sharp knife... I have worked embedded c++ for decades now, some safety critical where we inspected the assembly generated and verified 100% code and branch coverage, on the assembly. I have made one memory safety error that escaped test in those years. That has been found yet... I'm not in the kernel culture so I don't know. But it doesn't seem like it values things like static analysis, unit test coverage, san builds etc. It seems from the outside they are simply relying on their knife skills instead of measuring the quality of their work. Microsoft and Google both say over 70% of their exploits have come from memory safety errors. So it isnt M-1 + x. It is M0.3 + X. And rust isn't super new, so we have some ideas about X from early production use in firefox and dropbox. And we have an idea about how many knife users never cut themselves given even just the recent history like beacown. It is time to start the incremental change.

optymizer 4y ago
Thank you for a thoughtful response. I do hope I am wrong and we as an industry end up in a better spot overall, though I suspect Rust is not the language that's going to get us there. Most accounts I've read or conversations I've had with people who used Rust in large projects boil down to "it's not worth fighting the language", so my general impression is that Rust is the Perl of this decade, and I'm excited for the next generation of languages after Rust, because they will have to consider the safety aspect.
- galangalalgol 4y ago
  In the three projects I've been on that used rust, there really hasn't been much of that. Mostly I have been surprised at how high level it feels even with all the control. I do think the type of project makes a difference. I have been doing mostly dsp type stuff. And coming at it from the mindset of ocaml or modern c++ (value semantics etc.) Vs the ansi c mindset I used on TI DSPs back in the day makes a big difference. And that is the problem with bolting on the safety. The borrow checker doesn't just find mistakes, it also forces you to code in a different style so it can reliabily do so. Not necessarily a better style, but not slower either, a different and easier style for it to check. The syntax could have been closer to c, but the style would end up being similar. As far as all the complexity getting added, ferrocene or someone like them may end up making a safety critical subset like spark is to ada, that is simpler to do formal verification on. That would be a good subset for drivers and kernels.

optymizer 4y ago

Thank you for a thoughtful response. I do hope I am wrong and we as an industry end up in a better spot overall, though I suspect Rust is not the language that's going to get us there. Most accounts I've read or conversations I've had with people who used Rust in large projects boil down to "it's not worth fighting the language", so my general impression is that Rust is the Perl of this decade, and I'm excited for the next generation of languages after Rust, because they will have to consider the safety aspect.

galangalalgol 4y ago
In the three projects I've been on that used rust, there really hasn't been much of that. Mostly I have been surprised at how high level it feels even with all the control. I do think the type of project makes a difference. I have been doing mostly dsp type stuff. And coming at it from the mindset of ocaml or modern c++ (value semantics etc.) Vs the ansi c mindset I used on TI DSPs back in the day makes a big difference. And that is the problem with bolting on the safety. The borrow checker doesn't just find mistakes, it also forces you to code in a different style so it can reliabily do so. Not necessarily a better style, but not slower either, a different and easier style for it to check. The syntax could have been closer to c, but the style would end up being similar. As far as all the complexity getting added, ferrocene or someone like them may end up making a safety critical subset like spark is to ada, that is simpler to do formal verification on. That would be a good subset for drivers and kernels.