Comment by maxs | Hacker News Reader

Comment by maxs | Hacker News Reader

I'd like to use any of the alternative JVM languages out there.. However, as someone who already has a great deal of code in JARs, it seems like it would increase complexity for little benefit.

What I am saying is that I don't like the costs of investing into a whole another ecosystem (say Scala or Clojure), with an unproven future, and a smaller market (compared to pure Java). Of course, you can call any JAR from Scala and Clojure, but it seems to me that a Scala/Clojure JARs are not equally callable from Java (or other JVM languages). You start getting into runtime JARs and the basic "impedance-mismatch" of different language abstractions. (For example, for languages with traits, what do those correspond to in Java -- interfaces, abstract classes?)

Ideally, I would like to have a language that can compile a Java class that seamlessly interacts with other Java stuff. The problem is that it seems to me you don't get any of the benefits of Scala, Clojure, in that setup, because the runtime adds a lot of value. Most that you could get are nice syntax for lambdas (which are a bit verbose in Java, but not really a problem for me), but those are anyways coming in JDK 8.

Have people on HN thought about this? People who use alt JVM languages, I am curious about your opinions. Honest question, I am not interested in language flamewars.

Clojure has a fully optional, very grokkable and well-defined map from Clojure to Java, in the form of protocols and gen-class. Protocols are a natural part of the language, and if you need a concrete gen-class, because Clojure is functional it's easy to plug whatever Clojure functionality into a Java interface.

I think this is the main advantage of Xtend. Xtend compiles to plain Java classes and uses the same typesystem as Java. This way you get excellent Java interoperability, as Xtend classes can be used seamlessly from Java and vice versa. This goes so far that I usually mix in my projects Java and Xtend code. I recently wrote a blog post about this topic, as well [1].

[1] http://sebastianbenz.de/5-Things-that-make-Xtend-a-great-Lan...

In my experience Clojure is very callable from Java. For example, Lists and Maps can be passed as normal arguments to clojure functions without conversion step. This works because Clojure favors abstractions over concretions. For example, instead of a concrete cons cells datastructure, Clojure has the ISeq interface. As far as I can tell, calling clojure from Java introduces no overhead at all.

Datomic is a commercial database system developed in Clojure. The peer library is what you use in your client application to query the Datomic server. The peer library is written in Clojure. I expect that means calling Clojure from Java, and including the Clojure runtime jar in a client application, is safe/stable/supported enough to build a business on top of it.

I'm still learning though, so take what I said with a grain of salt.

As others mentioned, Clojure makes it fairly simple to generate a normal Java class containing your Clojure code. In addition, you can access clojure.lang.RT to run your Clojure function directly, like this: RT.loadResourceScript("pkg1/pkg2/runner.clj"); RT.var("pkg1.pkg2.runner", "run").invoke(args);

However, in my experience, Groovy is about as simple as it can be. Just put your Groovy code inside a class and it looks exactly like any other Java class.

There's no Scala runtime. I think you're either mistaken or using the wrong term. Do you mean the standard library? If so then what's the problem with adding that to your classpath?

I get that some of the Scala constructs (e.g. traits) may be unweildy to use from Java, but I think you're unlikely to have a large and growing surface area for that. On a case-by-case basis I think you could just provide a Java friendly interface from your Scala code.

> Ideally, I would like to have a language that can compile a Java class that seamlessly interacts with other Java stuff.

Groovy fits the bill.

Groovy has a lot of interop issues. The dynamic resolution of overloaded methods being just one example. Xtend is much more interoperable as it binds at compile-time just like Java does and uses the exact same type system.

> The dynamic resolution of overloaded methods being just one example.

That has never caused an interoperability issue for me. If there is concern about which method would get picked then use explicit types.

> Xtend is much more interoperable as it binds at compile-time just like Java does and uses the exact same type system

You can enable this in groovy 2 using explicit types and @CompileStatic.

Reply on news.ycombinator.com