The memory safety thing is just a moot out of scope contract. It seems moot to me every time someone shows up trying to push memory safety everywhere, that's a language to developer contract issue, not a functionality issue. When the contract of the language is such as that of Go vs Rust, the two languages are just offering different contracts. Rust just promises to hold your hand more than Go does.
Regarding the JVM and GC. Good luck with that? Every Java application I've seen in the wild when I supported JVM seemed to never release any ram it allocated. Ever. If it used 1G and even after free, the JVM decided that was going to be used again and wouldn't release it.
It would be hard to sell me on wanting to use Java again (people can pay me enough to do it, but I hate it). Which kinda sucks since Apache Foundation has a ton of really cool projects using it. Kotlin maybe, but I have no real use cases where it would be better than anything else I know right now.
When was the lat time you encountered such issue? The JVM has been more proactive in releasing memory back to the OS[1], and more work on dynamically setting the heap size (both up and down)
> People least suitable to wield power are most magnetically attracted to it.
In the current system.*
There are systems that allow you to distribute power more equally. It requires a different setup, like for example randomised choice. The people in power don't like it. It's much easier to bribe 2-3 career politicians and guarantee their success.
It really does matter. I don't know enough about this specific case, but multiple order of magnitude differences in CVE numbers are frequently explained by different policies towards finding and assigning CVEs in many many cases.
Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.
Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1].
Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4].
I agree with your general point that the number of CVEs is a useless metric, though.
The point is that such bugs shouldn't exist in the first place.
Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety.
Every time you call something recursively you should be thinking "how deep is this?".
By that logic, why even spend effort migrating from a known-working implementation to one which is known to have outstanding bugs that there isn't enough bandwidth to fix?
Hard to say, but there are legitimate reasons. One of which being they think Rust is growing while C is a shrinking language. Other could be safety (yes, yes the audit did surface bugs). Or even that having a single lib work seamlessly on Windows/Linux/MacOS/Redux/Web.
It's coming from Go. In presence of data races on interfaces, slices or maps your memory might get corrupted.
> Also why can't I have my memory back when it's not in use in tightly packed systems?
You can. You have to either set your GC to be more aggressive or you need to utilize value types more.
reply