Why I Don't Want to Learn Go
arantaday.com
Why I Don't Want to Learn Go
1–10 of 139 posts
Re: Why I Don't Want to Learn Go
#2Thanks 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.
Re: Why I Don't Want to Learn Go
#3Unfortunately, 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.
Re: Why I Don't Want to Learn Go
#4I 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.
Re: Why I Don't Want to Learn Go
#5Unfortunately, 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 shortcomi…
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
Re: Why I Don't Want to Learn Go
#6This is addressed on the Go FAQ: 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.
Re: Why I Don't Want to Learn Go
#7Go 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.
Re: Why I Don't Want to Learn Go
#8This is addressed on the Go FAQ: 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…
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#.
Re: Why I Don't Want to Learn Go
#9I 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 b…
>>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.)
Re: Why I Don't Want to Learn Go
#10Go 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+…
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.