5 ms·

I was a C++ developer a long time ago (I've actually used CFront as a professional -- that's how long ago ;-) ). C++ is a fine language. You can write good co

I was a C++ developer a long time ago (I've actually used CFront as a professional -- that's how long ago ;-) ). C++ is a fine language. You can write good code in C++. I've worked on large projects that were extremely stable and easy to work with. It can be done. The one thing I will say about C++ from long ago was that you needed to be skilled at C++. You needed to understand it and you needed to know how to write code that wasn't going to cause you problems in the future. You also needed to work on a team that allowed you to use your skill. The language is so different now that it's practically I different language so I don't know how much of that still remains, but I guess quite a lot. I've been doing some Rust recently. I like Rust. There are bits I think still need work, but generally it's a fine language. The biggest difference I see between it and C++ from long ago is that Rust helps you a lot. It's very convenient and friendly. It also scolds me when I do something stupid, which I appreciate. However, I don't really feel like I need to know less than I did as a C++ programmer. With Rust, it helps you, but if you start causing problems for yourself you can be in for a world of hurt trying to understand what the compiler doesn't like. It will catch that thing that slips by you, which is awesome, but you still have to understand what's going on under the hood. So in my book, it feels very much like C++ with a super friendly and super powerful linter. I mean it's really, really nice, but I don't think you could just hire random people off the street and give them a Rust compiler and say "This will protect you". So to answer your question (finally), I think you won't really fare much better or worse, but the journey seems a little bit more relaxed with Rust.

roca 7y ago
The failure modes of "can't get code to compile" and "something weird and possibly exploitable could happen at runtime" may both be frustrating to developers, but they're worlds apart in practice. Looking at it from the point of view of a kernel maintainer evaluating submissions, the former is not your problem --- in fact it keeps the bad code from ever coming to your attention --- but the latter creates ongoing problems for you.
- rcthompson 7y ago
  This is an interesting point I hadn't considered before: converting run-time failures to compile-time failures is already desirable on its own, but in the context of submitting a patch/pull request to an existing piece of software, it also results in shifting more of the maintenance burden from the person evaluating the submission to the person submitting, since presumably they will usually not submit their patch until it compiles cleanly. I wonder if easing the maintenance burden of beleaguered open source maintainers is an even larger benefit in practice than catching errors at compile time.
- CountSessine 7y ago
  This is true, but there's also a lot of trivial busy-work and confusion that the compiler and language foist on you that isn't security related. Like the fact that you always seem to have a &str when you actually need a String or vice-versa and your code is littered with .to_string() everywhere. Or figuring out what type your iteration is at a particular stage and why you can't call map() on it. Or figuring out the vicissitudes of what collect() will accept and convert for you and what it won't. Or clumsily dealing with a Vec of Results when what you really want is a Result with a Vec Having a really sophisticated type system means...dealing with types a lot. I love Rust - especially ADTs and everything being an expression - but I wouldn't call it more productive than C++. And I think that was mikekchar's point?
  - mplanchard 7y ago
    Just wanted to make sure you knew, you can use `.collect()` to convert an iterable of results into a Result with an iterable. See the 6th example here: https://doc.rust-lang.org/std/iter/trait.Iterator.html#examples-24 https://doc.rust-lang.org/std/iter/trait.Iterator.html#examp...
kbenson 7y ago
> So in my book, it feels very much like C++ with a super friendly and super powerful linter. I mean it's really, really nice, but I don't think you could just hire random people off the street and give them a Rust compiler and say "This will protect you". I think that's probably an acceptable trade-off for certain types of development, and kernel engineering is probably exemplary of that type of development. I might be more hesitant to endorse it if it was the only way (or only way without major hurdles) since that would raise the bar of entry for people wanting to figure out how to make a Linux kernel module (the "make your own kernel module" howto's are empowering for Linux), but as an additional supported interface with the constraints mentioned in the article I think it makes sense.
m0zg 7y ago
C++ is a different language than it was even 10 years ago. The standard library is still lacking, but if you haven't worked with it in the past decade, I'd give it another look. C++11 makes it bearable, later revisions make it very nice.

roca 7y ago

The failure modes of "can't get code to compile" and "something weird and possibly exploitable could happen at runtime" may both be frustrating to developers, but they're worlds apart in practice. Looking at it from the point of view of a kernel maintainer evaluating submissions, the former is not your problem --- in fact it keeps the bad code from ever coming to your attention --- but the latter creates ongoing problems for you.

rcthompson 7y ago
This is an interesting point I hadn't considered before: converting run-time failures to compile-time failures is already desirable on its own, but in the context of submitting a patch/pull request to an existing piece of software, it also results in shifting more of the maintenance burden from the person evaluating the submission to the person submitting, since presumably they will usually not submit their patch until it compiles cleanly. I wonder if easing the maintenance burden of beleaguered open source maintainers is an even larger benefit in practice than catching errors at compile time.
CountSessine 7y ago
This is true, but there's also a lot of trivial busy-work and confusion that the compiler and language foist on you that isn't security related. Like the fact that you always seem to have a &str when you actually need a String or vice-versa and your code is littered with .to_string() everywhere. Or figuring out what type your iteration is at a particular stage and why you can't call map() on it. Or figuring out the vicissitudes of what collect() will accept and convert for you and what it won't. Or clumsily dealing with a Vec of Results when what you really want is a Result with a Vec Having a really sophisticated type system means...dealing with types a lot. I love Rust - especially ADTs and everything being an expression - but I wouldn't call it more productive than C++. And I think that was mikekchar's point?
- mplanchard 7y ago
  Just wanted to make sure you knew, you can use `.collect()` to convert an iterable of results into a Result with an iterable. See the 6th example here: https://doc.rust-lang.org/std/iter/trait.Iterator.html#examples-24 https://doc.rust-lang.org/std/iter/trait.Iterator.html#examp...

kbenson 7y ago

> So in my book, it feels very much like C++ with a super friendly and super powerful linter. I mean it's really, really nice, but I don't think you could just hire random people off the street and give them a Rust compiler and say "This will protect you". I think that's probably an acceptable trade-off for certain types of development, and kernel engineering is probably exemplary of that type of development. I might be more hesitant to endorse it if it was the only way (or only way without major hurdles) since that would raise the bar of entry for people wanting to figure out how to make a Linux kernel module (the "make your own kernel module" howto's are empowering for Linux), but as an additional supported interface with the constraints mentioned in the article I think it makes sense.

m0zg 7y ago

C++ is a different language than it was even 10 years ago. The standard library is still lacking, but if you haven't worked with it in the past decade, I'd give it another look. C++11 makes it bearable, later revisions make it very nice.