5 ms·

It is weird, I do not feel restricted when I write non-GC code. Btw. you still need to pay attention with GCd languages no to leak references that cannot be GCd

It is weird, I do not feel restricted when I write non-GC code. Btw. you still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Rust made it easy and simple to deal with memory in a non-malloc level while not having GC. Erlang on the other hand has a VM that makes GC much faster than in other languages. I can live with that because if you do it right it does not impact end user latency. For me both Rust and Erlang gives the cake + eat it feeling.

jerf 7y ago
"I can live with that because if you do it right it does not impact end user latency." The vast majority of GC use does not impact end user latency. Thinking otherwise is either the availability heuristic at work, or you work in AAA videogames or another ultra-high-real-time-performance industry and don't realize you're not in the center of programming work, you're on an extreme. (A perfectly valid and sizeable extreme.) This may also be why you don't feel restricted; if you happen to work in any of the many places where a tree of references is adequate, you'll find Rust-style management to be a treat. If you work pervasively with graph structures in the core of your program, though, the experience can change. Pervasively-graph-type-structures are generally just a question of how you want your automated garbage collection to work, because I'm pretty sure getting the manual management correct otherwise is effectively impossible without an algorithm that's going to look a lot like a GC. That said, despite my disagreement, I also disagree with the people who, as of this writing, have downvoted your comment into grey. I feel like I've been seeing a burst of "downvote as disagreement" in the past couple of weeks.
- MrEldritch 7y ago
  "Downvote as disagreement" is such a pervasive pattern that I Find myself doing it automatically even when I know that's not what downvote is "supposed" to be for. I suspect it's because I'm more likely to view posts that I disagree with as being poorly thought-out. This even extends to platforms where downvoting is not a thing - witness 4chan's struggles with "sage is not a downvote" ("sage" being a function which allowed you to reply to a thread without bumping it to the top and extending its lifespan - again, intended to mark a thread as low qualit) until they finally gave up and made saging invisible. Given how thoroughly inescapable downvoting-to-disagree seems, I wonder if it might not be better to just declare defeat, allow downvotes and upvotes to mean nothing beyond a signal of protest or agreement, and have a separate "this comment is low quality / this comment is high quality" buttons.
  - wglb 7y ago
    PG long ago said that it is ok to use downvotes (in part) to signal disagreement.
coldtea 7y ago
>It is weird, I do not feel restricted when I write non-GC code. Some people don't feel C has any safety issues either -- perhaps they think all others are idiots and their code is mistake proof because they do it right.
apta 7y ago
> still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Unless you're doing weird things with class loaders, this is a non-issue. > Erlang on the other hand has a VM that makes GC much faster than in other languages What makes Erlang's VM make GC faster than other languages?
- geocar 7y ago
  That's a very loaded question. I don't think it's easy to point to one thing Erlang is doing and say that is why it's faster, partly because I think the way Erlang programmers are encouraged to write their programs also has an effect; The language itself may have a greater effect on its GC performance than the GC implementation itself. As an example: In Erlang, we have function calls like F(X) but we also have message sends like F!X. Message sends get one type of memory treatment, while function calls get another one. The lifetime of objects you send via messaging is going to be different, and yet Java only has function(method) calls, so there's no way to hint this to Java. Maybe this information can be recovered with static/dynamic analysis, but in Erlang we have syntax to tell the VM what's going to happen. If you want to learn more about Erlang's internals, I can recommend Joe's original paper on the subject: http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397570F246B379399EB5A3FDDFF2C5E?doi=10.1.1.42.7791 http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397... since it describes a lot of the design that went into Erlang early, and: http://www.it.uu.se/research/publications/lic/2005-001/ http://www.it.uu.se/research/publications/lic/2005-001/ which while long, quite in-depth describes many of the sub-optimisations that can be realised on top of it.
  - apta 7y ago
    Thanks for the links. That being said, new developments in GCs on the JVM (like Shenandoah and ZGC) are yielding very impressive results. Things like < 1ms pause times for heaps in the TB range. No other free GC for any other language approaches this as far as I'm aware, including golang's which people claim is fast, but completely gets destroyed for even heaps in the GB range (I did some benchmarks).

jerf 7y ago

"I can live with that because if you do it right it does not impact end user latency." The vast majority of GC use does not impact end user latency. Thinking otherwise is either the availability heuristic at work, or you work in AAA videogames or another ultra-high-real-time-performance industry and don't realize you're not in the center of programming work, you're on an extreme. (A perfectly valid and sizeable extreme.) This may also be why you don't feel restricted; if you happen to work in any of the many places where a tree of references is adequate, you'll find Rust-style management to be a treat. If you work pervasively with graph structures in the core of your program, though, the experience can change. Pervasively-graph-type-structures are generally just a question of how you want your automated garbage collection to work, because I'm pretty sure getting the manual management correct otherwise is effectively impossible without an algorithm that's going to look a lot like a GC. That said, despite my disagreement, I also disagree with the people who, as of this writing, have downvoted your comment into grey. I feel like I've been seeing a burst of "downvote as disagreement" in the past couple of weeks.

MrEldritch 7y ago
"Downvote as disagreement" is such a pervasive pattern that I Find myself doing it automatically even when I know that's not what downvote is "supposed" to be for. I suspect it's because I'm more likely to view posts that I disagree with as being poorly thought-out. This even extends to platforms where downvoting is not a thing - witness 4chan's struggles with "sage is not a downvote" ("sage" being a function which allowed you to reply to a thread without bumping it to the top and extending its lifespan - again, intended to mark a thread as low qualit) until they finally gave up and made saging invisible. Given how thoroughly inescapable downvoting-to-disagree seems, I wonder if it might not be better to just declare defeat, allow downvotes and upvotes to mean nothing beyond a signal of protest or agreement, and have a separate "this comment is low quality / this comment is high quality" buttons.
- wglb 7y ago
  PG long ago said that it is ok to use downvotes (in part) to signal disagreement.

coldtea 7y ago

>It is weird, I do not feel restricted when I write non-GC code. Some people don't feel C has any safety issues either -- perhaps they think all others are idiots and their code is mistake proof because they do it right.

apta 7y ago

> still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Unless you're doing weird things with class loaders, this is a non-issue. > Erlang on the other hand has a VM that makes GC much faster than in other languages What makes Erlang's VM make GC faster than other languages?

geocar 7y ago
That's a very loaded question. I don't think it's easy to point to one thing Erlang is doing and say that is why it's faster, partly because I think the way Erlang programmers are encouraged to write their programs also has an effect; The language itself may have a greater effect on its GC performance than the GC implementation itself. As an example: In Erlang, we have function calls like F(X) but we also have message sends like F!X. Message sends get one type of memory treatment, while function calls get another one. The lifetime of objects you send via messaging is going to be different, and yet Java only has function(method) calls, so there's no way to hint this to Java. Maybe this information can be recovered with static/dynamic analysis, but in Erlang we have syntax to tell the VM what's going to happen. If you want to learn more about Erlang's internals, I can recommend Joe's original paper on the subject: http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397570F246B379399EB5A3FDDFF2C5E?doi=10.1.1.42.7791 http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397... since it describes a lot of the design that went into Erlang early, and: http://www.it.uu.se/research/publications/lic/2005-001/ http://www.it.uu.se/research/publications/lic/2005-001/ which while long, quite in-depth describes many of the sub-optimisations that can be realised on top of it.
- apta 7y ago
  Thanks for the links. That being said, new developments in GCs on the JVM (like Shenandoah and ZGC) are yielding very impressive results. Things like < 1ms pause times for heaps in the TB range. No other free GC for any other language approaches this as far as I'm aware, including golang's which people claim is fast, but completely gets destroyed for even heaps in the GB range (I did some benchmarks).