5 ms·

Yeah, that makes sense. If the killer app is JVM interop, nothing but JVM based languages should even be on the table. The "why Clojure?" question just becomes

Yeah, that makes sense. If the killer app is JVM interop, nothing but JVM based languages should even be on the table. The "why Clojure?" question just becomes "because Clojure is the best language on the JVM," which is not too interesting of a topic IMO. Haskell has decent interop with C/C++ languages, but certainly nobody uses haskell because of that.

BoiledCabbage 6y ago
If the killer app is practical usage than Clojure clearly comes out on top. The problem with function language adoption is people keep pushing Haskell likes it's anything more than at its essense a language exploration research project. The fact that you'd have a comment that ignores a language because it wins by default because it practical is more proof that people evaluating languages are speaking two different... well languages. Some are looking for what they feel have the coolest ideas, others are looking for languages with very cool ideas, much better than what they're using today, and can still be effective/ productive in. Haskell is cool if you want to think about or play with ideas. Clojure is cool ideas, and can still be productive in (ie full modern library support). As well if you don't know, F# falls into that same bucked of cool ideas, better than your avg imperative language and can still be very productive due to language and .net library. We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. Otherwise the produvtivity loss from lack of libraries is almost impossible to overcome from any possible produvtivity gains from the language.
- mumblemumble 6y ago
  > We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. I certainly hope this does not turn out to be the case. Both the JVM and .NET impose a certain type system on all their client languages. Those languages have an option to embrace it, like F# or Kotlin have, or to struggle against it, like Scala has, but they don't have the option to truly pull free of it. Not without shutting out effortless interop with the rest of the platform, and, in doing so, undermining the whole purpose of being on those platforms in the first place. And, since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation.
  - BoiledCabbage 6y ago
    > since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation. Not disagreeing at all. Interop with a library means interop/conformance with its type system. Which means if you want languages with new / innovative type systems, someone will need to build a library system to resolve this. Either an untyped library system as large as the .NET or Java library systems, or a library that has a trivial way to tack on type transformation of some form so that each language that interops with it can minimally add a type translation layer between the two. What that looks like, I'm not certain. But as long as engineers need to be productive, they need a robust modern library system. No new lang will get adopted if the lang author also needs to build up a complete library system, so it must be a general component.
    - mumblemumble 6y ago
      I'm hopeful that Rust will lead in a good direction. A C-style ABI, by virtue of being the least common denominator, is probably the best bet for re-usability across paradigms. Higher level languages would want to write idiomatic façades, but they already habitually do that anyway, even on higher-level platforms like Java and .NET. And I think that deterministic memory management is probably also a pretty important feature. You don't want your libraries all bringing their own clever ideas about object lifetimes and such. But you also need it to be very reliable; a real danger with inviting libraries written in C and C++ into your process space is that they are liable to corrupt your memory. Rust's affine type system seems like a big step in the right direction here. Similar thoughts for the error model. I don't have any particular complaints about exceptions, except that you don't want to be bleeding them on an external API, because that ends up being another spot where languages can fail to mesh. What's missing, though, is that there is no good cross-platform standard for libraries that work with the C ABI (neither in source nor binary form) for other languages to plug into. So that's where I get to thinking that Rust might be closer to (if not exactly at) the mark than C is.
  - thu2111 6y ago
    I don't think that's really the case anymore. You have to separate three things: 1. Using the JVM for its capabilities, like the JITC and GC engines, which are very powerful. 2. Using the JVM for Java interop. 3. Using the JVM for generic cross-language interop. The nice thing about the JVM especially now with Graal/Truffle is it lets you explore and choose almost any point on the spectrum between "we're totally alien and the JVM is just our runtime" and Kotlin-esque "we are basically Java v2 with perfect interop". Modern JVMs are capable of running languages as diverse as Haskell, JavaScript, Kotlin, Ruby, WebAssembly, LLVM bitcode etc. Obviously if you're coding in C or Rust and running it on the JVM via Sulong, your interop is going to be limited to creating objects and invoking simple functions on them. If you're in Ruby or Python your interop gets better: you can expect automatic translation of things like Java-world collections to a vaguely native-language like collection via the Polyglot interop layer. And if you're Kotlin then you don't even create your own collections at all, just use the JDK standard library. The point is, you don't have to use the Java bytecode type system to interop with Java or other languages anymore. Graal has fixed that. Your language can have any arbitrary semantics and it will still be JIT compiled, GCd and it can still call into other languages. The closeness of the type system is now a choice you make that trades off ease of use of Java libraries vs whatever divergence you want to have.
- Scarbutt 6y ago
  While all of this is true and interop can save you from being completely stuck in a problem on many occasions, the interop is not as seamless as many advertise, at least not in Clojure, don't know about F#. Many times in Clojure is easier to write two wrappers, one in Java (to make the Java lib access tolerable from Clojure lol) and the Clojure one. And I'm talking about ad-hoc wrappers for your use case/functionality needs, not general wrappers, which take much more time. Productivity goes down in this translation, you start to wonder why are you wasting all this time wrapping Java libs. Kotlin is much better in this area of course.
  - thu2111 6y ago
    Can you elaborate on this? What do the two wrappers need to do - where is the primary pain points?
andrewem 6y ago
I think there are at least two cases where JVM interoperability is relevant. The first is when a company is already using the JVM and so knows how to deploy and monitor it; in that case, it’s easy to choose because it presumably imposes limited burdens on the company’s operations people. The second case is when you want access to some mature environment, so that all kinds of packages and services are available to support it, but don’t have a commitment to any one in particular yet, and Clojure qualifies because of the JVM; in that case, a non-JVM language like Python, PHP, or Ruby might also work.
didibus 6y ago
It's not just killer JVM interop, it's killer all around interop. Clojure relies on interop more than any other major language, the language has inherent syntax around it and even its standard library is designed with it in mind. That makes it very easy to adapt over different runtimes, giving Clojure more reach than most. That's why you have Clojure JVM, Clojure CLR, Clojure Unity, ClojureScript, Clojerl (Clojure on BEAM), etc.

BoiledCabbage 6y ago

If the killer app is practical usage than Clojure clearly comes out on top. The problem with function language adoption is people keep pushing Haskell likes it's anything more than at its essense a language exploration research project. The fact that you'd have a comment that ignores a language because it wins by default because it practical is more proof that people evaluating languages are speaking two different... well languages. Some are looking for what they feel have the coolest ideas, others are looking for languages with very cool ideas, much better than what they're using today, and can still be effective/ productive in. Haskell is cool if you want to think about or play with ideas. Clojure is cool ideas, and can still be productive in (ie full modern library support). As well if you don't know, F# falls into that same bucked of cool ideas, better than your avg imperative language and can still be very productive due to language and .net library. We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. Otherwise the produvtivity loss from lack of libraries is almost impossible to overcome from any possible produvtivity gains from the language.

mumblemumble 6y ago
> We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. I certainly hope this does not turn out to be the case. Both the JVM and .NET impose a certain type system on all their client languages. Those languages have an option to embrace it, like F# or Kotlin have, or to struggle against it, like Scala has, but they don't have the option to truly pull free of it. Not without shutting out effortless interop with the rest of the platform, and, in doing so, undermining the whole purpose of being on those platforms in the first place. And, since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation.
- BoiledCabbage 6y ago
  > since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation. Not disagreeing at all. Interop with a library means interop/conformance with its type system. Which means if you want languages with new / innovative type systems, someone will need to build a library system to resolve this. Either an untyped library system as large as the .NET or Java library systems, or a library that has a trivial way to tack on type transformation of some form so that each language that interops with it can minimally add a type translation layer between the two. What that looks like, I'm not certain. But as long as engineers need to be productive, they need a robust modern library system. No new lang will get adopted if the lang author also needs to build up a complete library system, so it must be a general component.
  - mumblemumble 6y ago
    I'm hopeful that Rust will lead in a good direction. A C-style ABI, by virtue of being the least common denominator, is probably the best bet for re-usability across paradigms. Higher level languages would want to write idiomatic façades, but they already habitually do that anyway, even on higher-level platforms like Java and .NET. And I think that deterministic memory management is probably also a pretty important feature. You don't want your libraries all bringing their own clever ideas about object lifetimes and such. But you also need it to be very reliable; a real danger with inviting libraries written in C and C++ into your process space is that they are liable to corrupt your memory. Rust's affine type system seems like a big step in the right direction here. Similar thoughts for the error model. I don't have any particular complaints about exceptions, except that you don't want to be bleeding them on an external API, because that ends up being another spot where languages can fail to mesh. What's missing, though, is that there is no good cross-platform standard for libraries that work with the C ABI (neither in source nor binary form) for other languages to plug into. So that's where I get to thinking that Rust might be closer to (if not exactly at) the mark than C is.
- thu2111 6y ago
  I don't think that's really the case anymore. You have to separate three things: 1. Using the JVM for its capabilities, like the JITC and GC engines, which are very powerful. 2. Using the JVM for Java interop. 3. Using the JVM for generic cross-language interop. The nice thing about the JVM especially now with Graal/Truffle is it lets you explore and choose almost any point on the spectrum between "we're totally alien and the JVM is just our runtime" and Kotlin-esque "we are basically Java v2 with perfect interop". Modern JVMs are capable of running languages as diverse as Haskell, JavaScript, Kotlin, Ruby, WebAssembly, LLVM bitcode etc. Obviously if you're coding in C or Rust and running it on the JVM via Sulong, your interop is going to be limited to creating objects and invoking simple functions on them. If you're in Ruby or Python your interop gets better: you can expect automatic translation of things like Java-world collections to a vaguely native-language like collection via the Polyglot interop layer. And if you're Kotlin then you don't even create your own collections at all, just use the JDK standard library. The point is, you don't have to use the Java bytecode type system to interop with Java or other languages anymore. Graal has fixed that. Your language can have any arbitrary semantics and it will still be JIT compiled, GCd and it can still call into other languages. The closeness of the type system is now a choice you make that trades off ease of use of Java libraries vs whatever divergence you want to have.
Scarbutt 6y ago
While all of this is true and interop can save you from being completely stuck in a problem on many occasions, the interop is not as seamless as many advertise, at least not in Clojure, don't know about F#. Many times in Clojure is easier to write two wrappers, one in Java (to make the Java lib access tolerable from Clojure lol) and the Clojure one. And I'm talking about ad-hoc wrappers for your use case/functionality needs, not general wrappers, which take much more time. Productivity goes down in this translation, you start to wonder why are you wasting all this time wrapping Java libs. Kotlin is much better in this area of course.
- thu2111 6y ago
  Can you elaborate on this? What do the two wrappers need to do - where is the primary pain points?

andrewem 6y ago

I think there are at least two cases where JVM interoperability is relevant. The first is when a company is already using the JVM and so knows how to deploy and monitor it; in that case, it’s easy to choose because it presumably imposes limited burdens on the company’s operations people. The second case is when you want access to some mature environment, so that all kinds of packages and services are available to support it, but don’t have a commitment to any one in particular yet, and Clojure qualifies because of the JVM; in that case, a non-JVM language like Python, PHP, or Ruby might also work.

didibus 6y ago

It's not just killer JVM interop, it's killer all around interop. Clojure relies on interop more than any other major language, the language has inherent syntax around it and even its standard library is designed with it in mind. That makes it very easy to adapt over different runtimes, giving Clojure more reach than most. That's why you have Clojure JVM, Clojure CLR, Clojure Unity, ClojureScript, Clojerl (Clojure on BEAM), etc.