Comment by tialaramex
4 years ago
Not just memory safety. Rust also prevents data races in concurrent programs. And there are a few more things too.
But these tricks have the same root: What if we used all this research academics have been writing about for decades, improvements to the State of the Art, ideas which exist in toy languages nobody uses -- but we actually industrialise them so we can use the resulting language for Firefox and Linux not just get a paper into a prestigious journal or conference?
If ten years from now everybody is writing their low-level code in a memory safe new C++ epoch, or in Zig, that wouldn't astonish me at all. Rust is nice, I like Rust, lots of people like Rust, but there are other people who noticed this was a good idea and are doing it. The idea is much better than Rust is. If you can't do Rust but you can do this idea, you should.
If ten years from now people are writing unsafe C and C++ like it's still somehow OK, that would be crazy.
Imagine it's 1995, you have just seen an Internet streaming radio station demonstrated, using RealAudio.
Is RealAudio the future? In 25 years will everybody be using RealAudio? No, it turns out they will not. But, is this all just stupid hype for nothing? Er no. In 25 years everybody will understand what an "Internet streaming radio station" would be, they just aren't using RealAudio, the actual technology they use might be MPEG audio layer III aka MP3 (which exists in 1995 but is little known) or it might be something else, they do not care.
> If ten years from now people are writing unsafe C and C++ like it's still somehow OK, that would be crazy.
It's 26 years after Java was released. Java has largely been the main competitor to C++. I don't see C++ going away nor do I see C going away. And it's almost always a mistake to lump C and C++ developers together. There is rarely an intersection between the two.
I think you do not understand how short 10 years is. There are tons of people still running computers on Sandy Bridge.
> I think you do not understand how short 10 years is. There are tons of people still running computers on Sandy Bridge.
Ten years is about the time since C++ 11. I may be wrong, but I do not regret my estimate.
Well, Zig isn't memory safe (as implemented today; they could add a GC), so it's not a good example of a Rust alternative in this domain. But I agree with your overall point, and would add that you could replace Zig with any one of the dozens of popular memory safe language, even old standbys like Java. The point is not to migrate to one language in particular, but rather to migrate to languages in which memory errors are compiler bugs instead of application bugs.
Zig isn't memory safe but it's still leaps and bounds above C.
I have to admire the practicality of the approach they've been taking.
I could have sworn I'd read that Zig's ambition was to be memory safe. Given ten years I don't find that impossible. Indeed I gave C++ the same benefit of the doubt on that timeline. But, when I just searched I couldn't find whatever I'd seen before on that topic.
The Zig approach is "memory safe in practice" vs "memory safe in theory". They don't have any aspirations to total memory safety like Rust, but they want to get most of the way there with a lot less overhead.
Basically they have a lot of runtime checks enabled in debug mode, where you do the majority of your testing, that are then disabled in the release binary.
Additionally the approach they've taken to allocators means that you can use special allocators for testing that can perform even more checks, including leak detection.
I think it's a great idea and a really interesting approach but it's definitely not as rigorous as what Rust provides.
5 replies →
> Well, Zig isn't memory safe (as implemented today; they could add a GC), so it's not a good example of a Rust alternative in this domain.
While the first part of the sentence is mostly true (although the intention is to make safe Zig memory safe, and unsafe Rust isn't safe either), the second isn't. The goal isn't to use a safe language, but to use a language that best reduces certain problems. The claim that the best way to reduce memory safety problems is by completely eliminating all of them regardless of type and regardless of cost is neither established nor sensical;. Zig completely eliminates overflows, and, in exchange for the cost of eliminating use-after-free, makes detecting and correcting it, and other problems, easier.
I remain unconvinced that race proof programs are nearly as big a deal as memory safety. Many classes of applications can tolerate panics and its not a safety or security issue. I don't worry about a parser or server in go like I would in C.
(I realize that racing threads can cause logic based security issues. I've never seen a traditional memory exploit from on racing goroutines though.)
A Race in Go is Undefined Behaviour. All bets are off, whatever happens, no matter how strange, is OK.
If you have a race which definitely only touches some simple value like an int and nothing more complicated then Go may be able to promise your problem isn't more widespread - that value is ruined, you can't trust that it makes any sense (now, in the future, or previously), but everything else remains on the up-and-up. However, the moment something complicated is touched by a race, you lose, your program has no defined meaning whatsoever.
Of course, but when talking about security, a race in Go would be very hard to exploit.
It is a different story in languages meant to run untrusted code of course.
I've seen Qt Creator segfault due to the CMake plugin doing some strange QStringList operations on an inconsistent "implicitly shared" collection, that I guess broke due to multithreading (though I'm not sure exactly what happened). In RSS Guard, performing two different "background sync" operations causes two different threads to touch the same list collections, producing a segfault. (These are due to multiple threads touching the same collection/pointers; racing on primitive values is probably less directly going to lead to memory unsafety.)
Apparently in Golang, you can achieve memory unsafety through data races: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... (though I'm not sure if a workaround has been added to prevent memory unsafety).
I take that bet about C being pretty prominent in 10 years from now.
A language and a memory access model are no panacea. 10 years is like the day after tomorrow in many industries.
> also prevents data races in concurrent programs.
I have another neat trick to avoid races. Just write single threaded programs. Whenever you think you need another thread, you either don't need it, or you need another program.
You do realize that data races can happen between multiple programs as well, when shared resources are used? Which is pretty much a requirement for many things.
Yes, and rust can't prevent those.
3 replies →
> If ten years from now people are writing unsafe C and C++ like it's still somehow OK, that would be crazy.
I mean to be clear, modern C++ can be effectively as safe as rust is. It requires some discipline and code review, but I can construct a tool-chain and libraries that will tell me about memory violations just as well as rust will. Better even in some ways.
I think people don't realize just how much modern C++ has changed.
It must have changed a shitload in the last 2-3 years if that's the case. What tools are you referring to? I'm pretty familiar with C++ tooling but I haven't paid attention for a little while.
The modern standard library, plus some helpers is the big part of it. Compiler warnings as errors are very good at capturing bad situations if you follow the rules (e.g. don't allow people to just make raw pointers, follow a rule of 5). I never said it was as easy to do as in rust.
As for tooling, things like valgrind provide an excellent mechanism for ensuring that the program was memory safe, even in it's "unsafe" areas or when calling into external libraries (something that rust can't provide without similar tools anyway).
My broader point is that safety is more than just a compiler saying "ok you did it", though that certainly helps. I would trust well written safety focused C++ over Rust. On the other hand, I would trust randomly written Rust over C++. Rust is good for raising the lower end of the bar, but not really the top of it unless paired with a culture and ecosystem of safety focus around the language.
2 replies →