Integration so that you can easily integrate new Smalltalk code (in this case) with existing JVM code that your organisation/product might have.
Ecosystem because you don't need to kickstart a massive community of developers, open source libraries, a standard library, and so on, to have a useful language. Basically, by making a language that targets an existing platform (such as the JVM, CLR or JavaScript), you're "batteries included" from the very start. Better yet, the batteries will be familiar to shares of developers. This is major. Ever wondered why Lisp was only used by a couple of men with beards (and pg) until Clojure? I can promise you, it wasn't the square brackets.
Exit strategy because you want to be able to get out as easily as you got in. If you build non-hobby software with Redline Smalltalk, and for whatever reason the whole thing blows up in your face (e.g. big performance or security problems, project ends up unmaintained with large nuisances, and so on), you can migrate code to another JVM language bit by bit.
True, and I would also add the best performance of any managed runtime and the best profiling of any runtime.
Unless your language's main features coincide with the very specific pain points poorly addressed by the JVM (like struct arrays or mobile-phone deployment), I'll say that the JVM is the default target choice. It is any other choice that will need to be justified.
I could say exactly the same for any source-to-C compiler, and/or any system allowing decent FFI with C. Unless there is some different reason than the JVM itself, C has an even larger code base.
In a way, C can be considered an "existing platform" in much the same sense. I didn't include it in my list of examples because I really don't want to have to fight build tooling and cross-platform dependency hell in 2012 if I don't absolutely have to. With e.g. the JVM, you can get a jar from somewhere (or maven it in), and -poof- it just works, everywhere. This is a major advantage to the whole "ecosystem" point.
I understand why people choose the JVM, I'm sure it gets people up and running very quickly, and maybe if you're an enterprise java programmer then getting set up on the latest cool JVM based language is quite easy. But speaking as a Python/JS/.Net guy who once spent a few evenings trying to build something in Scala, the JVM just seems so painful to use.
I lost hours trying to set up Maven to download one library and build my project. All the documentation pages seemed to point to other documentation pages. I ended up trying to download about 30 jars manually, but the versions seemed to clash. I am convinced that the best thing a programming language can to do improve adoption is not to create a JVM version, but to create a package management system like pip/npm/NuGet.
In all fairness, it does come across as "well thought out" and "solid"; similar to the way that Java comes across as well thought out and solid. I can tell it does a lot but I have to be completely initiated into the JVM way of thinking before I can get anything done. The quickstart page has some 6000 words, which describes how to set up an XML file containing all sorts of stuff. I'm introduced to things like a standard directory structure, Archetypes, CLASSPATHs and Project Object Models. All because I finished the Scala tutorial and then tried to use a library that wasn't installed on my machine already.
With Python, in the past things were a little trickier with easy install, but these days the library's web page would probably have told me to type:
pip install third_party_library
And that's about it. Even if you haven't got Pip it's quite obvious what to do, the terminal tells you it doesn't know what pip is, so you Google "install pip Windows/Mac/..." and pretty soon you're up and running.
The first couple of days with a language can be painful. People have trouble getting python libraries to work too. Maven is really quite well thought out and solid.
> People have trouble getting python libraries to work too
Aside from developing on Windows with C extension libraries, those are increasingly rare. Pip + virtualenv works wonders, and the latter has been folded into the most recent official release of CPython (3.3), so it's now officially the right way to do Python package management, as opposed to simply the de facto approach.
As someone who's had to use both, I will say that my experience with even the most basic, functionality in Java's package management is a nightmare, whereas learning how to use the same basic functionality in pip/virtualenv was so easy, I wondered why I'd been putting it off so long.
> I lost hours trying to set up Maven to download one library and build my project.
You should check out Apache Buildr (http://buildr.apache.org/). It gives you the power of Maven repos with a Ruby "front end". And, yes, I know it's imperative and not declarative but I find that the build files tend to be small and understandable.
I know it's not considered a good thing to do, but I also have problems with Maven, mostly because I so seldom use Java.
But I found JarFinder in IntelliJ to be a good replacement for many needs. You just start using a class and it suggests a couple of jar's to download and reference. :)
Have you tried writing a patch for one of the large C compilers? and getting it into mainline? not trivial either.
For the JVM there are choices. IBM, Azul, Oracle, OpenJDK and many other more academic ones. With different tradeoffs and costs. I have switched massive code bases from one to the other with minimal effort.
Switching C compiler is more invasive than switching JVM providers. And many other languages only have a single sanctioned runtime.
Sure the JVM eco system is far from perfect. But it is dependable!
Any language that someone is arguing should be "the next big language" should take things other than everyday development on the JVM. Nevertheless, wanting to be able to patch the JVM has been a part of my "everday development" several times.
i really dont get it why this is so popular... maybe it makes your code faster yes but it comes with all the cluter that is the JVM.
The JVM is a big black box and I think its veryhard to see whats happening inside.
have someone tried to write a patch for the JVM? no? then try!