3 ms·

I 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

I 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 ago
Well, 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 ago
Go 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.

DocSavage 14y ago

Well, 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 ago

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