*The JVM as a target is much friendlier to other languages, compared to the CLR, in spite of the initial hype surrounding the CLR's multi-language capabilities.*
I'm not sure this is true, Don Syme has written several times about how difficult it would be to implement F# on the JVM - I believe tail recursion and not being able to define new intrinsic types (i.e. new primitives) are the sticking points. I think a lot of people believe that from a functionality point of view the CLR is better than the JVM - as far as I know it's not missing any functionality from the JVM and it has significant advantages (reified generics as well as the functionality mentioned above). That said, I agree with most of what you say. But it's not just the deployment and UNIX toolchain, it's also the development OS. I don't run Windows nor do I want to, but if I don't the development tooling for .NET languages is terrible. Even if Mono were a respectable JVM competitor for deployment (and it may be, I hear it's pretty good these days) there is no decent environment for writing C# or F# on OSX. Which is a shame, C# is a much nicer language than Java. So although I love the look of F# I've never seriously played with it, which means I'll almost certainly never use it for any real work. Cheers, Colin On 6 June 2013 20:14, Alexandru Nedelcu <m...@alexn.org> wrote: > On Thu, Jun 6, 2013 at 9:55 AM, Zed Becker <zed.bec...@gmail.com> wrote: > >> Why do the languages running on the CLR (ironRuby, ironPython, >> ironScheme, ScalaCLR) do not get to live long enough in the sunshine, >> whereas same languages get embraced by the Java runtime, and live in the >> limelight? > > > N.B. - Not all is well on top of the JVM. Jython, the Python > implementation, tends to die and get revived and then it dies again. I > don't know the state of IronPython right now, but it was in much better > shape when I last looked at it. > > The JVM is more popular for other languages though. There are multiple > issues at play here. > > Language authors prefer the JVM as a target, as it's easier to bootstrap a > new language on top of the JVM. The JVM as a target is much friendlier to > other languages, compared to the CLR, in spite of the initial hype > surrounding the CLR's multi-language capabilities. There's also the huge > open-source Java ecosystem to blame. For everything you want to do, there's > already a library that you can build on top of (Netty is a stellar example, > being used all over the place). Also, many language authors would like to > support both, but they lack the resources to do it, so they end up picking > one and stick with it. > > Then there's the audience. Unix has always been a true tower of Babel for > programming languages (that's why it has a Shebang). And the JVM has and > always had first-class support for Unix variants, including Linux, BSD and > OS X. People that target Unix for deployments (web apps, mobile apps) or > people that use Unix on their workstations accustomed to Unix toolchains, > will always prefer tools that are first-class in Unix. Having true > cross-platform support and not having to recompile is pretty sweet too. > > Then there are also the Java developers that are fed up with Java, the > programming language, but love the JVM, the tooling available and the Java > ecosystem (such as myself). > > So Unix is like a tower of Babel for programming languages, but the .NET > ecosystem is the exact opposite. .NET developers that want to pick > alternatives to C# have an uphill battle to do against the status quo, as > .NET developers and companies tend to be pretty conservative. The uptake of > F# has been abysmal compared to JRuby, even though F# is included in Visual > Studio and classic ASP.NET is still more popular than ASP.NET MVC. > > JRuby is an interesting case-study. It is popular because it's used as a > deployment target for web applications (Rails runs well on top of it), > quickly becoming the de-facto standard, as more and more people start > realizing how awesome it is compared to Ruby MRI in a server-side > environment. With each release, performance has been improved by leaps and > bounds. So it won converts that normally live in the Ruby ecosystem and had > no interest in Java or the JVM. > > Also, JRuby is a community-driven project, sponsored by multiple companies > involved in the Ruby ecosystem, born out of real necessities and that > thrived because it was designed to fit well within the existing Ruby > ecosystem. IronRuby, a project started by Microsoft for demoing the DLR > library, never stood a chance to catch up with it. > > -- > Alexandru Nedelcu > https://bionicspirit.com > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
