5 ms·
"The JVM the only game in town if you want some combination of high performance, the ability to do user-space systems level programming, type safety, and GC."
by DocSavage 14y ago
"The JVM the only game in town if you want some combination of high performance, the ability to do user-space systems level programming, type safety, and GC."
I think all those points are covered by Go. And Go is more succinct. It was trivial to cross-compile Go executables on my Mac for Windows and Linux.
- ch0wn 14y agoThe next sentence ruins it though: "Nobody loves Java but it is the easiest language to recruit for if you're targeting the JVM." Recruiting for Go is not nearly as easy as for Java.
- eru 14y agoPromising work in Scala or Clojure will probably lead to better success. At least if you employ a measure of success even slightly more sophisticated than thickness of the pile of resumes you receive.
- luriel 14y agoIf you hire a Go programmer, it probably will be somebody that deeply cares about their work, somebody who has a certain sense for aesthetic and technical simplicity, and other qualities that not common that among Java programmers.
- VMG 14y agoAlso the person will be more expensive.
- stock_toaster 14y agoI agree that Go may very well be a "python paradox"[1] language. [1]: http://paulgraham.com/pypar.html http://paulgraham.com/pypar.html
- mercurial 14y agoOn the other hand, Go does not have the benefit of the huge Java ecosystem.
- kamaal 14y agoYou need the huge Java ecosystem and benefit from it only if you wish to be and use the Java ecosystem, which is basically a million different ways to use XMLs, abuse design patterns, needlessly make solutions verbose and complicated to make your work complex and very important. Other technologies will have their own ecosystem. Which will grow at their own pace as demand for that grows.
- mercurial 14y agoTrolling much? Of course you have a number of AbstractBeanXmlFactoryFactory, and it's generally pretty verbose, but you do have a large number of well-tested, well-performing solutions already established. And that's definitely an advantage when you have a problem to solve right now.
- lsh 14y agoAgreed - about Java and the trolling. All his comments on this topic is nothing but a troll.
- luriel 14y agoI count this as a Go feature.
- jlarocco 14y agoI don't think the Java ecosystem is really that great any more. There was definitely a time when it was the biggest and best, but I don't think that's been the case for a while. Is there anything in particular that's available in Java that you couldn't get in Go or Python?
- white_devil 14y ago
- noelwelsh 14y agoI knew this would come up. Haskell and Rust cover the same space as well. HN seems to have some weird obsession with Go at the moment, but the reality is that outside of this little bubble no-one knows or cares about Go. I use "no-one" in the to-within-rounding-error sense, not the literal sense. Go may gain sufficient mindshare in the future that it gains a space in the average developer's head as their goto tool for a certain job but it isn't there yet. While we're at it, Java is not the only language on the JVM. For example, Scala is growing fast and it has polymorphism AND sane error handling (http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.util.Try http://www.scala-lang.org/archives/downloads/distrib/files/n...), features which AFAIK elude Go.
- DocSavage 14y agoWell, I was responding to the "only game in town" characterization with respect to the points you gave, all of which are addressed in Go. You could add as requirements a mature and highly optimized GC and a large pool of talent, then it might be correct. (If you are talking Scala, Clojure, and some other JVM-based languages, I think Go talent pools will quickly catch up if it's not already there.) I would think HN has a very broad readership across many occupations. Dismissing Go as an HN bauble seems very odd. The point is that I enjoy Go, and it handles all the things you mention and a few more within its sweet spot. And it works well even now, immature that it is. It's a reasonable alternative to the JVM for lots of problems. Go is also most pertinent from the Python perspective because it's probably gaining recruits from that community instead of the C/C++ community.
- burntsushi 14y ago> it has polymorphism AND sane error handling ... features which AFAIK elude Go Go certainly has polymorphism. Also, I've written about ~30,000 lines of Go thus far, and the programs I've produced have by far the best error checking than any other program I've produced with another language. I think that at least qualifies as "sane." (Particularly since I find my error checking to be easy to write and easy to read.)
- cmccabe 14y agoGo vs. Java: * Go makes it a lot easier to interface with native libraries than Java ever will. I think anyone who has ever written JNI can confirm that it is a nightmarish interface. JNI also has performance problems, to the point where using an optimized C implementation through JNI is often slower than writing the same thing in Java. * Java definitely has more libraries available. However, partly because of point #1, Go is catching up quickly. It's very easy to wrap C libraries in a Go interface with cgo. Also, a lot of the old Java code and frameworks smell kind of funny. Do you want to write a new AWT application in 2012? Really? Yeah, Java has more stuff, but... is it kind of stuff you actually want to use, or the kind of stuff you find at the thrift store? * Go exposes more OS-level features than Java. For example, Java didn't get a way to create softlinks until JDK7. * Java does not provide a built-in solution to dependency management. The CLASSPATH mechanism essentially punts the problem to the individual developer. It seems easy enough to dump all your jars in a folder and call it a day, but eventually you end up in a situation where library X depends on library Y, which depends on library Z, which depends on a different version of library X. Hmm. Guess you are in trouble! With Go, this problem does not exist because things are compiled statically, and Go has standardized library paths. Maven and OSGi were both attempts to solve the dependency problem in Java-land. However, since they weren't standard parts of the language, they felt clunky and bolted-on. Maven also combines the functionality of apt-get, Makefiles, and distcc in one giant monolith, which can make debugging... interesting. * Partly because of the complexity of Java classloaders, a number of security vulnerabilities have been discovered recently. * Go programs have a miniscule startup time, whereas the JVM takes a lot of time to start. This seems like a very minor point, until you realize that for things like command-line utilities, it makes Java a real performance-killer. This is one often-overlooked reason why Java fizzled in the browser but succeeded on the server. polymorphism AND sane error handling [elude Go] Go has polymorphism. I like Go's error handling a lot-- but this topic has been discussed elsewhere.
- sanderjd 14y agoGo's GC has a long way to go before it is anywhere near the maturity level of the JVM's. One of the biggest advantages of building a language on the JVM is that you get about the best GC implementation out there completely for free.