3 ms·

The difference is that you can upgrade each Go application to Go 1.6 separately, whereas with Java, once you upgrade the JVM, all of your applications get upgra

The difference is that you can upgrade each Go application to Go 1.6 separately, whereas with Java, once you upgrade the JVM, all of your applications get upgraded at once. While you could technically have two different JVMs installed side-by-side, in practice nobody actually does this because of the operational complexity and the way that Java handles dependencies. Perhaps this will become an issue for Go if people start using the new shared library feature. For Java, _everything_ is a shared library (sort of), so this is an omnipresent issue. I think both Go and Java have been good about avoiding backwards incompatible changes in the standard library. Both languages have an explicit policy of avoiding these whenever it is at all possible. Frankly, the Go standard library is a lot better written than the Java one. For example, I dare you to figure out how to call statvfs from Java, or figure out how many hardlinks there are to a specific file inode. Or make an asynchronous DNS lookup. Even simple things like creating a socket without doing a DNS lookup are very difficult to achieve in the Java standard library.

pjmlp 11y ago
Actually we have deployments where the JRE is packaged alongside the application, because in some customers teams have the freedom to choose their JDKs. However we also have projects where the Java version is married to whatever the Websphere deployment of the day supports. And on Android, well there is no upgrade at all. Which is yet another reason to use the NDK, even with all the 3rd class developer treatment, at least the C++ compiler gets updated and doesn't depend on the Android version of the target devices.
mike_hearn 11y ago
I really don't get this at all. The JVM is a program. It sits in a single directory. I routinely have several installed on my laptop. There are no operational complexities from having multiple different versions installed, if you want that. I suspect this really boils down to operational complexities of Linux distros, not Java. If your package manager only lets you install one JVM then maybe this seems "complicated" relative to Go, but that's not a Java problem. WRT the standard library, yes the Java standard library doesn't expose UNIX specific syscalls. It exposes stuff at a higher level instead because it tries to be portable. That's a different tradeoff to what Go makes but I wouldn't say that makes it badly written. To me badly written would mean buggy, confusingly designed, too small or too big etc. If you want to write non-portable software then that means you may have to link in an extra library or so (like JNA). Creating sockets does not do DNS lookups in Java. You may be thinking of the URL class, which does, and there's a URI class that avoids that.
- colin_mccabe 11y ago
  It's not a Linux issue. People almost always install the Oracle JVM themselves rather than using a package manager (it's a long story...) The desire for a single JVM comes partly from the architecture of Hadoop itself. Hadoop is structured as a framework (you give your MR job to YARN and it runs it by creating new JVMs for you). The Java standard library is weak in many areas. The "write once, run anywhere" ideology is part of it, but there are also just... weak parts.

pjmlp 11y ago

Actually we have deployments where the JRE is packaged alongside the application, because in some customers teams have the freedom to choose their JDKs. However we also have projects where the Java version is married to whatever the Websphere deployment of the day supports. And on Android, well there is no upgrade at all. Which is yet another reason to use the NDK, even with all the 3rd class developer treatment, at least the C++ compiler gets updated and doesn't depend on the Android version of the target devices.

mike_hearn 11y ago

I really don't get this at all. The JVM is a program. It sits in a single directory. I routinely have several installed on my laptop. There are no operational complexities from having multiple different versions installed, if you want that. I suspect this really boils down to operational complexities of Linux distros, not Java. If your package manager only lets you install one JVM then maybe this seems "complicated" relative to Go, but that's not a Java problem. WRT the standard library, yes the Java standard library doesn't expose UNIX specific syscalls. It exposes stuff at a higher level instead because it tries to be portable. That's a different tradeoff to what Go makes but I wouldn't say that makes it badly written. To me badly written would mean buggy, confusingly designed, too small or too big etc. If you want to write non-portable software then that means you may have to link in an extra library or so (like JNA). Creating sockets does not do DNS lookups in Java. You may be thinking of the URL class, which does, and there's a URI class that avoids that.

colin_mccabe 11y ago
It's not a Linux issue. People almost always install the Oracle JVM themselves rather than using a package manager (it's a long story...) The desire for a single JVM comes partly from the architecture of Hadoop itself. Hadoop is structured as a framework (you give your MR job to YARN and it runs it by creating new JVMs for you). The Java standard library is weak in many areas. The "write once, run anywhere" ideology is part of it, but there are also just... weak parts.