I arrived to the comments section before the C vs Rust flame war
Obviously not. We've been doing this for decades and are still making the same mistakes with costly effects. Humans are as much a part of technological systems as the language or platform; continuing to ignore that even educated, disciplined, skilled developers are prone to certain classes of errors -- errors that could be obviated by other components of the system -- is hubris. It is much more feasible to create tools that exclude certain classes of error than to create less fallible developers.
> (code size; execution speed; random latencies)
Rust is not GC'ed, has no inherent reason to be slower than C (as the toolchain matures), and I doubt is more verbose than C code that provides the same safety.
And nothing to say about the performance cost of these infallible tools? They are not free.
And now we have power saws that immediately stop when they encounter flesh. Obviously, disciplined users never had to worry about that system, otherwise we would have had a bunch of people missing fingers... like my wood shop teacher in high school. :/
> And nothing to say about the performance cost of these infallible tools? They are not free.
People have brought this up a few times, but I've never gotten an explanation that makes sense. My understanding is that Rust does most of its protections in the compile stage, so while not free, they are a small up-front cost at the compile stage, plus an indeterminate cost at the development stage in possible more complex reasoning about the code, which then pays off over the lifetime of the application. While not free, that's definitely a trade-off that seems to make sense to me.
Or are you talking about some other cost? Can you explain where I'm not understanding your point?
I agree we could do better than C. Everyone here talks about it every time this happens, but does nothing. I'll take battle-hardened C over written-last-week Rust, too. Especially crypto code.
Apparently 40 years are not enough to acquire that level of discipline.
We've enjoyed orders of magnitude performance and latency improvement over scripted or GC'd languages.
Its certainly possible to write competent C++ with a professional team, and clear reasons for doing so.
C++ does provide the necessary features to write safe code, as long as one stays away from "C with C++ compiler" mentality and adopts those language and library features.
As for the tools, they are largely ignored by the majority of enterprise developers, assuming Herb Sutter's presentation at CppCon 2015 is in any way representative (1% of the audience said they were using them).
Which goes in line with my (now) outdated C++ professional experience up to 2006.
Only one company cared to pay for Insure++ (in 2000) and I was probably the only one that cared to have it installed.
Also except for my time at CERN, I never met many top elite C++ developers.
Most were using it as "C with C++ compiler" and in teams with high attrition, leading to situations where no one was 100% sure what the entire codebase was doing.
I do wish them the best luck, though.
Also, I'm pretty sure that Oberon was quite a bit earlier than that.
- implicit type conversions errors
- memory allocations with incorrect size
- implicit decay of arrays into pointers
- lack of bounds checking for arrays
- null terminated strings with missing null character
- invalid pointers passed as argument for out parameters
- implicit conversion of integers into invalid enumeration values
I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
Rust's standard library aborts on OOM.