261–270 of 336 posts
Earlier quoted context omitted.
They are considered in many research labs since Xerox, unfortunately there are still too much anti-GC religion among mainstream devs.
I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill. Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.
Earlier quoted context omitted.
I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill. Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.
Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it. It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either. That a GC is adverse to the performanc…
Earlier quoted context omitted.
> Maybe systems that are severely I/O bound but is barely a thing these days. Any kind of web service is barely a thing today? Which is what 99% of HN posters are working on, hence my comment. > High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either Games are high-performance throughput-optimized systems that have adopted GC languag…
If you are severely I/O bound it isn't intrinsic, it means your server is badly under-provisioned in the I/O department. Linux on a modern server can push 200 GB/s of I/O. Even if web services were engineered to a standard that could consume that much I/O, which they are not, you would have to be astonishingly wasteful to burn it all. It is rare to be severely I/O bound because software engineered for I/O performance…
That said, from your profile, you seem to work on a very sensitive niche that might colour your opinion, with good reason. What I am claiming is most of us are not building such strict a system.
Even in my toy hobby of OS development a GC isn’t the end of the world unless your goal is to compete with, say, Linux in a some kind of performance challenge, where in that case memory allocation might be the least of your bottlenecks.
Earlier quoted context omitted.
> Maybe systems that are severely I/O bound but is barely a thing these days. Any kind of web service is barely a thing today? Which is what 99% of HN posters are working on, hence my comment. > High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either Games are high-performance throughput-optimized systems that have adopted GC languag…
If you are severely I/O bound it isn't intrinsic, it means your server is badly under-provisioned in the I/O department. Linux on a modern server can push 200 GB/s of I/O. Even if web services were engineered to a standard that could consume that much I/O, which they are not, you would have to be astonishingly wasteful to burn it all. It is rare to be severely I/O bound because software engineered for I/O performance…
Earlier quoted context omitted.
Could you elaborate on "GCs are not used there [high-performance throughput-optimized systems]"? Are you referring to the cascading effects of tail latency on systems with high fanout?
Sophisticated throughput-optimized systems rely on deep latency-hiding. Schedulers see millions of atomic operations into the future, continuously rewriting the schedule globally to maximize locality and minimize resource contention based on real-time changes to workload, resource availability, and system behaviors. In short, for each of the millions of in-flight operations (which might only map to a handful of user…
Earlier quoted context omitted.
Many people try to twist the fact memory safe languages have unsafe code blocks to make the pivot that why bother. It is like someone arguing that since they always bump the head somehow while wearing seatbelts, then they are only a nuisance and should not be used.
Memory safe languages, where usage of Miri and Valgrind (tools to for instance debug memory unsafety) are common and integrated into CI for some of the projects in the language. Even some Rust guides encourages running Miri in CI https://microsoft.github.io/RustTraining/engineering-book/ch... . Searching on GitHub yields a lot of projects that run Miri in CI. And there have been a lot of CVEs for Rust projects caused…
Yes, those unsafe blocks should be cross checked, but lets not pretend it is the same as writing C or C++ where each line of code is a possible CVE.
Earlier quoted context omitted.
I adore unsafe, appreciate it as a feature... but it is an escape hatch. One that is sometimes necessary, one that is sometimes not necessary but might still be (ab)used for performance, or initial 1:1 porting of C/C++ code. There are a lot of cases where that escape hatch should probably welded shut though. Fortunately, the Rust ecosystem has tools like `cargo geiger`, and straight out of the box I can also write: /…
I feel like this perpetuates a bad mental model. Unsafe is not an escape hatch. Code within unsafe blocks must uphold the same semantics as code outside it but the compiler cannot guarantee that those semantics are upheld. If we're using analogies, `unsafe` is like a "hard hat required" sign. There's nothing intrinsically different about the space inside or outside of it, other than that you can't be sure a brick isn…
Earlier quoted context omitted.
Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026. > Memory safety is necessary, but not sufficient, I fully agree!
> I fully agree! But why then did you conflate safety and memory safety? > Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026. No, there is a lot of unsafe in both Rust's standard library and in non-stan…
That's the power of Rust, not a limitation of it. Rust thrives on its ability to provide safe interfaces over unsafe code.
You'll see this practice in other languages too; if you're coding safe Java, you're using a lot of unsafe code from the JVM and via JNI.
If you're using Python, the stdlib and all the performance-sensitive libraries (numpy, pandas, etc) are written in unsafe code, but even when you import those we still say your Python code is safe, and that Python overall is a memory safe language.
Earlier quoted context omitted.
Of course they are, anything can be a gateway to inject backdoors, if security is not taken into account. And as mentioned, if what Zig offers is already in Purify, there is hardly any added value over C and C++, without the headaches of a niche language.
Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.
Earlier quoted context omitted.
Sophisticated throughput-optimized systems rely on deep latency-hiding. Schedulers see millions of atomic operations into the future, continuously rewriting the schedule globally to maximize locality and minimize resource contention based on real-time changes to workload, resource availability, and system behaviors. In short, for each of the millions of in-flight operations (which might only map to a handful of user…
Real time GC as used by the military in weapons control systems, and on factory automation robots, keeping PTC and Aicas in business, people pay to use them.
For throughput-optimized systems, some of which are real-time, you never see a GC. That loss in performance is simply too large such that the computation becomes intractable. A lot of really poor systems admittedly exist but no one considers them “good”.