5 ms·

The JVM interop is a huge positive for Clojure, in my opinion. Being able to consume any JVM library makes Clojure usable in many more professional settings th

The JVM interop is a huge positive for Clojure, in my opinion. Being able to consume any JVM library makes Clojure usable in many more professional settings than Haskell.

fiddlerwoaroof 6y ago
Yeah, I worked at a company where several Haskell projects crashed and burned because of interop issues with existing JVM systems, but the Clojure project I worked on did really well.
johnday 6y ago
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.
- 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.
city41 6y ago
ClojureScript is another plus. I'm unsure what Haskell's story is for frontend dev (I have no Haskell experience).
- johnday 6y ago
  The GHC compiles Haskell either directly to assembly or via LLVM. There is a GHCJS project, which works fine, but personally I've not used it. There's not much of a story in terms of frontend Haskell. On the other hand, there are two "child" languages of Haskell for the job: Elm, which is a frontend-focused language, and PureScript, which compiles to JS and is designed for that use case.
- teodorlu 6y ago
  As someone who tried out GHCJS, then Purescript, then Elm, then Clojurescript: - GHCJS and purescript are powerful, but the learning experience might be steep[1] - Elm is an excellent entrypoint into ML programming in the browser. Solid story for new users, and a great standard library for interactive web applications. - ClojureScript differs from Elm in that it embraces its host, with all its power and all its wrinkles. Writing Elm is mostly a smooth experience. Read the guide[2], then you can actually build a web app. I've spent the most time with Elm. Other people might have different experiences. [1]: a few years since I tried, might be better now. [2]: https://guide.elm-lang.org/ https://guide.elm-lang.org/

The JVM interop is a huge positive for Clojure, in my opinion. Being able to consume any JVM library makes Clojure usable in many more professional settings than Haskell.

fiddlerwoaroof 6y ago

Yeah, I worked at a company where several Haskell projects crashed and burned because of interop issues with existing JVM systems, but the Clojure project I worked on did really well.

johnday 6y ago

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.
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.

city41 6y ago

ClojureScript is another plus. I'm unsure what Haskell's story is for frontend dev (I have no Haskell experience).

johnday 6y ago
The GHC compiles Haskell either directly to assembly or via LLVM. There is a GHCJS project, which works fine, but personally I've not used it. There's not much of a story in terms of frontend Haskell. On the other hand, there are two "child" languages of Haskell for the job: Elm, which is a frontend-focused language, and PureScript, which compiles to JS and is designed for that use case.
teodorlu 6y ago
As someone who tried out GHCJS, then Purescript, then Elm, then Clojurescript: - GHCJS and purescript are powerful, but the learning experience might be steep[1] - Elm is an excellent entrypoint into ML programming in the browser. Solid story for new users, and a great standard library for interactive web applications. - ClojureScript differs from Elm in that it embraces its host, with all its power and all its wrinkles. Writing Elm is mostly a smooth experience. Read the guide[2], then you can actually build a web app. I've spent the most time with Elm. Other people might have different experiences. [1]: a few years since I tried, might be better now. [2]: https://guide.elm-lang.org/ https://guide.elm-lang.org/