1. Most programers (above and below average) can just pick-up Go and be productive without much hand-holding.
2. Most programers can, without much experience, pick anyone's Go code and understand what it's doing.
Working in a company where we introduced Go for backend services without anyone knowing much about it, I know first hand those 2 are true for Go. But I'm not so sure about how OCaml, F#, Haskell or Scala would do with some of my colleagues in that sense.
If you think team productivity only matters to managers, that's kind of sad.
People call it a lowest common demoninator language as a way to dismiss it, but it's actually incredibly well thought out by a lot of really smart people, several of whom have been writing code for longer than most people on HN have been alive.
The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned.
Sure, I actually like that. But I need a type system that's sophisticated enough to let me handle them nicely; there are times when I need eithers or validations or the like. More than that, there are enough cases where I need one or the other that I need to write code that can handle any kind of context generically.
It's funny because despite the reputation Scala (my language of choice) is actually very simple at the language level. But what you can do with those simple pieces can become very complex, and the range of patterns that are possible takes a while to learn. It's not learning the language that takes ramp-up time, it's the library code.
I predict that if Go is successful it will acquire its own scalaz-equivalent; it pretty much has to, because there are patterns in the way you do things like error handling that it would be stupid to just repeat in every project. I mean, you know what else was a small simple language? Java, which is why it acquired the massive frameworks it's best known for.
(That's not the worst possibility though; that would at least make Go a useful language. But with a type system noticeably worse than Java's, I'm not sure it will be possible to build these things in Go, and a type system isn't something you can bolt-on in a library.)
If you're just an average programmer you can probably still go program enterprise software somewhere big where personal accountability is lacking.
If it wasn't for the NDAs I would have lots of war stories to tell.
I concur with his fun vs. efficiency graph. It strikes me as quite accurate. Also, I concur that it's a big win to not need nginx/Haproxy as a reverse proxy/SSL terminator. I suspect that a great deal of my server performance gain going from Clojure to Go resulted from this alone. Also concur that getting off the JVM has improved programmer fun by eliminating initial wait times.
Also the argument about initial wait times is bizarre considering you are talking about server side applications. Plus there is always Drip.
Clojure community at the time was still recommending using a reverse proxy as an SSL terminator. Are you going to say that the JVM SSL implementation is as fast as using nginx? It's also supposed to give some measure of DOS immunity.
Also the argument about initial wait times is bizarre considering you are talking about server side applications.
Yeah...Java guys were saying that back when I was working with app servers on Smalltalk VMs, which also had a tremendous advantage in startup times. (Take away the splash and herald, and VisualWorks used to start faster than Perl 5.) All of those several second wait times nickel and dime you to distraction.
Plus there is always Drip.
I did use it. About halved my wait times. The wait was still too long. Using Go is better for me.
The question isn't whether it's as fast as nginx so much as whether it's as fast as go.
Go is faster than Clojure plus nginx running my algorithms. What's more, the Go server actually got faster after turning on TLS. I suspect it retires bad connections more efficiently.
I don't mind Go. But I would hardly consider it "fun". The error handling is a chore, it's lack of libraries frustrating and you don't get the more interesting constructs of a FP language.
If it wasn't for Google sponsoring, it would have joined Limbo already.
Sure, functional language can be used in almost all the programming related projects. But are they really a good fit or not is not decided by FP advocacy, but the people who actually tackle these problems.
Go for now shines in a pretty niche market, it is extremely good fit for this niche market, and this fact is not advocated by Go fans or Go team, but by large amount of open source projects and emerging usage in quite a few serious companies/startups.
You can certainly go ahead and ask them "Why not use OCaml, F#, Haskell or Scala", or you can use FP to make a better project in this field to show people FP is indeed much better fit.
To some of us, programming language is merely a tool to solve a problem, not to show off the shining design concept. For us, Go hits a incredibly sweet point on the balance of coding efficiency and running efficiency. Note that, coding efficiency has nothing to do with "how beautiful and elegant this code snippet is", it has everything to do with "if this project is easy to read, easy to maintain and easy to expand"
Those languages are better tools for solving problems in a lot of cases, the problem is people just choose tools that are similar to ones they already know rather than the best tools available.
Go to github and see the rank of project written in Go, you will see clearly what is the niche market(not that niche I would say) I'm talking about.
The point stcredzero about manually laying out memory is fair, though much less important in writing web servers than in a game.
A lot of the slides are about why he wouldn't use Perl, why he wouldn't use Java, and the like. His whole argument is that there's no other language in the efficient / nice to program quadrant. To make that kind of argument you have to cover all the options, and at least place those languages somewhere on the diagram (or acknowledge why you aren't).
> You can certainly go ahead and ask them "Why not use OCaml, F#, Haskell or Scala", or you can use FP to make a better project in this field to show people FP is indeed much better fit.
Well, that's what I do. But Go seems to get a disproportionate amount of coverage on HN, particularly compared with what people I've met in real life are using. (at least here in London. Maybe it's much more popular in SV?)
There are quite a lot middle/small scale companies using Go in US. I can give you a long list if you want, but you can probably just search it by yourself.
I can not speak for Brad, but my impression on his comparison is that he picks up languages which are more used in the field Go is targeting at, not those which are only perfect fit in theory
Go(ne ?)