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.

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

Lisp implementations have had excellent GCs that are broadly better than the JVM for years.

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?

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

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.

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

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.

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.

Those people are wrong. Malloc and crt0 aren't VM's.

Some people are wrong, the word they are looking for is runtime, not VM.

that's what i was looking for.

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".