Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits.<p>One key feature is that the Go compiler itself is the style guide: it automatically reformats your code to remove style guide violations. This makes it easy to work on a codebase the size of Google's because everything looks like it was written by the same person. We try to do the same thing for C++, Java, and Python, but it doesn't work as well because the process is manual.<p>Similarly, compilation time and runtime for every component, no matter how unimportant, is of utmost importance for Google's codebase. It may not matter how long it takes to run one one-off script, and it may not matter to you how long it takes to compile, but it does matter at Google because we compile every project and run every test after every commit. (OK, builds and tests that are obviously unaffected are skipped. But it's still a lot of code being built and tested.) So your Python project that takes 5 seconds to run tests instead of 1 second ends up wasting decades of CPU time throughout its life time. Same for C++ projects that take many hours to compile. Go tries to be as expressive as Python and run as fast as Java (and compile faster than anything else), and this saves lots of time in aggregate. (Remember, when you break someone's build, the delay between submitting your change and the system knowing about the breakage can result in a lot of hair-pulling for the developers on the project you broke. But if we can know the build is broken before the change is even submitted, then many hours of developer productivity are saved.)<p>Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go. Google is a special case and just because we have some problem doesn't mean you should have the same problems. One-man shops should optimize for individual efficiency instead of aggregate efficiency like Google does.
This is addressed on the Go FAQ: <a href="http://tip.golang.org/doc/go_faq.html#garbage_collection" rel="nofollow">http://tip.golang.org/doc/go_faq.html#garbage_collection</a><p>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).<p>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.
Unfortunately, as much as I want to agree with it, the article seriously lacks any credibility. Go claims to present high-level features (namely GC) for low-level system programming. Obviously, this sounds new and ground-breaking. Simply dismissing it on account that "GC is unacceptable [for low level problems]" is nothing short of stating a disbelief: it doesn't prove anything.<p>If anyone wants to prove any shortcoming, than maybe they should come up with a more technical analysis, or at least some sort of benchmarking.
Where Go fits in seems very clear to me. It is a less memory hungry and less verbose replacement for Java, fit for the age of fine grained parallelism.<p>Go will never replace C/C++ for embedded systems and operating systems. Go will never replace JavaScript in the browser. And Go will never replace Haskell, Lisp, ML, Scheme, etc, for those who have a very deep interest in programming languages themselves.
As for the GC speed, how do GC and manual memory management compare to the Automatic Reference Counting system that was introduced recently into Objective-C? It looks to me as ARC has the advantages of both worlds: it relieves the programmer from managing memory by hand and has no overhead, as the decisions are made during compilation. I'm a bit frustrated each time people talk about GC and manual memory management and act like they were the only options available.
Thanks for the link! The author expresses exactly my thoughts.<p>In essence: Go is not a system-level language (GC) and for problems where performance does not hurt so much there are other alternatives.<p>To add my personal opinion: I would not consider Go for another reason - I will not invest in a language that is backed by one company. I did this once with Java and I will not hurt myself again. Java's start was fantastic but then came all the business crap like EJBs and tons of frameworks.
Why I have learned go:<p>The overlap between problems that I'd like to solve with node.js and go is pretty large and I prefer being able to use a statically typed language with coroutines and multicore support built in.<p>The libraries are great for server side programming.<p>Go optimises for both speed and memory usage. Folk who run benchmarks often seem to ignore the latter but given how the cloud is priced, optimising for memory usage can be a big win.<p>Go's GC is suboptimal at the moment. That said, I suspect that it'll improve pretty quickly. Go benefits from all those lessons learned during the man centuries spent building the Java GC.
<i>And before you tell me that the GC isn't that big a deal: it is. Literally every big project I've worked on in a garbage collected language reserves a bunch of memory off-heap at startup and uses that for allocations on the critical path because the GC kills performance.</i><p>You could replace occurrences of GC with malloc, switch the language to C, and it would be just as factual. Basically, what the author is saying is equivalent to, "Real projects have to optimize." Well, yes. This isn't deep. It certainly isn't surprising, and it doesn't strike me as a good reason for not learning a language.
I understand and recognize as valid all of the author's concerns. I am personally using Go for things that I used to do in Java. I recognize that this may not be realistic for people heavily invested in the JVM, but I'm finding development with Go to be much more enjoyable than Java.
I agree with the GC point. If I'm using a low-level language, my litmus test is "could I write an OS Kernel in it".<p>I have a naive question: could GC in Go be replaced with something like Apple's Automatic Reference Counting (ARC)? It could be an optional feature backed by inserting real alloc(), retain(), release(), and destroy() calls, so you'd still have full control if you wanted to turn it off.
The thing with Go is, it's really easy to write your critical path in C and then write the other 95% of the code in Go and not have to deal with crap like null-terminated strings and a lack of built-in data structures.<p>Go has better integration with C than any other language I've seen.
Why can't someone make a language where you can optionally use GC on one chunk of memory and use automated reference counting on another chunk? Tell the compiler which variables should be in which category, and then most of the quick programming is done in GC while all the stuff that needs to be performant will be in reference counting but automatically managed so you shouldn't have to know outside of the one keyword to flag the variable and occasionally breaking a cycle when you want to free a structure (or using weak references like Obj-C allows).
I think a large portion of online life is already ruled by Google. I will never use Go only because it comes from Google. A mobile with Google's OS, a Google browser and Google for email and now we will also code in a language controlled by Google?<p>I have nothing against Google, but as a community of web developers our interest lies in diversifying and ensuring that no one gets more powerful than us.<p>Also looking at the features of Go itself, it seems to me that the languages caters to many needs of Google and not many of us may have those needs.
Article summary: Go is a "better" Java. Why would it claim to be a systems programming language?<p>It is a fair point. If anything it illustrates that Google have mis-marketed the product rather than anything else.
In light of C++11, I see Go as something rather obsolete. I see absolutely no reason why I should spend my time on a language that's different just for the sake of it, instead of studying new features of C++.
I concur with the concurrer and the author with my own more 'positive' addendum:<p>I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds <i>optional</i> compile and runtime semantics that can be very helpful and powerful.<p>Some ideas:<p>No GC. This is <i>NOT</i> negotiable. I'm tired of belabouring that point.<p>Give me something nicer than the current C bitfield syntax.<p>Bounds-checked arrays...optionally. Make the distinction very obvious in the code/type-signature.<p>Higher-order functions, optionally. I don't really want an object system, just the ability to utilize callbacks in perhaps a nicer way than how function pointers currently function. I'd actually be happy with a standardized syntax sugar for function pointers.<p>Compile-time (only!) duck-typing and polymorphism. This part I think Go got right, but its sins were too great and the problem it was solving too poorly defined to make up for this.<p>Unicode-native from the ground up.<p>Clean up the string/array/pointer conflation, adopt the semantics of the bstring library as the default string type for the language, but leave open the door for 'raw-er' string implementations.<p>Don't reify language types without enabling people to implement their own data structures at the nitty-gritty level.<p>Cross-OS green-threads might be nice. Let people define their own concurrency models and semantics on top of what the language provides by default though. Same problem as the language type reification, don't delude yourself into thinking you've solved the world's problems with your subset of solutions. Let people use things like ptrheads without punishing them for doing so.<p>But most profoundly of all:<p>Make a language that would make writing a library like libev or libevent less bug-ridden and a lot more fun.<p>P.S. I sincerely hope someone writes a "pragmatist's" systems language like this.
For all the talk of the speed benefits of Go, and it being static et all, I don't see much improvement over, say, Python.<p>A lot of the questions re speed bumps on the mailing list are answered with "those are microbenchmarks, what matters is real cases" and generally a "lalala hands in the ears approach", even when it's obvious that the problem is deeper than some microbenchmark only case.<p>Like this example:<p><a href="https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/HDz5KiG6oMY" rel="nofollow">https://groups.google.com/forum/?fromgroups#!topic/golang-nu...</a><p>[Downvote? Something very controversial about hashmap O behavior?]