41–50 of 132 posts
Earlier quoted context omitted.
Why would you mention it? Go is shares all memory, erlang doesn't. It is a different problem.
Actually, IIRC Erlang does have a shared heap, but it is used as an optimization to avoid copying very large objects.
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
> The only true benefit I can think of is reducing heap fragmentation Unless something has changed recently in the literature, concurrent data structures, especially lock free ones are super difficult to get right without garbage collection. Further, lock free structures are one of the most straight forward paths to large non-contended concurrent in memory data sets becoming the norm rather than the exception. I'm am…
(Note that you need generics for lock-free data structures to be ergonomic.)
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
This is the one HN post that I agree with above all others. I also thought I was in a small majority holding this view. I recall being told 15 years ago that I was "a dinosaur" for being skeptical about GC. I'm now a black-belt JVM GC tuner but that has only served to confirm my feelings about GC. You're exchanging the solution of some albeit tricky problems for the acquisition new much worse problems (pauses, inabil…
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
To be clear, modern GCs are truly impressive -- I just don't think that GCs are how we should be addressing memory management. They impress me in the way that, let's say, a Rube Goldberg machine is an impressive way to make toast. I respect the craftsmanship, the creativity, the ingenuity ^_^ but I'd never make toast that way.
> ...there has been a virtuous cycle between software and hardware development. CPU hardware improves, which enables faster software to be written, which in turn... This is the exact opposite of the experience I've had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstracti…
Why would I want to solve the same problem I was solving last year, but just a little bit faster (or more times, if you prefer)? If it was good enough last year, it's probably good enough today. Today I will solve new problems with even more resources.
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
Erlang doesn't do anything different in its GCing algorithms or anything; it just gives each (really tiny) process its own heap, so there's lots of heaps, which can each be GCed at some opportune time when that particular (tiny) process isn't scheduled. It's stop-the-world GC, but with high-granularity worlds.
This seems to suggest, to me, that the "problem" of GC is not in its implementation algorithm. Generational, concurrent, real-time, whatever other clever properties: not important. A GC pass is problematic in proportion to the size of the heap. So, make smaller heaps. The easiest way is smaller processes.
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
To be clear, modern GCs are truly impressive -- I just don't think that GCs are how we should be addressing memory management. They impress me in the way that, let's say, a Rube Goldberg machine is an impressive way to make toast. I respect the craftsmanship, the creativity, the ingenuity ^_^ but I'd never make toast that way.
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
I'm just as confused as you are about most implementations of garbage collection. There's one that feels like it works, though: Erlang's. Erlang doesn't do anything different in its GCing algorithms or anything; it just gives each (really tiny) process its own heap, so there's lots of heaps, which can each be GCed at some opportune time when that particular (tiny) process isn't scheduled. It's stop-the-world GC, but…
Something like ARC would work for Go though (right?), & I agree it's a really nice approach, and I don't really get why it's not more widely used.
I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…
It's something I find annoying about some ARC/Rust enthusiasts: their belief that because they haven't found need for a GC, that there isn't one.
Earlier quoted context omitted.
I'm just as confused as you are about most implementations of garbage collection. There's one that feels like it works, though: Erlang's. Erlang doesn't do anything different in its GCing algorithms or anything; it just gives each (really tiny) process its own heap, so there's lots of heaps, which can each be GCed at some opportune time when that particular (tiny) process isn't scheduled. It's stop-the-world GC, but…
This works for erlang 'cuz it's functional. Not gunna work for something like Go. Something like ARC would work for Go though (right?), & I agree it's a really nice approach, and I don't really get why it's not more widely used.