I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "teaching" language, nor would anyone call it "mature" at this point, but it does fill a niche and fills it pretty well.
> And compared to Java, the fact that Go compiles to a native binary is a huge benefit.
I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in the Java community, which suggests it's not a problem for other people.
When i see someone suggesting that Go has a significant advantage over Java in terms of deployment, i assume that they don't actually have experience of deploying Java apps, they're just regurgitating the standard Go talking points.
Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then...
The ability to tune GC and availability of monitoring solutions are things I consider as big pluses for deploying on the JVM.
I would love to have a GC which tunes itself to accommodate the workload. On the JVM, G1 is a step in the right direction. How does Go's GC work in this regard - does it auto-tune itself?
Also, how are Go programs monitored in production? Are there tools like AppDynamics, NewRelic, JConsole or similar APM/telemetry solutions available to monitor Go applications?
Setting memory parameters and tweaking them would be similar to deciding what compilation flags to use when compiling your program. I also much prefer profiling over JMX than re-compiling the application with the profile flag activated and re-deploying.
As someone else who has been deploying Java applications for years, I'm not saying it's hard, but you have to take care when upgrading the JRE on a server, because with most setups (such as the default Sun JDK RHEL packages) it's a shared resource. You can go ahead and bundle a JRE with your jars. With Go this specific problem doesn't exist.
Fair point. I've always used the approach of dedicating a machine to one particular application (using virtual machines once those became available), so the impact of upgrading the a global JRE is limited.
I did once work on a system where we installed two JREs in parallel, and selected which one to use for the app based on an entry in the manifest file. That let us upgrade Java versions under application control, without requiring sysadmin intervention. Took a couple of lines of shell script.
I think it makes a lot of sense. I can download the Windows version of an app and double click on it and it runs. As opposed to I double click on it and it's all "oh you don't have a JRE" or "you have the wrong JRE, mysterious error" or "you need to install this JRE", or it installs a JRE for me, but another app requires a different JRE.
I'm surprised you didn't mention Java compiles to byte code which is then JITed for the processor on which you're currently executing - I don't need to recompile for every platform and I still get native performance. This has been Java's primary strength since the introduction of JIT. Even better, I don't have to use Java to create the byte code. My favorite happens to be Clojure but you have several language options to suit your needs.
You never had any classloader issues with things like logging libraries and their configs or XML parsers? No versioning problems with dependencies of dependencies getting confused at runtime? No inconsistent clasloader behaviour with differnt Java EE containers?
I'm not saying that library versioning and dependencies are not a problem with Go. Quite the contrary. But it's a compile time issue. There are far fewer surprises at runtime and that makes deployment a lot easier.
I'm perfectly capable, I just don't see the reason. Why should I install a JRE to run your program? The JRE has nothing to do with your program; it's incidental complexity. Go gives us a way to eliminate that incidental complexity and so is a step forward.
Oh, look, there's already an antique jre installed on my os, not compatible with the particular jre needed by this application, which I first need to uninstall. And then hope that it doesn't break anything else in the process, because I haven't been following the minutae of java development environments for the last n+1 years...
I think it falls solidly in the "easy if you know it, and a wasted q hours if you don't" category.
I am not sure your definition of upgrade, but it is definitely a downgrade in terms of features even comparing it to Java. It has lean environment that makes it more attractive to systems programming and the CSP (channels, go routines etc.) make it great for concurrency. The trouble starts when you are shifting from systems projects to business logic projects. This is where Java runs circles around Go (or for that matter several other languages/environments). I wish Go had similar type system like OCaml.
If I would like to teach something smart to software engineers I use OCaml, if I want to teach how simple things can achieve a lot I use Go. (They gonna end up programming in Java or Python anyways :)) )
I get the feeling that the people who deride Java either have little experience with the language and ecosystem or had were the poor folks that had to maintain a legacy <1.4 Java app for years and have no experience with modern Java.
It has its quirks (what languages doesn't?) but it is a fantastic general purpose programming language.
In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...
Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones.
Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes sense and you have seamless interop between multiple languages e.g. Ruby, Python, Scala, Clojure.
Anyone who thinks Go is an upgrade to Java is woefully misinformed.
"Let's also not forget that Java is significantly faster"
Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.
Note that the benchmarks game is going to count compile time against Java, but not against Go, since Go is AOT compiled and Java is JIT'd. If your app is a long-running server, you should take the benchmarks game numbers with a grain of salt.
The notable exception (not included in summary measurements) is the few tenths of a second run-time for meteor-contest. Of that few tenths of a second: JVM startup takes 95%, JIT and OSR another 4.9%.
Whatever kind-of app you have, you should take general statements about program performance with a grain of salt, there's even a page for that --
There are cases where the Go compiler generates horrors, and the only workaround is to write your code in asm.
Here's one example:
// imagine a for-loop around this
s := foo[i:i+4]
s[3], s[2], s[1], s[0] = s[0], s[1], s[2], s[3]
The reasonable assumption is that the second line generates either zero, one, or four bounds checks on s. However, the Go compiler likes to be sure, and turns it into 8 bounds checks.
I agree it's not a typical for a server to spend the majority of it's time swapping bytes. In the rare case that happens, you're going to hate the compiler for not being smarter.
> It's an upgrade in terms of compile times, deployment simplicity, conciseness,
> concurrency, etc. Some people care about such things.
I remember the days of going for coffee while the compiler chugged away but I wonder what compiles people do on a regular basis that take such time? I just rebuilt SBCL here on a mid-2012 MBP and it took less than 6 wallclock minutes in the background including download and whatever else I was doing:
real 5m12.752s
user 4m33.393s
sys 0m27.579s
I personally use D when possible, but waiting on compiles is usually secondary to the amount of time I spend thinking or exploring.
Depends the definition of IDE. My IDE is VIM. Why is it an IDE? Because it understand the text I am editing. An editor does not understand it. Anything, that supports programming on the top of an editor an IDE feature in my view. If you definition of IDE is IntelliJ than it is a different problem. I cannot edit Java without it anymore, Java is just too verbose and too many things can go wrong, I need immediate feedback from my IDE to tell me that I am doing it wrong also collapsing too verbose parts is a great thing. I don't use too much of IDE features but anything that I incorporated to my workflow over the years (very little, I keep it simple) is damn useful and I am pretty sure I would be slower without it.
Languages with small clean syntax do not require that much IDE usage, at least this is my experience. I never thought my Erlang workflow could be improved with something like IntelliJ. I guess having a REPL helps a lot.
Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."
Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).
Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up.
I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I have better things to do than install editor plugins.
Yes, but it had the One True Format, which is the only way it can possibly work. I've used a formatter at other jobs in other languages, and you end up having your formatter fighting with everyone else's, unless they're configured exactly the same, which no one can ever agree on.
In some ways, this is correct. Go is much more simple and consistent than Ruby or Java, has a better deployment story, and better tooling in some ways.
As a language, it's much less enjoyable to write. Yes, the concurrency primitives are much better, and that's a good programming tool. But to a developer coming from Ruby, code is often needlessly repetitive and obtuse to write. It ends up being overly verbose, full of copypasta, and much less expressive.
It's got it's niche – I've found it useful for writing small command-line utilities, and it's been surprisingly helpful at putting together a good deploy story for some work I've done on the Raspberry Pi (with the benefit of being well-structured and reasonably performant).
But I wouldn't like to use if full-time – mostly because it's just so weirdly irritating to write.
"code is often needlessly repetitive and obtuse to write."
I think it helps to remember that Go's use case is a lot of teams interacting to produce fairly large code bases, i.e., at Google. I'm getting into it for my job because it has the same use case, and I find it hits a nice sweet spot in what you can do, vs. what you can't do, and I happen to be in a position in which I am routinely hit hard by other people's "clever" code. I don't do my personal coding in it, though.
Part of the problem with the "clever" code is that it often uses the clever features, but, wrong. Like, all the pain of seeing someone do something "clever"... and you'll note how I keep scare-quoting that... and none of the benefits. If the clever code was actually more concise and performant than my generally-non-clever replacements, I wouldn't mind so much, but it's amazing how often I rip out a "fluent" API or something and replace it with something simpler, faster, and still results in several hundred negative lines on the commits.
I've developed a theory that it isn't even because the developers are "dumb" or something, especially since in many cases they manifestly are not. I think it's that once you pass a certain size of organization, but are still sharing some code bases, you encounter an increasing number of instances where a developer has to fix something in the shared code, parachutes in to make the minimum possibly change that might work with the minimal cognitive effort, and gets out and back to their own code as quickly as possible. The net effect in such situations is that even if your code is being written by nothing but senior devs with decades of experience, from the point of view of the code being developed on it might as well be being bashed on by a series of above-average gorillas bashing away on keyboards.
Languages that tend to point you at a single right answer, and confine the very busy, very distracted gorillas from beating on the code too hard, and make it obvious when that's happening, can be advantageous in those cases.
> And compared to Java, the fact that Go compiles to a native binary is a huge benefit.
Java has multiple native code compilers, how is it a benefit when Java can do the exact same thing? (FWIW I learned recently that C# also has at least one native code compiler).
http://blog.disqus.com/post/51155103801/trying-out-this-go-t...