Hacker News new | ask | show | jobs
by zRedShift 1311 days ago
I don't even disagree with these points! But if you go down to language lawyering and semantics, I think one could technically make a case for Rust being safer (in the memory safety sense) than Java/Go/(insert any GC'd memory safe language that features synchronization primitives as an opt-in feature, think volatile in Java), if only on the merit of protecting you from data races.

Elixir is great, use elixir. I certainly am not stopping you, it's completely safe and fault tolerant. Or maybe I'm saying this because I don't know as much about Elixir/BEAM internals compared to the aforementioned languages, who knows.
1 comments
kaba0 1310 days ago
That’s not true - if anything, Java is much more memory safe. Even data races are well-defined and are not prone to “out-of-thin-air” values.

If you ever go down the safe road in Rust (be it a buggy library n layers down that you use from entirely safe code), you can no longer be sure in anything, a data race is entirely undefined behavior.

link
zRedShift 1308 days ago
How is it different from "If you ever go down the JNI road in Java"? Be it a library the bundles RocksDB, or Android stuff, doesn't matter that your average Spring Boot developer probably won't be having any native dependencies (unless they use Kafka Streams or something else that bundles a native dependency that had CVEs that needed to be patched). Just as a Rust high-level Back-End developer that works with axum, sqlx, tokio etc. (vs Netty/NIO in Java for example, which also use unsafe/native code) hopefully won't be using buggy unsafe libraries.

Does the JVM protect you from partial reads? On Hotspot or on say, GraalVM's LLVM runtime too? Does Go? I assume they at least protect you from stale read UAFs by virtue still being traceable. (This is a genuine question).

link
kaba0 1308 days ago
Java is probably the most self-reliant platform out there, it is almost completely pure, as in being written in Java or in another JVM language. Besides places where it is absolutely necessary (e.g. opengl), there is simply no JNI used, or only very rarely.
link