11 ms·

Why I Don't Want to Learn Go

212 points by dwwoelfel 15y ago

reirob 15y ago
Thanks for the link! The author expresses exactly my thoughts. In essence: Go is not a system-level language (GC) and for problems where performance does not hurt so much there are other alternatives. 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.
babarock 15y ago
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. 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.
- smanek 15y ago
  Do you seriously doubt that the Go GC is significantly worse than the Oracle JVM GC (by the metrics of pause times and throughput)? I don't think I've ever heard anyone suggest that it isn't. My point with this article is simply that, even if Go's GC catches up to the JVMs (which would be an amazing accomplishment in itself), it would still be too inefficient for serious systems work. I provided several real-world examples to that effect. If you want benchmarks, check out the numbers from moving some of the critical allocations off heap (and out of the GCs reign) in the Java HBase project: http://www.slideshare.net/cloudera/hbase-hug-presentation http://www.slideshare.net/cloudera/hbase-hug-presentation
  - flogic 15y ago
    In C, don't people just allocate a slab of memory for critical paths too?
    - nknight 15y ago
      Sometimes, perhaps, but simple malloc/free are much faster and more predictable than what you see in GC'd languages, often mitigating the problem. On top of that, many critical paths can avoid even those by confining their memory allocation to the stack, something that effectively ceases to exist in GC'd languages.
      - edwardw 15y ago
        > but simple malloc/free are much faster and more predictable than what you see in GC'd languages More predictable, very likely. Much faster, this is simply not true. E.g., quotes from an article by Brian Goetz[1]: The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions, whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call. ... "Garbage collection will never be as efficient as direct memory management." And, in a way, those statements are right -- dynamic memory management is not as fast -- it's often considerably faster. > allocation to the stack, something that effectively ceases to exist in GC'd languages.* Not true, either. With escape analysis, Hotspot JVM can do stack allocation. The flag of doing escape analysis is actually turned on by default now. [1] http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html http://www.ibm.com/developerworks/java/library/j-jtp09275/in...
        nknight 15y ago
        That writeup is certainly interesting, mostly with regard to escape analysis, but it's entirely untrustworthy with regard to the comparison to malloc. First, it appears to base its assumptions about malloc implementations on a paper dating to 1993 (WTF?!), second is that it thinks "instructions" is a meaningful metric for judging performance.
      - 15y ago
webjprgm 15y ago
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).
- jamesgeck0 15y ago
  I'm not very familiar with it, but doesn't C# or the CLR let you do something like this with managed and unmanaged code?
- pjmlp 15y ago
  Modula-3, Ada, Oberon are just a few of such languages.
heretohelp 15y ago
I concur with the concurrer and the author with my own more 'positive' addendum: 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 optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C bitfield syntax. Bounds-checked arrays...optionally. Make the distinction very obvious in the code/type-signature. 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. 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. Unicode-native from the ground up. 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. Don't reify language types without enabling people to implement their own data structures at the nitty-gritty level. 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. But most profoundly of all: Make a language that would make writing a library like libev or libevent less bug-ridden and a lot more fun. P.S. I sincerely hope someone writes a "pragmatist's" systems language like this.
- berntb 15y ago
  >>No GC. Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour. Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years). (Not knowledgeable on this; I'm asking, not making an argument.)
  - heretohelp 15y ago
    It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays vs. linked-lists are the trivial but canonical example) The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming. Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming. Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code. I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming. In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.
jgrahamc 15y ago
This is addressed on the Go FAQ: http://tip.golang.org/doc/go_faq.html#garbage_collection http://tip.golang.org/doc/go_faq.html#garbage_collection 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.
- heretohelp 15y ago
  Nobody believes GC is a bad idea, it's a canard to suggest otherwise. It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC. Go isn't competing with C and C++, it's competing with Java and C#.
  - cageface 15y ago
    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.
    - heretohelp 15y ago
      >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.
jrockway 15y ago
Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. 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. 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.) 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.
- smanek 15y ago
  That's fair - the largest code bases I've ever worked on are all less than ~200K LOC. They've enforced style by mandating committers hook a linter into a git pre-commit hook, and compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part). I can imagine that not working at Google-scale.
  - adgar 15y ago
zoul 15y ago
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.
- stcredzero 15y ago
  Check out iGC. The claim is, by tailoring GC to the ObjC runtime in iOS, you can beat ARC's performance with GC. (Look at how ObjC allocates heap and use read/write barriers to reduce the number of roots that have to be traced.)
batista 15y ago
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. 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. Like this example: https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/HDz5KiG6oMY https://groups.google.com/forum/?fromgroups#!topic/golang-nu... [Downvote? Something very controversial about hashmap O behavior?]
- jacquesm 15y ago
  You could compare python with perl or php, you could compare Go with C, C++ or Java. But to compare Go to Python is a bit weird. Of course, you could do it, but why would you, almost every metric that you'd want to use would be off. You're comparing a compiled language with lightweight threads aimed at just-above-low-level programming backed by a single vendor with an interpreted language that is mostly geared towards single threads of execution with a very high level of expressiveness that is developed by a bunch of open source gurus under the supervision of a benevolent dictator.
  - dripton 15y ago
    I think it's fine to compare Go and Python. They're both general-purpose programming languages. When choosing to write a new program, you can often pick either of them. I can imagine problems where either might be a reasonable choice. In fact, there are programs that I've written in both. (Granted, those were Project Euler exercises, not code that someone was paying me to write.) Don't get too caught up in the marketing.
    - jacquesm 15y ago
      > I can imagine problems where either might be a reasonable choice. Yes, I can imagine that too. But there are also a very large number of problems where either one is a (much) better fit, and it would seem to me that that is the majority of problems, not of the 'toy' variety. The biggest factor in picking a language for a specific project is (in my opinion) availability of libraries and familiarity with the language by the team. Python scores very high for a large number of people in both those categories but it has been around for a while. Go is backed by one of the largest software companies on the planet so it stands a chance but google has a bad rep when it comes to cutting off projects in mid stride. The devil is always in the details with choices like these and without knowing more about a specific problem and the people that you intend to do the work with it is hard to say which one is the better fit beforehand.
stcredzero 15y ago
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. 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.
- smanek 15y ago
  It's different, because I'm saying that much system level work has to optimize by not using a garbage collector. I've literally implemented off-heap malloc()/free() in Java because GC is so untenable. I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work. Which means, if Go is to find a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.
  - minimax 15y ago
    I don't think you're getting his point. I can still replace GC with malloc() and we end up with the same criticisms of C that you have of Go and Java. > I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable. Anyone who has had to write fast C programs that make a lot of small objects eventually ends up here. You end up incorporating some sort of pool based allocator, which I'm sure you can come up with in Go just as you can in C (or Java, or whatever).
    - stcredzero 15y ago
      Outside of professionals and core contributors who write performance critical C, most folks haven't done a whole lot of work with a profiler with C programs. One doesn't get performance for free. It's paid for in some way, shape or form. The only thing that's up for grabs is how and when you pay for it. The costliest form of payment is developer hours, which you try not to pay if you can avoid it, though you sometimes can't avoid it.
scanr 15y ago
Why I have learned go: 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. The libraries are great for server side programming. 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. 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.
Roybatty 15y ago
The title is wrong. It should be "Why I Don't Want to Learn Go and You Shouldn't Either"
jbooth 15y ago
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. Go has better integration with C than any other language I've seen.
- pjmlp 15y ago
  Better than C++ and D? You must be joking.
  - jbooth 15y ago
    Ok, not better than C++ and I haven't used D. I should've said "other mid-to-high-level langauge". But using C++ doesn't solve my complaints about the clunkiness of the non-critical path stuff. Still have wacky string handling and I'd rather write my own bintree or hashmap than have to use STL.
    - pjmlp 15y ago
      And throw away years of experience in optimization from the compiler developers? You surely have lots of free time available.
      - jbooth 15y ago
        In fact I don't, which was why I said "critical path in C, rest in Go". Usually I do Java but if I need to use C, I'd like to just write the part that needs to be fast, then drive it using something else. Python is also acceptable when it comes to parsing command line options and the like, and it's as slow as dogshit. "Lots of free time" would be dicking around with cryptic STL error messages.
asdfasdf4321 15y ago
Well, this seems like an 'informed opinion' without any actual sources. http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf "In particular, when garbage collection has ﬁve times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management"
dhconnelly 15y ago
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.
zvrba 15y ago
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++.
fauigerzigerk 15y ago
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. 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.
digamber_kamat 15y ago
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? 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. 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.
- jff 15y ago
  I don't like giving over my life to Google either, but there's a big difference between using Gmail for everything and writing programs in Go. Go is an open source project. You can fork it right now if you want, call it Not-Evil-Go or whatever, and BAM it's no longer controlled by Google. They can never make it just up and disappear, the worst they could manage is to do like Oracle did with OpenSolaris and force the community to fork it.
phatbyte 15y ago
I wonder why aren't they using something like ARC in ObjC instead of GC ?
breckinloggins 15y ago
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". 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.
drucken 15y ago
Article summary: Go is a "better" Java. Why would it claim to be a systems programming language? It is a fair point. If anything it illustrates that Google have mis-marketed the product rather than anything else.

212 points by dwwoelfel 15y ago

Thanks for the link! The author expresses exactly my thoughts. In essence: Go is not a system-level language (GC) and for problems where performance does not hurt so much there are other alternatives. 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.

babarock 15y ago

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

smanek 15y ago
Do you seriously doubt that the Go GC is significantly worse than the Oracle JVM GC (by the metrics of pause times and throughput)? I don't think I've ever heard anyone suggest that it isn't. My point with this article is simply that, even if Go's GC catches up to the JVMs (which would be an amazing accomplishment in itself), it would still be too inefficient for serious systems work. I provided several real-world examples to that effect. If you want benchmarks, check out the numbers from moving some of the critical allocations off heap (and out of the GCs reign) in the Java HBase project: http://www.slideshare.net/cloudera/hbase-hug-presentation http://www.slideshare.net/cloudera/hbase-hug-presentation
- flogic 15y ago
  In C, don't people just allocate a slab of memory for critical paths too?
  - nknight 15y ago
    Sometimes, perhaps, but simple malloc/free are much faster and more predictable than what you see in GC'd languages, often mitigating the problem. On top of that, many critical paths can avoid even those by confining their memory allocation to the stack, something that effectively ceases to exist in GC'd languages.
    - edwardw 15y ago
      > but simple malloc/free are much faster and more predictable than what you see in GC'd languages More predictable, very likely. Much faster, this is simply not true. E.g., quotes from an article by Brian Goetz[1]: The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions, whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call. ... "Garbage collection will never be as efficient as direct memory management." And, in a way, those statements are right -- dynamic memory management is not as fast -- it's often considerably faster. > allocation to the stack, something that effectively ceases to exist in GC'd languages.* Not true, either. With escape analysis, Hotspot JVM can do stack allocation. The flag of doing escape analysis is actually turned on by default now. [1] http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html http://www.ibm.com/developerworks/java/library/j-jtp09275/in...
      - nknight 15y ago
        That writeup is certainly interesting, mostly with regard to escape analysis, but it's entirely untrustworthy with regard to the comparison to malloc. First, it appears to base its assumptions about malloc implementations on a paper dating to 1993 (WTF?!), second is that it thinks "instructions" is a meaningful metric for judging performance.
    - 15y ago

webjprgm 15y ago

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

jamesgeck0 15y ago
I'm not very familiar with it, but doesn't C# or the CLR let you do something like this with managed and unmanaged code?
pjmlp 15y ago
Modula-3, Ada, Oberon are just a few of such languages.

heretohelp 15y ago

I concur with the concurrer and the author with my own more 'positive' addendum: 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 optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C bitfield syntax. Bounds-checked arrays...optionally. Make the distinction very obvious in the code/type-signature. 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. 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. Unicode-native from the ground up. 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. Don't reify language types without enabling people to implement their own data structures at the nitty-gritty level. 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. But most profoundly of all: Make a language that would make writing a library like libev or libevent less bug-ridden and a lot more fun. P.S. I sincerely hope someone writes a "pragmatist's" systems language like this.

berntb 15y ago
>>No GC. Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour. Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years). (Not knowledgeable on this; I'm asking, not making an argument.)
- heretohelp 15y ago
  It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays vs. linked-lists are the trivial but canonical example) The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming. Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming. Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code. I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming. In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.

jgrahamc 15y ago

This is addressed on the Go FAQ: http://tip.golang.org/doc/go_faq.html#garbage_collection http://tip.golang.org/doc/go_faq.html#garbage_collection 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.

heretohelp 15y ago
Nobody believes GC is a bad idea, it's a canard to suggest otherwise. It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC. Go isn't competing with C and C++, it's competing with Java and C#.
- cageface 15y ago
  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.
  - heretohelp 15y ago
    >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.

jrockway 15y ago

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. 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. 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.) 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.

smanek 15y ago
That's fair - the largest code bases I've ever worked on are all less than ~200K LOC. They've enforced style by mandating committers hook a linter into a git pre-commit hook, and compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part). I can imagine that not working at Google-scale.
- adgar 15y ago

zoul 15y ago

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.

stcredzero 15y ago
Check out iGC. The claim is, by tailoring GC to the ObjC runtime in iOS, you can beat ARC's performance with GC. (Look at how ObjC allocates heap and use read/write barriers to reduce the number of roots that have to be traced.)

batista 15y ago

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. 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. Like this example: https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/HDz5KiG6oMY https://groups.google.com/forum/?fromgroups#!topic/golang-nu... [Downvote? Something very controversial about hashmap O behavior?]

jacquesm 15y ago
You could compare python with perl or php, you could compare Go with C, C++ or Java. But to compare Go to Python is a bit weird. Of course, you could do it, but why would you, almost every metric that you'd want to use would be off. You're comparing a compiled language with lightweight threads aimed at just-above-low-level programming backed by a single vendor with an interpreted language that is mostly geared towards single threads of execution with a very high level of expressiveness that is developed by a bunch of open source gurus under the supervision of a benevolent dictator.
- dripton 15y ago
  I think it's fine to compare Go and Python. They're both general-purpose programming languages. When choosing to write a new program, you can often pick either of them. I can imagine problems where either might be a reasonable choice. In fact, there are programs that I've written in both. (Granted, those were Project Euler exercises, not code that someone was paying me to write.) Don't get too caught up in the marketing.
  - jacquesm 15y ago
    > I can imagine problems where either might be a reasonable choice. Yes, I can imagine that too. But there are also a very large number of problems where either one is a (much) better fit, and it would seem to me that that is the majority of problems, not of the 'toy' variety. The biggest factor in picking a language for a specific project is (in my opinion) availability of libraries and familiarity with the language by the team. Python scores very high for a large number of people in both those categories but it has been around for a while. Go is backed by one of the largest software companies on the planet so it stands a chance but google has a bad rep when it comes to cutting off projects in mid stride. The devil is always in the details with choices like these and without knowing more about a specific problem and the people that you intend to do the work with it is hard to say which one is the better fit beforehand.

stcredzero 15y ago

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

smanek 15y ago
It's different, because I'm saying that much system level work has to optimize by not using a garbage collector. I've literally implemented off-heap malloc()/free() in Java because GC is so untenable. I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work. Which means, if Go is to find a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.
- minimax 15y ago
  I don't think you're getting his point. I can still replace GC with malloc() and we end up with the same criticisms of C that you have of Go and Java. > I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable. Anyone who has had to write fast C programs that make a lot of small objects eventually ends up here. You end up incorporating some sort of pool based allocator, which I'm sure you can come up with in Go just as you can in C (or Java, or whatever).
  - stcredzero 15y ago
    Outside of professionals and core contributors who write performance critical C, most folks haven't done a whole lot of work with a profiler with C programs. One doesn't get performance for free. It's paid for in some way, shape or form. The only thing that's up for grabs is how and when you pay for it. The costliest form of payment is developer hours, which you try not to pay if you can avoid it, though you sometimes can't avoid it.

scanr 15y ago

Why I have learned go: 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. The libraries are great for server side programming. 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. 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.

Roybatty 15y ago

The title is wrong. It should be "Why I Don't Want to Learn Go and You Shouldn't Either"

jbooth 15y ago

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. Go has better integration with C than any other language I've seen.

pjmlp 15y ago
Better than C++ and D? You must be joking.
- jbooth 15y ago
  Ok, not better than C++ and I haven't used D. I should've said "other mid-to-high-level langauge". But using C++ doesn't solve my complaints about the clunkiness of the non-critical path stuff. Still have wacky string handling and I'd rather write my own bintree or hashmap than have to use STL.
  - pjmlp 15y ago
    And throw away years of experience in optimization from the compiler developers? You surely have lots of free time available.
    - jbooth 15y ago
      In fact I don't, which was why I said "critical path in C, rest in Go". Usually I do Java but if I need to use C, I'd like to just write the part that needs to be fast, then drive it using something else. Python is also acceptable when it comes to parsing command line options and the like, and it's as slow as dogshit. "Lots of free time" would be dicking around with cryptic STL error messages.

asdfasdf4321 15y ago

Well, this seems like an 'informed opinion' without any actual sources. http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf "In particular, when garbage collection has ﬁve times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management"

dhconnelly 15y ago

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.

zvrba 15y ago

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

fauigerzigerk 15y ago

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

digamber_kamat 15y ago

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

jff 15y ago
I don't like giving over my life to Google either, but there's a big difference between using Gmail for everything and writing programs in Go. Go is an open source project. You can fork it right now if you want, call it Not-Evil-Go or whatever, and BAM it's no longer controlled by Google. They can never make it just up and disappear, the worst they could manage is to do like Oracle did with OpenSolaris and force the community to fork it.

phatbyte 15y ago

I wonder why aren't they using something like ARC in ObjC instead of GC ?

breckinloggins 15y ago

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

drucken 15y ago

Article summary: Go is a "better" Java. Why would it claim to be a systems programming language? It is a fair point. If anything it illustrates that Google have mis-marketed the product rather than anything else.