The authors believe that they can make GC a low overhead operation in Go and they believe that it's essential to take memory management out of the hands of the programmer to save programmer effort. Lastly, they say that should you need to you can always work around the GC by doing your own memory management (linked example).
It feels like they are trying to honor Hoare's "premature optimization is the root of all evil" by considering non-GC languages to have optimized the wrong thing.
Go isn't competing with C and C++, it's competing with Java and C#.
This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.
The "tool & library ecosystem" in Java is one of its main reasons why many people avoids it like the plague.
And that using Java is almost impossible without such tools and 'frameworks' doesn't tell you much good about the language itself.
With Go there is little need for such extra stuff, and the tools that exist are very simple and very useful (eg., gofmt, gofix) without being required to make up for deficiencies in the language.
>This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.
I don't even have to do that. In my world, I'm free to oscillate between C and Python, depending on the problem being solved. Bonus: One can call the other.
I have no need for mid-tier corporate languages like Java and C# anymore. Go can be a "better" mid-tier language all it wants, I still won't learn it because it doesn't do anything better than Python or C currently do.
I actively avoid using or creating codebases so grossly-huge that you need the "bug-avoidance" and performance of something like Java and C# to the point where Python is no longer practicable.
When you need more "performance" because your codebase is too fat, you've got a bigger problem that can't be solved with a faster runtime.
But what do I know? I'm just a startup kid who ran screaming from the .NET ecosystem.
It's hard to love Java as a language but I'll still sometimes reach for it over Ruby or Python or C because it's not that much more verbose and it can get within 4x or so of C++ code without even trying.
And often the large codebase finds you, no matter how hard you try to avoid it, and there you start to appreciate some of the design decisions of Java.
I don't deny it has its place for some people, but it's definitely not my experience that
>Ruby or Python or C because it's not that much more verbose
I've seen some shocking differences in LOC and comprehensibility between Ruby/Python vs. Java code, even when a concerted effort has been made to avoid the typical sins of Java codebases.
You might just be more patient than I am, or a better Java programmer. I don't know. All I know is that I end up experiencing kidney failure every time I have to interact with Java code.
> You might just be more patient than I am, or a better Java programmer. I don't know. All I know is that I end up experiencing kidney failure every time I have to interact with Java code.
I don't experience kidney failure, just a sudden urge to scrape my skull against a rough, brick wall. Life is too short for me to spend it dealing with that crap and the community that insists that "Java's not slow", even though it needs gigs and gigs of memory to run (which takes forever to populate and blows your cache), has no shared libraries, no copy-on-write, no memory protection, and no dozens of other things that Unix has had for decades for a reason.
You are severely mistaken about GC then. GC means to a large extent that programmers should know what their objects are doing. Perhaps even more so than in a non-GC'ed language.
The inherent problem with GC is when you put it into hands of people without that knowledge. Then the GC will save them and reclaim their data, whereas it would otherwise be a space leak and dead program. This means that you will have programs that work, but they will run slowly. GC-fanatics like me say that the program has bad productivity since it spends all its time in the garbage collector.
The advantage of GC though is this: If you know what you are doing, you don't need to manage memory in about 90% of your program. It is often either good enough or way faster than doing it yourself. Both in raw performance and in programmer time. A hint is that most modern parallelizing malloc routines use garbage collection internally to make them run more concurrently and faster :)
For the last 10%, the solution is the same as in any other language. You allocate large chunks of memory and then you handle that memory yourself. The advantage is that you only have to do this for a small part of your program and that means you can build software much faster.
The only place where GC is provably a bad idea is in hard real time systems.
> Programmers should know what their objects are doing.
Programmers "should" do lots of things, but designing as if they actually do is usually a mistake. (If vehicle passengers behaved appropriately, air bags wouldn't be a good idea.)
It's better to design wrt what programmers actually do or get new programmers.
I believe that Rob Pike has made the point that garbage collection is required to make the concurrency model practicable. Being Go's foremost raison d'être, its use of CSP should not be ignored or abused, or you won't be getting much out of Go. That's not to say that low-latency garbage collection isn't interesting, or that Go's authors haven't been around this block. (You might be interested to read http://doc.cat-v.org/inferno/concurrent_gc/concurrent_gc.pdf )
Agreed. But sometimes you can know what your object are doing but not want to manage them.
It's tangential, but in my experience coding in Java or any other GC enabled language doesn't mean you can completely ignore the memory management. You still have to watch for leaks, unefficiencies or anything you would have cared for if you managed memory yourself.
The authors believe that they can make GC a low overhead operation in Go and they believe that it's essential to take memory management out of the hands of the programmer to save programmer effort. Lastly, they say that should you need to you can always work around the GC by doing your own memory management (linked example).
It feels like they are trying to honor Hoare's "premature optimization is the root of all evil" by considering non-GC languages to have optimized the wrong thing.