> (Well-designed, first-class) GC is still the only system proven to completely remove memory safety issues.
To be pedantic, you need more than a GC for memory safety. Like a language (type system, bounds checks) that forces you to only look only inside the memory being managed. :-)
Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way.
Beyond that there are safety concerns that where the shared memory model managed by the GC bites you. For example: Rust solves threading issues with move semantics and pinning, guiding programmer away from shared mutable state. Also think of stop-the-world problems inherent with GCs. They can be life threatening in real-time systems.
So: yes it's true that it's difficult to write safe code in C++, and many safety bugs are related to memory. But that doesn't mean that code in a GCed language is inherently safer.
> Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way
Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory?
Regardless, a GC is about trade offs. A GC alleviates the 99% of programming. Thinking about having to close a file resource occasionally, especially since javac will warn you when you don’t, is leagues easier than having to navigate the borrow checker all of the time.
The same goes for concurrent programming. 99.9% of all code written in GC’d languages like Java never go over a thread boundary.
> Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory?
Unfreed memory also doesn't let you ++ your way into remote code execution.
Using a file-handle after it's been closed can cause all sorts of issues; and if the underlying file-descriptor is being reused to e.g. write a shell script you can end up in RCE territory as well.
No, you can get an exception, but that can happen either way (the OS can close the file handler irrespective of what the process does), and is not a safety violation.
The only problem that can happen in managed languages is leaking of file handlers by not manually closing them, leaving it up to the GC, and opening handles faster than they are being closed — this can cause the OS to run out of handlers for the process, terminating it.
But this is not a big issue in practice in my experience, in Javac try-with-resources idiomatically solves this issue.
> To be pedantic, you need more than a GC for memory safety. Like a language (type system, bounds checks) that forces you to only look only inside the memory being managed. :-)
True enough :-)
> Also think of stop-the-world problems inherent with GCs. They can be life threatening in real-time systems.
There are GCs that can work in real-time systems, given enough resources. RAII is also not suitable for real-time systems without much care, so the point is pretty much moot. Real-time systems require a level of attention to timing that no regular programming paradigm enables.
> So: yes it's true that it's difficult to write safe code in C++, and many safety bugs are related to memory. But that doesn't mean that code in a GCed language is inherently safer.
It is very much clear that programming in a GC language is safer than in C++ (or C or assembly) - not safe (the log4j vulnerability comes to mind), but absolutely and certainly safer. Rust has a radically new approach to memory safety that seems to offer similar advantages. It's still a little early (not that much internet-connected Rust-based infrastructure) to say for sure, but so far it does seem to offer similar or better safety guarantees as a GC language.
Java has try-with-resource blocks, though. But scope-based resource scopes are fundamentally limiting and static, it is not a generic solution.
Preventing data races is cool, but it’s again, not a complete solution to the general category of race conditions, which are the real issue - and I’m not sure if there is any general enough system that could prevent it whole-sale. Also, java’s data races are well-defined (while if you mess up some unsafe logic in rust, your program is completely unpredictable from that point).
Hard real time is so special that I don’t see much point bringing it up here — standard Rust/C/whatever is also not fit for that in and of itself. For soft real time, some GCs may be more than fine, the occasional frame drop won’t kill anyone for example.
To be pedantic, you need more than a GC for memory safety. Like a language (type system, bounds checks) that forces you to only look only inside the memory being managed. :-)
Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way.
Beyond that there are safety concerns that where the shared memory model managed by the GC bites you. For example: Rust solves threading issues with move semantics and pinning, guiding programmer away from shared mutable state. Also think of stop-the-world problems inherent with GCs. They can be life threatening in real-time systems.
So: yes it's true that it's difficult to write safe code in C++, and many safety bugs are related to memory. But that doesn't mean that code in a GCed language is inherently safer.