I'm not saying Go isn't better than Java -- I'm sure it is. My main point is this: if I want to relax, there are more relaxing languages than Go; if I really need JVM-like performance, I'd rather go with Java and not relax as much; and if I need both -- there's Clojure, Scala, Kotlin (soon).
This leaves one point: RAM footprint, which I'll concede. But stacking that against the JVM's monitoring and large ecosystem, I'll take the JVM any day. So, Go is nice. Really nice. But not nearly nice enough to even consider abandoning the JVM (unless you're memory-constrained, in which case the JVM was never an option).
Also:
> Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages.
> Go comes with all the tools you need to programmatically understand Go code... Java doesn't have this.
It does since Java 6: http://docs.oracle.com/javase/6/docs/jdk/api/javac/tree/inde...
This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.
This to me makes Clojure less relaxing. In fact Clojure is not relaxing it's challenging which can be enjoyable but I wouldn't say it's what I want to do everyday for my job. Go I could easily see myself doing it everyday.
As I said Go has a lot of good qualities all in one package. Clojure has some of those qualities but not all of them.
The pointer to the compiler api is interesting. I hadn't seen it before. I don't see any way to serialize a source tree in there but that might be just for lack of searching. I wonder why things like gofmt and company don't exist in the java toolchain already. I mean outside of third party IDE's.
I don't want to join into a language war, but I wanted to point out two things with this statement:
1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.
2- Rich Hickey worked on massive telephone systems and created Clojure, at least in (large) part, out of frustration of dealing with mutation.
So there's a long line of research backed by "real world" experience showing mutation not holding up well for concurrency. Erlang is another example.
Regardless, I do agree that immutability may not be what it is hyped up to be, especially if you are looking for the mythical silver bullet, but it most certainly isn't over-hyped if you compare it to mutation, and the ideas are still quite young and being tested. Give it 20 years and I suspect there will be another paradigm shift at some point.
Maybe, but concurrency based on mutability seems to have won this war in the real world these past thirty years.
Immutable systems might be easier to design in theory but we haven't seen this proven in the battle field yet, and the fact that most of the concurrent code today runs on mutable structures shows that it can be done.
"Shortly thereafter, Erlang was banned within Ericsson Radio Systems for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson"
Not exactly a strong endorsement for Erlang.
[1] http://en.wikipedia.org/wiki/Erlang_(programming_language)
It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.
Go makes it easy to get right. It doesn't make you get it right.
(Java + Clojure) > Go && (Java + Scala) > Go
Edit: Fix spelling of "Clojure".
And programmers in the New Jersey school (see Worse is Better) are unlikely to ever stomach Clojure.
These differences are more in the realm of deep allegiances and HN comments will probably be limited to revealing allegiances--they have little chance to sway the reader one way or the other.
Might as well say, "MIT type with love for the JVM? Choose Clojure. New Jersey type with love for native code? Choose Go".
You say some people consider the JVM a liability. Can you please explain why? As far as I can see, the JVM has two disadvantages: a high RAM footprint and a slow startup time. But on server-class hardware (and I believe that's probably the main environment for Go), it's hard to beat the JVM's performance, and nothing even comes close in providing similar monitoring. So -- and I'm asking this completely seriously -- why would anyone consider the JVM a liability in such an environment?
Doesn't matter, since you'll find huge large holes in libraries, tooling, ecosystem and maturity in Go which can be easily filled in Java+Scala/Clojure, and which nullify any "smaller spec" advantage.
For example there is not one mature and complete web framework in Go. Several for all of Java/Scala/Clojure. There is no good RBDMS support in Go. As good as it gets for the JVM languages. Etc...
There are several[3] (scroll down to the relevant section) web frameworks too.
I personally tend to prefer using the gorilla toolkit[4], in combination with the stdlib http and templating stuff. It should be noted that my current usages for Go include an API service, command line tools, and a proxy. Certainly not much html generation going on there by any means.
[1]: http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/
I recently (more or less) shut down my consulting business to do other things and since I no longer need (so much) to fit in with customer's tool chains, I decided on Clojure as a great general purpose language that is also a lot of fun to develop with. I could make the same comment about Scala or JRuby if I had chosen either of those fine languages.
Really, the JVM ecosystem rocks.
As far as the creating tens/hundreds of thousands of structs per second for weeks or months without leaking memory, I'll get back to you on that once my code has been active that long ;)
I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries...
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.
Go error handling is not to be taken lightly just because you can ignore error codes or just print the error and be done with it. I seem to recall that the core developers of Go demanding that Go users try harder to handle errors. Something the compiler doesn't really "enforce".
I prefer Dart to Go because Dart starts from a higher level of abstraction already. Also Dart has been the result of two years of development even if many of the Dart developers also had plenty of experience with developing past languages and tools.
OOP already gives us a lot of bondage and discipline. No need for more incentive by the compiler. Sometimes a couple of extra tools can help our hands without it being forced by the compiler with every run. Say a tool that helps to tell us which methods or variables aren't being used. Go forces us to deal with that on every compiler run. (Even if it can be disabled, but the Go developers prefer to avoid proliferation of config options.)
It's good to have Go and Dart around. So it's not just legacy (Java) and Microsoft (C#) dictating the standards.
This is what systems administrators with grey beards thought in the 1990s. A moment's thought about what an attacker who can run a compiler can do instead of running a compiler should be enough to inform you about how silly the idea is in practice.
Joy to ACLs, custom Solaris builds and proper kit (ultra enterprise units the size of a full 42u rack).
I miss those days.
> Funny thing about Go is that as a compiled language, folks often need
> to send the source-code to the deployment servers to compile on them too.
It is generally much easier to deploy a versioned statically compiled binary, compared to rolling out code to production in some languages (ruby, python, etc).
But when someone says they don't understand why someone else would want to do things differently I just naturally want to help them understand :-)
If you have differing operating systems then you have problems, but that's be a build process problem rather than a problem with Go.
The fact that Go relies on return codes instead of exceptions to express errors is what will fundamentally limit the language's adoption, in my opinion.
Anyone who was writing code in the 80's and 90's remembers how fragile and buggy software written this way is (Windows' HRESULT, anyone?). Exceptions have considerably increased the robustness and reliability of millions of lines of code, the software community is not going back to error codes.
Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.
Doesn't seem like a situation precipitated by something in Go. I've found cross-compilation to be very easy and effective. Having your build setup on the deployment servers would negate the advantage of the dependency free single-binary deployment.
Not in my experience. Nearly everyone I know who deploys Go code does it by shipping a binary. One of the benefits of static linking.
Sorry, I've yet to be shown a large enough class of problems where Go would give a significant enough an advantage to abandon rich and well-established ecosystems.
Look, there's no doubt Go is nice, and, as such, some people would use it for some tasks, just because it's there. But if I run a company building large software, why would I switch to an entirely new ecosystem that's incompatible with just about everything unless there is something spectacular that Go can do that no other solution can? Or, at the very least, something extremely hard that Go does very easily. Erlang, which is also incompatible with just about everything (though it might even be more compatible with C than Go is) does some spectacular things. If Go's killer feature is small console programs that don't require dependencies, then, well, it will see very little serious adoption.
Sure. I've started from scratch and Go seemed to me like the perfect match (not that there aren't any other choices, but it came right into my front door and I said: why not?)
I don't understand this: You claim you've used Haskell? Haskell beats Go's concurrency out of the water.
Not to mention conciseness...
While go makes a lot of correctness bugs really easy to accidentally make, Haskell does make a certain class of leak easier to maker. I'd personally take a correct program that leaks in some scenario over an incorrect one that does the wrong thing.
> C++ doesn't have this [Tools for writing IDEs quickly]
Well indeed it does, libclang does exactly that, and quite well. As a result, you have plugins for Vim, Sublime Text and others providing autocompletion and in editor compiltation and error reporting.
In all seriousness, C++ is extremely difficult for automated tools to work with, including C++ compilers.
use :!go run %
It will compile and run the script so fast you will swear it was an interpreted language except it runs way faster than an interpreted language.
So I'll try to impart some understanding of why I would switch to Go from Java or C++.
First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So when compared to java and C++ in those dimensions it holds up just fine but that might not be enough to sway someone over to the Go camp.
It's about what else Go has:
* Go is a batteries included language. The stdlib has almost everything you need to get started much like python does.
* Go is fast for development. I mean really fast. I mean like using Lisp in a REPL fast (almost). I really can't express how fast it's development speed is adequately just trust me its really really fast. This is not just about how fast it compiles although that's part of it. (I've literally been able to write, compile, and run a go "script" faster than an equivalent python script.)
* Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
* Go is concise. There is no wasted typing. It's easy to read and it's easy to write. Every feature of the language is orthoganal. And it tells you quickly when you've done it wrong.
* Go does OO right. Code reuse through composition not inheritance. Polymorphism through interfaces not inheritance. I never have to worry about it with Go. C++ or java? yeah I've got some inheritance related war stories there.
All of these things exist in other languages but Go is the only language where they all exist together. This is reason enough to switch to Go but there's more.
Go's future is bright. I don't say this because it has celebrity tech people behind it. I say this because the foundation they are laying demonstrates the core team knows what they are doing. Here's some examples.
* Go comes with all the tools you need to programmatically understand Go code. Parser, Type checking, Static analysis is all available via the stdlib. As a result GoCode which adds IDE functionality to the EDITOR of your choice came on the scene very quickly. Java doesn't have this. C++ doesn't have this. Go made it possible to create an IDE as a service with minimal effort. Besides Gocode you also have gofmt. Never worry about code formatting again. gofmt will reformat it for you and it will never break your code. It's 100% safe. I am aware of no other language excepting lisp with this functionality.
Lastly I want to address your "a lot less powerful" comment. I think it's false. In now way is Go less powerful than Java. It's fast enough to be in the same league as java. It has a lower memory footprint than java. It compiles faster than java. And the language itself is if anything more powerful and expressive than java. It has closures, It has interfaces that are just as typesafe and yet easier to use than java.
In fact I'll sum it up in one word: Go is relaxing.