People use languages for many reasons, but the most common reason is that it is perceived to solve a problem better than the alternatives.
The R language is a frigging mess but it has a huge number of libraries in the statistical domain. For this reason it's a popular choice for writing data exploration and analysis programs.
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. Nobody loves Java but it is the easiest language to recruit for if you're targeting the JVM.
Rails is the engine that drives Ruby. iOS drives Objective-C. The browser drives Javascript.
To me (an very infrequent user of Python) Python has NumPy and Django. So long as those projects continue to maintain their share of thought leadership Python will be fine.
---
Kinda odd to see this post on HN. It doesn't really seem to say much.
"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.
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.
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.
> 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.)
* 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.
Go'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.
You 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.
Trolling 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.
I 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?
First of all, the number one component of the Java ecosystem is the JVM - a rock solid execution environment on pretty much any hardware/OS combination you're likely to find in the wild. Also, the JVM is a very decent environment. For one, it has no trouble with high levels of concurrency. Neither Python or Ruby particularly likes concurrence (but achieves it with multiple processes). Write once, run anywhere might have been a mirage when Java came out, it's not anymore.
Next step on the ladder is languages. You can mix any combination of Java, Scala, Groovy, Clojure, JRuby, Jython and others with little or no friction.
Then there's infrastructure. There's a good selection of rock solid application servers - Tomcat, Jetty and Glassfish comes to mind. The entire JDK toolchain, especially VisualVM, JConsole and JMX. Get a stacktrace or a heap dump from a running java process? Trivial and built in.
Finally, the libraries: JDBC is pretty neat: Every database under the sun plugs into the same interface. Terracotta has a pretty interesting line up (http://terracotta.org/products). Hadoop - it's a full ecosystem of it's own. Eclipse and IntelliJ IDEA. Apache POI for MS Office doc manipulation. Apache FOP is supposed to be pretty powerful. Lucene. Apache Commons.
If 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.
Promising 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.
Yes, Python will probably retain niches as a beginner language and a language for scientific data processing (but not in web development). This is because it's fairly easy to learn and the language enforces certain minimal coding practices better than most other languages. But it should be clear by now that Python certainly won't be taking over the broader programming world.
There was group of guys at a previous job of mine who loved programming in Python so much that they started advocating for its use at work for serious projects. They eventually got their wish, but six months later they realized that using Python for heavy-duty corporate stuff is far removed from using it for personal hobby programming.
The main problem is that Python has been oversold. This will be corrected in due course, and things will go on with Python being used only where appropriate.
No, Python will not be "taking over the broader programming world", nor will any other language. Of course Python will go on, hopefully, being used only where appropriate.
As for your n = "?" (your ex=colleagues) anecdote, it is laughable, ignorant, and insulting to the intelligence. Are you not aware of "heavy-duty corporate stuff" such as Google, or Youtube, let alone the massive scientific ecosystem built around Python, or do you consider such things "personal hobby programming"?
Python has not been "oversold", as it has never been sold at all. Perhaps you should ask yourself why MIT has converted its courses to Python.
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.
There's Google Go now, too, which is arguably a better solution than the heavyweight JVM (though a worse one than C or Ada).
The R language is a frigging mess but it has a huge number of libraries in the statistical domain. For this reason it's a popular choice for writing data exploration and analysis programs.
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. Nobody loves Java but it is the easiest language to recruit for if you're targeting the JVM.
Rails is the engine that drives Ruby. iOS drives Objective-C. The browser drives Javascript.
To me (an very infrequent user of Python) Python has NumPy and Django. So long as those projects continue to maintain their share of thought leadership Python will be fine.
---
Kinda odd to see this post on HN. It doesn't really seem to say much.