←back to thread

Four Years of Jai (2024)

(smarimccarthy.is)
166 points xixixao | 4 comments | | HN request time: 0.001s | source
Show context
pcwalton ◴[] No.43726315[source]
> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes.

That exists; it's called garbage collection.

If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd.

replies(4): >>43726355 #>>43726431 #>>43727184 #>>43731326 #
sph ◴[] No.43726355[source]
The faster computers get, the more the GC problem is way overblown apart from super-low-latency niches. Even AAA games these days happily run on GC languages.

There is a prominent contributor to HN whose profile says they dream of a world where all languages offer automatic memory management and I think about that a lot, as a low-level backend engineer. Unless I find myself writing an HFT bot or a kernel, I have zero need to care about memory allocation, cycles, and who owns what.

Productivity >> worrying about memory.

replies(4): >>43726479 #>>43726679 #>>43729279 #>>43729921 #
lifthrasiir ◴[] No.43726479[source]
GC doesn't exactly solve your memory problem; it typically means that your memory problem gets deferred quite far until you can't ignore that. Of course it is also quite likely that your program will never grow to that point, which is why GC works in general, but also why there exists a desire to avoid it when makes sense.
replies(3): >>43726569 #>>43726586 #>>43730602 #
mjburgess ◴[] No.43726586[source]
Not sure why you're down-voted, this is correct.

In games you have 16ms to draw billion+ triangles (etc.).

In web, you have 100ms to round-trip a request under abitarily high load (etc.)

Cases where you cannot "stop the world" at random and just "clean up garbage" are quite common in programming. And when they happen in GC'd languages, you're much worse off.

replies(2): >>43726627 #>>43730012 #
Tomte ◴[] No.43730012[source]
That's why it's good that GC algorithms that do not "stop the world" have been in production for decades now.
replies(1): >>43732292 #
pebal ◴[] No.43732292[source]
There are none, at least not production grade.
replies(2): >>43732497 #>>43735137 #
kelseyfrog ◴[] No.43732497[source]
There are none, or you're not aware of their existence?
replies(1): >>43732755 #
pebal ◴[] No.43732755[source]
There are no production implementations of GC algorithms that don't stop the world at all. I know this because I have some expertise in GC algorithms.
replies(1): >>43733113 #
kelseyfrog ◴[] No.43733113[source]
I'm curious why you don't consider C4 to be production grade
replies(1): >>43735299 #
1. pebal ◴[] No.43735299{3}[source]
Azul C4 is not a pauseless GC. In the documentation it says "C4 uses a 4-stage concurrent execution mechanism that eliminates almost all stop-the-world pauses."
replies(1): >>43738741 #
2. kelseyfrog ◴[] No.43738741[source]
Except the documentation says

> C4 differentiates itself from other generational garbage collectors by supporting simultaneous-generational con- currency: the different generations are collected using concurrent (non stop-the-world) mechanisms

replies(1): >>43739876 #
3. pebal ◴[] No.43739876[source]
It doesn't matter at all. C4 uses STW.
replies(1): >>43740239 #
4. kelseyfrog ◴[] No.43740239{3}[source]
I wish I could have learned more from this interaction than it doesn't matter.