4 ms·

Go's GC is in fact much, much worse than the JVM's. One may have less memory issues because Go tends to generate less garbage, though.

by lucian1900 14y ago

louhike 14y ago
Can you prove your statement or give a link to an article on this subject?
- lucian1900 14y ago
  The JVM has several swappable GCs, both mature and new. There is plenty of documentation out there about them. Go has (had?) libgc and is going to get a slightly better GC. I believe it's not even generational. Again, there are plenty of articles about that, especially about the recent and prominent bug on 32bit platforms.
effinjames 14y ago
Go's VM consume less resources, so we gets more RAM. Fore back-end processing, it's a supercool trade off.
- genbattle 14y ago
  First of all; Go is compiled to binary form, it doesn't run on a VM (yet?). Second of all; the words you're looking for are "get" and "For", not "gets" and "Fore". Sorry to be a grammar nazi, but I'm just calling it as I see it, and this isn't Reddit or 4chan (yet?). For others wanting to know more about Go's garbage collection, it used a conservative GC up until recently, but heaps of work has been done to make the GC precise, so we don't get leaks on 32-bit platforms. As far as I know this GC change has yet to be released (current release is 1.0.2, and the changes should be in the next release). That said, if you clone tip and build from there (it's remarkably stable) you should be able to see the differences.
  - tomp 14y ago
    For some people, VM means everything that the language offers to the programmer at runtime. Sometimes libraries, usually GC. Even malloc could be considered VM.
    - batista 14y ago
      It's about what "some people think". This is Computer Science. Things have a name and a definition. By your logic "for some people, Earth is flat".
    - tptacek 14y ago
      Those people are wrong. Malloc and crt0 aren't VM's.
    - EdiX 14y ago
      Some people are wrong, the word they are looking for is runtime, not VM.
      - effinjames 14y ago
        that's what i was looking for.
gnuvince 14y ago
I recall hearing about Don Syme (F#'s creator) talking with the guys working on garbage collection in .NET and when they saw his allocation numbers, they pretty much said that "this much allocation means there's a bug in the program". Different languages with different paradigms and idioms call for different collection strategy; being extremely into the imperative camp, Go programmers tend to hammer away at data structures rather than copy then like is more common in Java (and even more common in functional languages). So I guess that a less polished GC will do an okay job for Go longer than it would for Java.
thebluesky 14y ago
In truth pretty much every language's GC is worse than the JVM's.
- KaeseEs 14y ago
  Lisp implementations have had excellent GCs that are broadly better than the JVM for years.
  - jbooth 14y ago
    Do you have a source for that? I could see a purely functional language creating much less garbage than Java and/or providing much easier escape analysis scenarios, leading to better performance, but I'd be very surprised to see them perform better for similar amounts of heap allocation, given all the work that went into the various Java GC algorithms. I mean, those LISP GCs probably predate wide adoption of threading, right?

Go's GC is in fact much, much worse than the JVM's. One may have less memory issues because Go tends to generate less garbage, though.

louhike 14y ago

Can you prove your statement or give a link to an article on this subject?

lucian1900 14y ago
The JVM has several swappable GCs, both mature and new. There is plenty of documentation out there about them. Go has (had?) libgc and is going to get a slightly better GC. I believe it's not even generational. Again, there are plenty of articles about that, especially about the recent and prominent bug on 32bit platforms.

effinjames 14y ago

Go's VM consume less resources, so we gets more RAM. Fore back-end processing, it's a supercool trade off.

genbattle 14y ago
First of all; Go is compiled to binary form, it doesn't run on a VM (yet?). Second of all; the words you're looking for are "get" and "For", not "gets" and "Fore". Sorry to be a grammar nazi, but I'm just calling it as I see it, and this isn't Reddit or 4chan (yet?). For others wanting to know more about Go's garbage collection, it used a conservative GC up until recently, but heaps of work has been done to make the GC precise, so we don't get leaks on 32-bit platforms. As far as I know this GC change has yet to be released (current release is 1.0.2, and the changes should be in the next release). That said, if you clone tip and build from there (it's remarkably stable) you should be able to see the differences.
- tomp 14y ago
  For some people, VM means everything that the language offers to the programmer at runtime. Sometimes libraries, usually GC. Even malloc could be considered VM.
  - batista 14y ago
    It's about what "some people think". This is Computer Science. Things have a name and a definition. By your logic "for some people, Earth is flat".
  - tptacek 14y ago
    Those people are wrong. Malloc and crt0 aren't VM's.
  - EdiX 14y ago
    Some people are wrong, the word they are looking for is runtime, not VM.
    - effinjames 14y ago
      that's what i was looking for.

gnuvince 14y ago

I recall hearing about Don Syme (F#'s creator) talking with the guys working on garbage collection in .NET and when they saw his allocation numbers, they pretty much said that "this much allocation means there's a bug in the program". Different languages with different paradigms and idioms call for different collection strategy; being extremely into the imperative camp, Go programmers tend to hammer away at data structures rather than copy then like is more common in Java (and even more common in functional languages). So I guess that a less polished GC will do an okay job for Go longer than it would for Java.

thebluesky 14y ago

In truth pretty much every language's GC is worse than the JVM's.

KaeseEs 14y ago
Lisp implementations have had excellent GCs that are broadly better than the JVM for years.
- jbooth 14y ago
  Do you have a source for that? I could see a purely functional language creating much less garbage than Java and/or providing much easier escape analysis scenarios, leading to better performance, but I'd be very surprised to see them perform better for similar amounts of heap allocation, given all the work that went into the various Java GC algorithms. I mean, those LISP GCs probably predate wide adoption of threading, right?