4 ms·

>But I still don't see why you would choose Go over Java (or Scala) for serious backend development. 1. Less verbose code 2. Platform Ind. + native binarie

>But I still don't see why you would choose Go over Java (or Scala) for serious backend development. 1. Less verbose code 2. Platform Ind. + native binaries, no runtime dependency 3. Built in unit testing/benching 4. Fast compile time 5. Better tooling, no Ant etc needed 6. Better core language support for multithreading/concurrency 7. A memory model that makes it easier to read the code and understand how the resulting data will be layed out in memory 8. Related to 7, better stack vs heap allocation control >Java has more libraries Many of which are of low quality / filled with code-rot, I used to play in the Java ecosystem the Go stdlib is cleaner and the Go 3rd party libraries tend to be better, more single function. >is faster This is not always the case and is changing for Go's better fast. To paint Go as non-competitive would be unfair as its in the same league as Java and it usually faster than C# Mono. >has generics (for the love of god) I used to miss this, but I find I don't anymore... I wrote proxies, databases, systems applications. >has better IDE support True. This used to pain me until I found LiteIDE and I started writing unit tests more and using the debugger less. Go's profiler is awesome though... >and has a larger hiring pool. Not really, any smart C/C++/C#/Java developer can be highly productive in Go in weeks. >In summary, the ecosystem is more mature. A double edged sword mind you, not to mention Go is maturing at faster rate then Java did. >Java's checked exceptions are less painful then Go's C-style error handling. No. C++/Java got it wrong, ignoring error paths lead or letting random low level errors bubble up are some of the horrible results of the Java way to handle exceptions. Forcing programmers to consider which operations may fail- how to handle those failures is one of the best decisions Go made. Multiple returns make this much less painful than C.

pjmlp 12y ago
> 2. Platform Ind. + native binaries, no runtime dependency Also available in Java. It is just a matter of choosing the right compiler. Java like many other languages, enjoys a standard, certification process and multiple implementations to choose from.
- voidlogic 12y ago
  GCJ is dead. Are you referring to proprietary implementations?
  - pjmlp 12y ago
    Yes, who still bothers with GCJ? I really don't understand why GCC still ships it. However there are also open source implementations like RoboVM and JikesRVM, among a few others.
bad_user 12y ago
> 1. Less verbose code Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages. > 2. Platform Ind. + native binaries, no runtime dependency In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work. On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency. It's true that it doesn't get distributed as byte-code that needs a VM, but at the very least you're still dependent on a garbage collector and that makes it unsuitable for all those things one would naturally do in C/C++. Also, Java being the standard that it is, has multiple implementations and it doesn't necessarily need a VM. The purpose of RoboVM (http://www.robovm.com/ http://www.robovm.com/) for example being to build apps for iOS in Java meant compiling Java to native and RoboVM does just that. But there are advantages to distributing apps as bytecode - Android ART (the successor to Dalvik) is doing AOT compilation to native upon installing an app on your phone and the cool thing is that you don't have to worry about what processor your app will end up running on. > 3. Built in unit testing/benching I don't see how that is an advantage. Does Go have something like YourKit Profiler? Can you easily connect to a remote application for debugging or profiling? > 4. Fast compile time One can argue that fast compile times are a direct consequence of the compiler not doing pretty much of anything you'd expect a compiler to do - like optimizations or type-safety. For example the C++ compiler is slow, but the C++ compiler can optimize the shit out of anything. Scala's compiler is slow, but it can catch a lot of errors for which you'd normally have to run expensive third-party tools. > 5. Better tooling, no Ant etc needed Nobody is using Ant anymore. Go doesn't have Maven or anything like it (i.e. Gradle, SBT, Leiningen). As a personal opinion, whenever I have to work with other platforms, feels like going back to the nineties. > 6. Better core language support for multithreading/concurrency This is a common misconception, when the opposite is factually true. On the JVM you'll find support for the Erlang-style actor model, Hoare's CSP, Futures/Promises, reactive streams (Rx), STM, parallel collections and the best concurrent data-structures that open-source can provide. See Akka, Quasar, Scala's and Clojure's standard libraries, LMAX Disruptor, etc... > 8. Related to 7, better stack vs heap allocation control This has always been a problem for the JVM, however stack-allocated values are coming in the next version. On the other hand the control on memory layout in Go is still weak and the JVM does have much better garbage collectors.
- 12y ago

pjmlp 12y ago

> 2. Platform Ind. + native binaries, no runtime dependency Also available in Java. It is just a matter of choosing the right compiler. Java like many other languages, enjoys a standard, certification process and multiple implementations to choose from.

voidlogic 12y ago
GCJ is dead. Are you referring to proprietary implementations?
- pjmlp 12y ago
  Yes, who still bothers with GCJ? I really don't understand why GCC still ships it. However there are also open source implementations like RoboVM and JikesRVM, among a few others.

bad_user 12y ago

> 1. Less verbose code Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages. > 2. Platform Ind. + native binaries, no runtime dependency In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work. On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency. It's true that it doesn't get distributed as byte-code that needs a VM, but at the very least you're still dependent on a garbage collector and that makes it unsuitable for all those things one would naturally do in C/C++. Also, Java being the standard that it is, has multiple implementations and it doesn't necessarily need a VM. The purpose of RoboVM (http://www.robovm.com/ http://www.robovm.com/) for example being to build apps for iOS in Java meant compiling Java to native and RoboVM does just that. But there are advantages to distributing apps as bytecode - Android ART (the successor to Dalvik) is doing AOT compilation to native upon installing an app on your phone and the cool thing is that you don't have to worry about what processor your app will end up running on. > 3. Built in unit testing/benching I don't see how that is an advantage. Does Go have something like YourKit Profiler? Can you easily connect to a remote application for debugging or profiling? > 4. Fast compile time One can argue that fast compile times are a direct consequence of the compiler not doing pretty much of anything you'd expect a compiler to do - like optimizations or type-safety. For example the C++ compiler is slow, but the C++ compiler can optimize the shit out of anything. Scala's compiler is slow, but it can catch a lot of errors for which you'd normally have to run expensive third-party tools. > 5. Better tooling, no Ant etc needed Nobody is using Ant anymore. Go doesn't have Maven or anything like it (i.e. Gradle, SBT, Leiningen). As a personal opinion, whenever I have to work with other platforms, feels like going back to the nineties. > 6. Better core language support for multithreading/concurrency This is a common misconception, when the opposite is factually true. On the JVM you'll find support for the Erlang-style actor model, Hoare's CSP, Futures/Promises, reactive streams (Rx), STM, parallel collections and the best concurrent data-structures that open-source can provide. See Akka, Quasar, Scala's and Clojure's standard libraries, LMAX Disruptor, etc... > 8. Related to 7, better stack vs heap allocation control This has always been a problem for the JVM, however stack-allocated values are coming in the next version. On the other hand the control on memory layout in Go is still weak and the JVM does have much better garbage collectors.

12y ago