3 ms·

> I'm genuinely curious [how] you say this with any sort of surety. Of all the things I said, is that really the only one you want to address? In the future,

> I'm genuinely curious [how] you say this with any sort of surety. Of all the things I said, is that really the only one you want to address? In the future, I'll try harder to qualify my statements with a "to the best of my knowledge" clause when replying to Rust core developers, but constantly adding caveats to every word I say is tedious. No, I'm not omniscient - I can't prove my software has never been exploited. I have some doubts whether your question is really all that sincere, but giving you the benefit of the doubt: For the last 15-20 years, my job-related software runs on networks which are effectively air-gapped. My users aren't shy about submitting bug reports, and they generally have my phone number. For what it's worth, truly "malicious users" run the risk of getting fired or facing a court-marshall. Anyone who runs my code already has a shell and a compiler on the machine. We give them the source. They frequently have sudo. It would be much simpler for them to just write a program and run it than inject it into my (hypothetical) buffer overflows. If they want to crash my software, they can simply kill -9 it (or not start it in the first place). Before that I worked for a few unsuccessful startups, and I wish my software had seen enough exposure to run the risk of being exploited. I've written Netscape plugins which I know were exploitable, but that code vanished along with the stock options before most people had gotten past dial-up connections. Maybe someone somewhere curses the day I was born, but they didn't send a bug report. Having said all of that, you probably think I'm in some rare position. However, it's a really big world, and you might be surprised how much sloppy C, C++, Fortran, and COBOL software is out there quietly getting the job done without the constant onslaught of black hats attacking it. We don't all write web browsers and servers. There are a lot of potentially profitable C++ targets in the finance industry, but somehow they survive. I'm not one of the people saying modern C++ solves all the problems. I'm keenly aware of many short comings in C++. The language sucks in a lot of ways, and I dread trying to explain the complexities to non computer science developers. Given all of that, I have been interested in Rust for reasons having nothing to do with safety. You have some great features, and I think you should advertise those. If you fixed the pain points in Rust instead of emphasizing the shortcomings in C++, I think you could win a lot more converts (and a lot of new developers who could grow your ecosystem outside of web clients and services).

dbaupp 10y ago
> Of all the things I said, is that really the only one you want to address? Yes, I guessed (correctly!) that others would inquire about the rest of the comment, I wanted the context. Thank you for taking the time to explain. > Having said all of that, you probably think I'm in some rare position. However, it's a really big world, and you might be surprised how much sloppy C, C++, Fortran, and COBOL software is out there quietly getting the job done without the constant onslaught of black hats attacking it. We don't all write web browsers and servers. There are a lot of potentially profitable C++ targets in the finance industry, but somehow they survive. I'm not surprised. Your argument is something along the lines "a lot of code doesn't have particularly high security requirements" and "sandboxing/airgapping mitigates problems", which are both totally reasonable and indeed are things that Rust core team acknowledge (although the first is becoming less and less true, in "surprising" places, as more things are internet connected). Additionally, the latter is a "defense in depth" strategy that the Rust community is keen on (e.g. https://github.com/servo/gaol https://github.com/servo/gaol): it is understood that code can have bugs, inside unsafe code or not, and so limiting the interaction with things outside the program is always good. However, neither of these facts support, for instance, an expert being able write a memory-safe regex library in C++ in a reasonable time (e.g. how long it took for Rust's regex library to be written by a single Rust expert), nor do they say anything about code that does have strict requirements about security or correctness (latent memory safety bug might not be exploited, but it can still lead to weird crashes and data corruption). > Given all of that, I have been interested in Rust for reasons having nothing to do with safety. You have some great features, and I think you should advertise those. If you fixed the pain points in Rust instead of emphasizing the shortcomings in C++, I think you could win a lot more converts (and a lot of new developers who could grow your ecosystem outside of web clients and services). This was extensively discussed a few weeks ago, e.g. http://words.steveklabnik.com/rust-is-more-than-safety http://words.steveklabnik.com/rust-is-more-than-safety https://thefeedbackloop.xyz/safety-is-rusts-fireflower/ https://thefeedbackloop.xyz/safety-is-rusts-fireflower/ http://graydon2.dreamwidth.org/247406.html http://graydon2.dreamwidth.org/247406.html http://words.steveklabnik.com/fire-mario-not-fire-flowers http://words.steveklabnik.com/fire-mario-not-fire-flowers . And, you might be interested to know that the 2017 roadmap https://blog.rust-lang.org/2017/02/06/roadmap.html https://blog.rust-lang.org/2017/02/06/roadmap.html includes many things like fixing pain points, and features for both web and non-web developers.

dbaupp 10y ago

> Of all the things I said, is that really the only one you want to address? Yes, I guessed (correctly!) that others would inquire about the rest of the comment, I wanted the context. Thank you for taking the time to explain. > Having said all of that, you probably think I'm in some rare position. However, it's a really big world, and you might be surprised how much sloppy C, C++, Fortran, and COBOL software is out there quietly getting the job done without the constant onslaught of black hats attacking it. We don't all write web browsers and servers. There are a lot of potentially profitable C++ targets in the finance industry, but somehow they survive. I'm not surprised. Your argument is something along the lines "a lot of code doesn't have particularly high security requirements" and "sandboxing/airgapping mitigates problems", which are both totally reasonable and indeed are things that Rust core team acknowledge (although the first is becoming less and less true, in "surprising" places, as more things are internet connected). Additionally, the latter is a "defense in depth" strategy that the Rust community is keen on (e.g. https://github.com/servo/gaol https://github.com/servo/gaol): it is understood that code can have bugs, inside unsafe code or not, and so limiting the interaction with things outside the program is always good. However, neither of these facts support, for instance, an expert being able write a memory-safe regex library in C++ in a reasonable time (e.g. how long it took for Rust's regex library to be written by a single Rust expert), nor do they say anything about code that does have strict requirements about security or correctness (latent memory safety bug might not be exploited, but it can still lead to weird crashes and data corruption). > Given all of that, I have been interested in Rust for reasons having nothing to do with safety. You have some great features, and I think you should advertise those. If you fixed the pain points in Rust instead of emphasizing the shortcomings in C++, I think you could win a lot more converts (and a lot of new developers who could grow your ecosystem outside of web clients and services). This was extensively discussed a few weeks ago, e.g. http://words.steveklabnik.com/rust-is-more-than-safety http://words.steveklabnik.com/rust-is-more-than-safety https://thefeedbackloop.xyz/safety-is-rusts-fireflower/ https://thefeedbackloop.xyz/safety-is-rusts-fireflower/ http://graydon2.dreamwidth.org/247406.html http://graydon2.dreamwidth.org/247406.html http://words.steveklabnik.com/fire-mario-not-fire-flowers http://words.steveklabnik.com/fire-mario-not-fire-flowers . And, you might be interested to know that the 2017 roadmap https://blog.rust-lang.org/2017/02/06/roadmap.html https://blog.rust-lang.org/2017/02/06/roadmap.html includes many things like fixing pain points, and features for both web and non-web developers.