←back to thread

Four Years of Jai (2024)

(smarimccarthy.is)
166 points xixixao | 2 comments | 15 Apr 25 23:17 UTC | HN request time: 0s | source
Show context
pcwalton ◴[18 Apr 25 09:09 UTC] 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 ◴[18 Apr 25 09:17 UTC] 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 ◴[18 Apr 25 09:48 UTC] 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 #
1. sph ◴[18 Apr 25 10:05 UTC] No.43726569[source]▶
That’s fair, no resource is unlimited. My point is that memory is usually the least of one’s problem, even on average machines. Productivity and CPU usage tend to be the bottleneck as a developer and a user. GC is mostly a performance problem rather than a memory one, and well-designed language can minimize the impact of it. (I am working on a message-passing language, and only allowing GC after a reply greatly simplifies the design and performance characteristics)
replies(1): >>43738357 #
2. charleslmunger ◴[19 Apr 25 18:29 UTC] No.43738357[source]▶
>My point is that memory is usually the least of one’s problem, even on average machines.

The average machine a person directly interacts with is a phone or TV at this point, both of which have major BoM restrictions and high pixel density displays. Memory is the primary determination of performance in such environments.

On desktops and servers, CPU performance is bottlenecked on memory - garbage collection isn't necessarily a problem there, but the nature of separate allocations and pointer chasing is.

On battery, garbage collection costs significant power and so it gets deferred (at least for full collections) until it's unavoidable. In practice this means that a large amount of heap space is "dead", which costs memory.

Your language sounds interesting - I've always thought that it would be cool to have a language where generational GC was exposed to the programmer. If you have a server, you can have one new generation arena per request with a write barrier for incoming references from the old generation to the new. Then you could perform young GC after every request, only paying for traversal+move of objects that survived.