Instead it merely states that Erlang GC has better latency than other system and we're supposed to just believe it.
It's fine as a description of how Erlang GC works but totally useless as an argument that Erlang has short GC pauses.
I would like to see this run with the latest versions of the various platforms, as a lot has changed since Phoenix 0.13, and I'm sure it has for the other platforms that were benchmarked as well. Initially, it seems like there is not a lot of difference between most of the platforms, but when you're working with variances of 1-2 ms on 180k rps is pretty substantial.
EDIT: My mistake, I thought you were the author of the benchmark
Even if we are using a language that manages memory itself
like Erlang, nothing prevents us from understanding how memory
is allocated and deallocated. Unlike Go Language Memory Model
Documentation Page that advices "If you must read the rest of
this document to understand the behavior of your program, you
are being too clever. Don't be clever.", I believe that we must
be clever enough to make our system faster and safer, and
sometimes it doesn't happen unless we dig deeper into what is
Erlang and Go have functional overlap, sure. However the trade-offs between both the guarantees and operational realities of the two languages leaves each one best suited to a different domain. Thus it is a pointless waste of time to argue and criticize one or the other in this manner.
While I may personally appreciate Go's opinionated-ness, it seems to lead to excessive amounts of conflict and drama. I wonder if it's an overall win or loss. On one hand, the controversy sparks interest which helps spread Go. On the other hand, it alienates many folks who may otherwise be open to getting involved.
Food for thought.
TLDR: It looks rather silly to compare languages with very different design goals.
But let's take your argument seriously for a second and pretend that all these terrible designs are actually the best way to achieve Go's design goals: to make a language that compiles fast for giant codebases while maintaining reasonable performance for a huge infrastructure (Google's). If that's the case, why are you using Go? There are a very small handful of companies where these design goals even make sense as goals even if they did achieve them. If you're going to claim that this is about different design goals, then I'm just going to claim that those very design goals are why you shouldn't be using Go.
First off, I'm not an ML-language guy: I have written a small amount of Haskell and respect the work those guys have done, but I'm more of a Scheme and Python guy. And I'm not super ideological about functional programming either; I write a good amount of C and some assembly.
I am all for making pragmatic compromises. Part of what offends me about Go is that they've coopted the idea of pragmatism as their own when in fact the design decisions made by the Go language aren't pragmatic for most users. Pragmatism is rooted in knowledge, having thoroughly investigated solutions and chosen the best based on your goals, not just giving up on implementing stuff because it's hard to implement (which I suspect is what the Go team actually means when they say something's not pragmatic).
In the end though, I think the reason I care is that Go's popularity poisons the industry as a whole. It eliminates places I'm willing to work at, and worse, it lowers the caliber of programmers I can work with. Programmers who use `go generate` aren't going to learn how to use code generation that integrates with a type system. Programmers who unconditionally claim generational garbage collection is too heavyweight aren't going to be able to write programs that allocate larger amounts of memory. Programmers who think "goroutines" are the newest, most innovative, one true way to do threading are going to shoehorn that model into their code in other languages, the same way I shoehorn threading models from other languages into my Java code, except I have a variety of models I've used and I can choose the right threading model for the right situation. And I'm going to have to work with these people at some point, and screen them out in interviews, and I'd rather we just didn't let this shitty language into our industry in the first place.
As the title of post which emphasizes on "WHY GC matters", I tried to reason why we should understand the underlying of a system, say Erlang, Go, Java or whatever else. But unfortunately always there are few documentation around about them and sometimes it is advised not to read them.
I do agree with you that comparing languages with very different goals is totally wrong, but what I did was comparing the Go's documentation author advice with mine, which is about being clever enough to understand your system.
Erlang has had similar corners over time, such as the way it has handled large binaries, where they've needed to reserve the right to change it. (IIRC the docs promise that the large binaries won't be in your process heap, which has been true for a long time, but beyond that, the details have changed significantly.)
That's a very charitable interpretation. If that's what they want to say, they could say that. I just don't buy it.
That's an idiotic thing to say. I don't care if you're saying it about memory synchronization or memory management, it's an idiotic thing to say either way.
Redirecting all criticisms of Go and pretending that they don't apply because Go isn't for anything or about anything seems to be the only defense Go users have. Why not, instead of telling us all the things Go isn't for, or all the things Go docs aren't talking about, why don't you actually use a non-shitty language that's actually useful for something.
Either way a less controversial way to put the Go advice would be:
> If you must read the rest of this document to understand the behavior of your program, you are being untrusting. Don't use things you don't trust.
If you care about memory performance characteristics that much you really should be using a language that gives you control over them.
That's not to say that all GC advice is bad: good GC advice exists and usually sticks to the formal definition of a GC (an infinite memory simulator), instead of implementation details which, again, can change.
Well, not THAT different. Different philosophoes maybe, but the goals were quite similar: a high level language to create network services in (and facilitate concurrency and/or parallilazation).
That said, I believe that if an official third-party specification for Erlang were ever created, it would likely have to specify a similar GC and threading system because this is necessary to allow the normal Erlang programming style.
I see a language barrier here. (no pun intended)