For the life of me I can't understand why anyone would give up the power (in terms of profiling, monitoring and ecosystem, and somewhat better performance, too) of the JVM, for a language marginally more convenient than Java, and arguably less expressive than other JVM languages. The only thing I could think of is a smaller RAM footprint, if you care about that sort of thing.
Whenever Go is compared to Java, the arguments in its favor seem kind of fuzzy. After all, one of the motivations behind Go was a C-like language with far better compilation time than C++. And Java already fits the bill. So, yeah, Go is leaner and more modern -- but certainly not by an order of magnitude, like other JVM languages. Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling? Because Java IDEs really get the job done), frameworks etc. But those things are simply the result of years of changing fashions. Newer Java "frameworks" are just as lean-and-mean as Go.
There are so many new and exciting languages around, but Go seems to carry the least "oomph" of the lot. It's basically Java. A little nicer; a little slower; a lot less powerful.
Go programs don't just use less memory, the language makes it possible to control memory allocations.
With the JVM-based languages I'm familiar with, it is difficult to control the memory allocation characteristics of you program, and typically the further the language deviates from the JVM's model (eg, Clojure and Scala) the more garbage must be generated (usually in doing= things like runtime type reflection).
All these allocations put pressure on the garbage collector and, fortunately, the JVM provides a few sophisticated garbage collectors. But even so, I am aware of some high profile companies whose JVM-based servers spend upwards of 80% of their CPU time in the garbage collector. It's just crazy.
On the other hand, the Go language and - critically - its libraries were designed to give the programmer control over the allocation patterns of the program. This creates less work for the GC, and leads to leaner services with predictable performance characteristics.
Go has other advantages over the JVM as a platform, but this is the critical one IMO.
Go's memory model has similarities to C. For instance you can use the heap or the stack. Go figures out which one an allocation should live in by doing escape analysis. If it never leaves the function it goes on the stack. If it does it goes on the heap. GC ensures anything on the heap gets cleaned up. It's not an API.
Both the JVM and the CLR do this. This is not a Go technology.
In fact, in certain cases the JVM can detect type information and remove the allocation entirely by hoisting integer fields and the like into registers.
The programmer explicitly specifies when to use pointers. Whenever pointers are not used, the object is stored in-place (for example, on the stack, in the array or slice, or in the struct).
For instance, in Go everything is passed by value. If you want to pass a reference, you must pass a reference type (like a pointer). This means that you can pass around structs without having to put them on the heap. In JVM-land, nearly everything is passed by reference, and the data must go on the heap.
Relatedly, in Go if you allocate an array of n values of type T, the size of that array in memory is n * sizeof(T), and the items are laid out sequentially in memory. There are no other bookkeeping data structures and no indirection.
JGit struggles with not having an efficient way to represent a SHA-1.
C can just say "unsigned char[20]" and have it inline into the
container's memory allocation. A byte[20] in Java will cost an
*additional* 16 bytes of memory, and be slower to access because
the bytes themselves are in a different area of memory from the
container object. We try to work around it by converting from a
byte[20] to 5 ints, but that costs us machine instructions.
In Go, you would just write [20]byte. If you wanted a struct with a field of [20]byte you can do so, and all it costs is the 20 bytes.
The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements. And if high-profile companies have servers that spend 80% of the time in GC -- well, they must have really neglected their code. That's a result of poor software maintenance, and I doubt any language could help them.
> The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
The 32-bit GC issue is an unfortunate shortcoming of the GC implementation, which will be resolved in Go 1.1 early this year. The issue was merely an artifact of dead simple conservative GC implementation.
OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC.
Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
No... It's because Java totally sucks when objects go from Eden to Survivor and then needs to be GC'ed or from Eden to Survivor to Tenured and then needs to be GC'ed.
That's the very reason why some trading companies who still insist on using Java do use methods where as few objects as possible are ever created and went on to invent things like the LMAX disruptor "pattern" (more like an anti-pattern, where the goal is to be as close to the metal as possible, by allocating gigantic primitive arrays... Quite the contrary of your beloved GC dogma, where you think that creating objects as no impact and that slow GCs are necessarily the programmer's fault).
I realize from your various post that you did really drink the Java cool-aid and that no matter what's going to be said you'll always come touting Java as the best language out there.
I know Java well enough to criticize it.
I also have the impression that Go is used inside Google on some impressive tasks so I wouldn't be to quick to dismiss it.
I'm not dismissing Go, and I'm not praising Java, and I've even admitted on this very thread that Go is better than Java, so there's really no need in trying to convince me of anything. All I'm saying is that Go isn't good enough -- if I really want fast development and expressivity, there are languages more expressive than Go (more so than Go is to Java), and if I really need top-notch performance, then Java is OK and comes with some absolutely useful advantages that Go doesn't offer. I see excellent use cases for Python, for Ruby, for Clojure, for Java and for C/C++. I just don't see compelling use cases for Go. I'm not dismissing it. It's really nice. I just think it's underwhelming.
And, BTW, if you think Go has some magic GC secrets that will make all (or even some) of the JVM GC problems go away -- I believe you're mistaken.
I'm not sure what "impressive tasks" you mean, but I don't think that's true. I heard of people using Go, true, but the perf-heavy backends are all in C++.
For me, Go aside, I just don't want to deal with the JVM. Sure, VMs are great -- erlang has a nice one, iterations of the JVM are still nicer than they were circa 1998, etc. But, I've dealt with services web services in C/C++, PHP, Python, Go, Java, etc. 5-10 years ago, Java and it's assorted frameworks had it's place, but the intersection of Jetty, JBoss/Tomcat, Glassfish, and plain old Java apps muddied the waters about managing Java apps. If you use a framework, you will need to tweak memory settings to make sure things behave well.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps.
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.
Oh, I don't doubt many things can be done much better in other languages than Java, only why stop at Go? Clojure pretty much hits every single one of your requirements, it's more modern and expressive than Go, gets concurrency better, and it's about as slower than Go as Go is slower than Java -- and getting faster. Also, you don't have to give up the monitoring and instrumentation the JVM gives you, as well as the vast Java ecosystem.
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.
> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages.
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 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.*
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.
My point is that Go gives you the option of immutability. Not immutability or something in between. I frequently send messages using non reference types which incurs a copy but means that I don't have to worry about who owns this code. It's easy since Go has pointer and non pointer types. Java has reference types and you have to design the object to be immutable by hiding fields behind methods and using annotations. Clojure goes to the other extreme. Go sits in the middle. Which is relaxing.
> 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.
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.
The main (and close to only) user of Erlang was Ericsson, and here is what the Wikipedia has to say about it [1]:
"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"
"The ban caused Armstrong and others to leave Ericsson.[6] The implementation was open sourced at the end of the year (1998).[3] The ban at Ericsson was eventually lifted, and Armstrong was re-hired by Ericsson in 2004.[6]"
It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.
Alright, I'm sure some people find Go's particular combination of features appealing. For me, a language has got to be so unbelievably awesome to consider leaving the JVM, and seeing that some of the most awesome languages target the JVM, that language better do something that would truly impress a veteran like me. There's only one non-JVM language that I'll use for some very specific applications, that I think is all that: Erlang.
I'm not sure if it's just a mindset thing or the stuff I've used it for, but I've never felt the immutability got in the way, it's one of the things I miss most when using other language.
That stance seems to require a low weight on the cost of conceptual and tool-chain overhead. I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages.
My claim is that Go's advantages are far, far too small to outweigh not running on the JVM. (also, I think Clojure > Go -- no need for Java in the equation -- but that's not my main point)
You see the JVM as an asset. Many consider it a liability.
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".
I realize I've started a pretty ridiculous language war; that was not my intent. But I still cannot understand why anyone would want to use a language that is mostly meant for non-constrained environments, does not provide some major productivity advantages over JVM languages while being slower than JVM languages. I would totally consider using use Go if it targeted the JVM.
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?
>I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages.
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...
That is a bit disingenuous. There is an SQL interface driver in the stdlib here[1]. There are several[2] implementations available which build apon it.
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.
It depends what you want to build I guess. Go has a much smaller surface or things to learn if you know POSIX already. It's fast startup times makes it also a good contender for command-line tools.
+1 for alternative languages like Clojure and Scala.
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.
I have a hard time believing anything can beat or even match the garbage collection performance of the JVM. Not that there is something special about the JVM, just that there have been _so_ many smart people working on the problem for so long now. And for good performance doing server tasks (ie, not computational tasks) exceptional GC is a must. Can a GO program handle a workload that creates tens/hundreds of thousands of objects per second for weeks or months without leaking memory? That's why I use Java. If I don't need that kind of performance, I use Ruby. I'm still just not sure where GO would fit into my workflow, though it looks really promising. Especially the concurrency model that you currently have to awkwardly bolt on to Java with something like Akka or JetLang.
I have to raise the eyebrow to that. I have had more GC problems with Java than any other language. Geniuses fuck up too, and when they do it's pronounced "OutOfMemoryError: PermGen space."
Remember Go doesn't have objects, it only has structs which are most likely (and should be, but I haven't verified) much lighter weight than the objects you might be used to in Java.
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.
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.
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.
It may have slowed down the occasional attacker who had no access to a HP-PA RISC cross compiler for his platform. But in todays world there is no reason.
> 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.
They do? Why not build as part of a CI run? Or via cross compile?
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).
I don't know that I was defending Go so much as describing why someone would want to use it. It's fine for someone to say they really like the jvm. I like it to. Clojure and Scala are fun languages. The JVM has a lot of really cool technology behind it.
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 :-)
From my experience if you're running Linux on your local machine and Linux on your server then you can distribute a Go binary to your server and it will run fine. Even if they are different distros.
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.
> 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.
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.
Go is far more innovative than Dart. Dart is, roughly, "We want to have a Java-clone in the browser". Go actually makes an effort at cleaning up C while adding a structural OO model and building in concurrency.
+1. For me a killer feature is that I easily create executables for lin/mac/win on my machine and don't have any dependencies at all (JVM for example).
Oh, absolutely! Small executables would be a good fit for Go (provided you don't need a GUI, since AFAIK Go doesn't have a UI toolkit). Only, in that case, isn't a whole new language ecosystem a bit of an overkill to avoid some of the inconveniences you'll have using C/C++?
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.
> Only, in that case, isn't a whole new language ecosystem a bit of an overkill to avoid some of the inconveniences you'll have using C/C++?
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?)
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.
The time it takes to 'go run' a go program is about the same as the time it takes to run a python program. If you are able to write Go code faster than Python code (that is the important "if". I can, some cannot. It's a personal thing.), then Go will be faster than python.
I program to solve problems. I usually solve the problems in my head or on paper before doing any coding.There is usually a step afterwards during which I translate this solution into a given programming language. This step in Java is much harder than I would like.
The reason for this is that I feel I spend too much time doing taxonomy and managing complex relationships between different classes when programming in Java. This occurs in every programming language but I find Java is by far the most restrictive in this regard. I find go much more flexible, as much as python, and scheme even more so.
The end result is that I am more productive when programming in these languages and most importantly I feel that I am not doing as much busywork. This in turns makes programming more fun and rewarding.
For my day job I program in Java doing enterprise stuff, at home I enjoy dabbling in Go, D, Haskell and Clojure for personal projects.
Mainly because in my opinion it's a huge PITA to do command line stuff in Java and distributing class files/jars to other systems is a real pain especially when other instances have varying versions of the JVM running.
With Go I can just compile something on my machine and send the executable to another (running the same/similar OS) and I can be pretty sure it runs fine.
Java is great for large, long running applications like web apps and servers, but I don't think you can be as productive when knocking out one-off scripts/rough and ready prototypes.
Does Java do coroutines/green threads? No. At a deep architectural level, the segmented stack required to do green threads is what sets Go apart. And if it wasn't for this, Go could have just been another JVM language probably. I guess they felt this was important enough to justify building their own runtime.
>Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling?
You should really write a GO code to understand what the author means. Writing GO code has no frills. And I have seen nothing cooler than: http://gofmt.com/.
Even if that's the case, Go just brings too little to the table. And if you think gofmt is cool, take a look at Project Jackpot [1], or its use in the NetBeans IDE [2].
Exactly. What you can reasonably expect from code in the wild makes a world of difference.
When I am working on personal projects that I have in C, I use `-Wall -Wextra -Werror -pedantic` (along with the strictest `-std=` that the particular project will allow), and it makes my development experience an order of magnitude more pleasant. However when I am working on C code that is primarily somebody else's, I rarely get the pleasure of expecting code neat enough to allow me to reasonably use those flags. This makes working in C a much less pleasant experience overall.
That Go goes further and is strict about style too is just brilliant.
That is utterly misleading. Java IDEs really get the Java job done. And, sadly, Java is a language of such an incredible verboseness and containing so many idiosynchrasies that it takes a lot of code to do things. And IDEs do certainly excel at this.
But you have to realize that a lot of the IDEs' functionalities when it comes to Java are really just work around Java's failures.
So, yes, I can fire IDEA and it shall allow me "easily" work around a 100 000 LOC codebase.
But if I can write the same program in 30 000 LOC of Go or 10 000 LOC of a Lisp dialect I think that there's still a jury out there trying to determine if Java IDEs are really that great.
So I don't doubt that IDEA / Eclipse is helping you in your Java + ORM + XML hell but there are other ways to develop applications. Mind you: it's a huge world out there and despite your beloved IDEs being so great there are still people not programming in Java.
Also the IDEs tend to suck quite a lot when we're talking about "non-Java JVM languages".
Btw I'm using IntelliJ since so long I don't remember if it was version 3 or 4 and I just bought version 12.
Whenever Go is compared to Java, the arguments in its favor seem kind of fuzzy. After all, one of the motivations behind Go was a C-like language with far better compilation time than C++. And Java already fits the bill. So, yeah, Go is leaner and more modern -- but certainly not by an order of magnitude, like other JVM languages. Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling? Because Java IDEs really get the job done), frameworks etc. But those things are simply the result of years of changing fashions. Newer Java "frameworks" are just as lean-and-mean as Go.
There are so many new and exciting languages around, but Go seems to carry the least "oomph" of the lot. It's basically Java. A little nicer; a little slower; a lot less powerful.