3 ms·

> 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. Platf

> 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.

voidlogic 12y ago
>Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages. There is a trade-off being verbosity and maintainability, IMGO Go hits that. >In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work. LOL. Said no person who has actually distributed a multiplatofrm Java application ever- I should know. Both Java and Go are "write once, test everywhere", but in my XP Go has been smoother. >On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency. The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it. >Does Go have something like YourKit Profiler? Can you easily connect to a remote application for debugging or profiling? Yes. It comes baked into the stdlib, its "http/pprof" >Go doesn't have Maven or anything like it Biggest plus ever, goes native simple tooling doesn't need an external life support system. >This is a common misconception, when the opposite is factually true. You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries. >On the other hand the control on memory layout in Go is still weak IMHO This is not the case, if you think it is, explain.
- bad_user 12y ago
  > There is a trade-off being verbosity and maintainability, IMGO Go hits that. This is where we'll always disagree, because if you like Go, it's natural for you to come up with this argument, however the line you're drawing is completely arbitrary. I have yet to hear an argument about what makes Go strike a fine balance between verbosity and maintainability, when my feelings are the opposite - I find Go code to not be very maintainable in comparison with other static languages, because Go is not very statically type-safe. > LOL. Said no person who has actually distributed a multiplatofrm Java application ever Yet it happens all the time and a LOL is not an argument that disproves that. From my own experience, I have built stuff on top of Java / the JVM on OS X / Linux and deployed on Linux, Windows and OS X, without encountering any issues, ever, without worrying that Java's NIO will work or not, without worrying on whether the memory model will suddenly be different, without worrying on whether my app will leak on 32 bits platforms ;-) Android is the only ugly duckling, but that's only because Android doesn't have a JVM on it. It still works out well though. But if you have examples, I'd love to hear them out. > The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it. Now that's an arbitrary distinction, isn't it? What stops one from bundling the VM in the same deployed binary? If you want this distinction, the only valid argument is one of size, but then again for the server-side (where most of the Go stuff is used) that's completely meaningless. > Yes. It comes baked into the stdlib, its "http/pprof" Are you seriously comparing something like YourKit's Profiler and Java's remote attach and debugging capabilities to http/pprof? IMHO, that's not a comparison you can make. > Biggest plus ever, goes native simple tooling doesn't need an external life support system. There are many issues wrong with this line of thinking - the simple tooling you're talking about doesn't do what I and many others want it to do. Also if you look throughout history, all the languages that came with batteries included have suffered once the people finally reached the conclusion that the included batteries have been shitty. Which is what happens when you don't let evolution pick a winner with the community acting as the fitness function. But we'll talk in about 5 years. > You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries. But that's the point mate, the JVM is capable enough to build anything you want on top of it as libraries, there's no point for something to be hard-coded in the language. Which is a good thing, because when speaking of concurrency and parallelism, there isn't a one size fits all. For example, speaking of Go's channels - they are strictly about managing concurrency, they are not about parallelizing a workload and they do not work across address spaces / asynchronous boundaries. And if you think that Go's channels are the answer to everything, well, you would have been better off with Erlang, as there you might have had a valid argument. > IMHO This is not the case, if you think it is, explain. Can you take an arbitrary memory location and cast it to anything you want? Can you override how heap allocation happens? Can you allocate an array on the stack? Can you do RAII? Do you have the union type from C? In practice you have no control on where Golang allocates stuff - the compiler decides that based on really simple rules for escape analysis and as a general rule of thumb AFAIK anything that is allocated with "new" goes on the heap. What you can do with Golang is to use the "unsafe" package. But that's not different than using Java's sun.misc.unsafe ;-) The only real difference with Golang is that you can have stack allocated structs, as otherwise Java also does escape analysis. But besides this coming to Java 9, the real kicker is that .NET/C# has had stack allocated values since inception, in addition to much more potent "unsafe" constructs - in C# you can even do pointers and pointer arithmetic and the runtime will pin those memory addresses during execution for avoiding GC interference.

voidlogic 12y ago

>Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages. There is a trade-off being verbosity and maintainability, IMGO Go hits that. >In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work. LOL. Said no person who has actually distributed a multiplatofrm Java application ever- I should know. Both Java and Go are "write once, test everywhere", but in my XP Go has been smoother. >On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency. The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it. >Does Go have something like YourKit Profiler? Can you easily connect to a remote application for debugging or profiling? Yes. It comes baked into the stdlib, its "http/pprof" >Go doesn't have Maven or anything like it Biggest plus ever, goes native simple tooling doesn't need an external life support system. >This is a common misconception, when the opposite is factually true. You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries. >On the other hand the control on memory layout in Go is still weak IMHO This is not the case, if you think it is, explain.

bad_user 12y ago
> There is a trade-off being verbosity and maintainability, IMGO Go hits that. This is where we'll always disagree, because if you like Go, it's natural for you to come up with this argument, however the line you're drawing is completely arbitrary. I have yet to hear an argument about what makes Go strike a fine balance between verbosity and maintainability, when my feelings are the opposite - I find Go code to not be very maintainable in comparison with other static languages, because Go is not very statically type-safe. > LOL. Said no person who has actually distributed a multiplatofrm Java application ever Yet it happens all the time and a LOL is not an argument that disproves that. From my own experience, I have built stuff on top of Java / the JVM on OS X / Linux and deployed on Linux, Windows and OS X, without encountering any issues, ever, without worrying that Java's NIO will work or not, without worrying on whether the memory model will suddenly be different, without worrying on whether my app will leak on 32 bits platforms ;-) Android is the only ugly duckling, but that's only because Android doesn't have a JVM on it. It still works out well though. But if you have examples, I'd love to hear them out. > The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it. Now that's an arbitrary distinction, isn't it? What stops one from bundling the VM in the same deployed binary? If you want this distinction, the only valid argument is one of size, but then again for the server-side (where most of the Go stuff is used) that's completely meaningless. > Yes. It comes baked into the stdlib, its "http/pprof" Are you seriously comparing something like YourKit's Profiler and Java's remote attach and debugging capabilities to http/pprof? IMHO, that's not a comparison you can make. > Biggest plus ever, goes native simple tooling doesn't need an external life support system. There are many issues wrong with this line of thinking - the simple tooling you're talking about doesn't do what I and many others want it to do. Also if you look throughout history, all the languages that came with batteries included have suffered once the people finally reached the conclusion that the included batteries have been shitty. Which is what happens when you don't let evolution pick a winner with the community acting as the fitness function. But we'll talk in about 5 years. > You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries. But that's the point mate, the JVM is capable enough to build anything you want on top of it as libraries, there's no point for something to be hard-coded in the language. Which is a good thing, because when speaking of concurrency and parallelism, there isn't a one size fits all. For example, speaking of Go's channels - they are strictly about managing concurrency, they are not about parallelizing a workload and they do not work across address spaces / asynchronous boundaries. And if you think that Go's channels are the answer to everything, well, you would have been better off with Erlang, as there you might have had a valid argument. > IMHO This is not the case, if you think it is, explain. Can you take an arbitrary memory location and cast it to anything you want? Can you override how heap allocation happens? Can you allocate an array on the stack? Can you do RAII? Do you have the union type from C? In practice you have no control on where Golang allocates stuff - the compiler decides that based on really simple rules for escape analysis and as a general rule of thumb AFAIK anything that is allocated with "new" goes on the heap. What you can do with Golang is to use the "unsafe" package. But that's not different than using Java's sun.misc.unsafe ;-) The only real difference with Golang is that you can have stack allocated structs, as otherwise Java also does escape analysis. But besides this coming to Java 9, the real kicker is that .NET/C# has had stack allocated values since inception, in addition to much more potent "unsafe" constructs - in C# you can even do pointers and pointer arithmetic and the runtime will pin those memory addresses during execution for avoiding GC interference.