4 ms·

I've used all three, and at least in my opinion, Scala is the most production ready by miles. Clojure is great if you like dynamic typing...by far the best dyn

I've used all three, and at least in my opinion, Scala is the most production ready by miles. Clojure is great if you like dynamic typing...by far the best dynamically typed functional language out there. Beware of claims that clojurescript and clojure are the same language. While both are dynamically typed, clojure's type discipline is strongly enforced (type errors will throw exceptions) while clojurescript will fail silently. I personally know of a team that experienced a million dollar bug because of this subtle distinction...you absolutely have to be prepared for it if you plan on using both. If you like gradual typing, there are some great options. Haskell is good but the language's strictness (especially around effects) is very demanding. This can be both a good thing and a bad thing. In my experience/opinion, it's a good thing in some use cases and a bad thing in other use cases...but there's no way to opt out of it when it's a bad thing. Further, the ecosystem is far less useful than the jvm ecosystem. Scala definitely has its faults, but its type system is extremely expressive without being extremely restrictive. I've never felt restricted by it (like I did with Haskell), but it regularly blows me away how easy it is to refactor and fix errors. The Java interop is far more intuitive than Clojure. Drawbacks: The only really useable IDE is Intellij. Some libraries tend to form an ecosystem of dependencies which don't play well with other ecosystems (ie some libraries are "Scalaz-only", some are "Cats-only", etc), which can be really annoying at times. Java interop isn't extremely straightforward in the case of collections (if that is a big concern, go with Kotlin which is phenomenal).

didibus 8y ago
ClojureScript is strongly typed. I'm curious to know the specific case they ran into? I suspect it might have been interop with JavaScript, because you shouldn't have weak types in ClojureScript.
- darksaints 8y ago
  No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11". The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously been json numbers. Since there was no exception produced, it silently corrupted data for a couple weeks before it was caught.
  - didibus 8y ago
    Woa, you're right. I had never realized they were compiler warnings and not JS errors. Thanks for the tip.
  - ajss 8y ago
    People were running a real money service that consumed JSON from another service and it didn't validate the incoming JSON? Wow.
    - saosebastiao 8y ago
      The problem comes from the fact that clojure and clojurescript are two different type disciplines, but people approach them with the same expectations. That exact problem would have errored out if they were running clojure, and a thrown exception is good enough validation for many developers. But because they were duped into a false safety net by thinking clojure == clojurescript, it slipped right underneath their radar.
  - didibus 8y ago
    I asked about this here: https://clojureverse.org/t/clojurescript-is-weakly-typed/3117 https://clojureverse.org/t/clojurescript-is-weakly-typed/311... And documented to what extent types are automatically coerced. Also got the rational behind this: performance. And that every new release of the compiler performs smarter and smarter type inference and can warn about more of these cases. Though it still misses some as of now.

didibus 8y ago

ClojureScript is strongly typed. I'm curious to know the specific case they ran into? I suspect it might have been interop with JavaScript, because you shouldn't have weak types in ClojureScript.

darksaints 8y ago
No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11". The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously been json numbers. Since there was no exception produced, it silently corrupted data for a couple weeks before it was caught.
- didibus 8y ago
  Woa, you're right. I had never realized they were compiler warnings and not JS errors. Thanks for the tip.
- ajss 8y ago
  People were running a real money service that consumed JSON from another service and it didn't validate the incoming JSON? Wow.
  - saosebastiao 8y ago
    The problem comes from the fact that clojure and clojurescript are two different type disciplines, but people approach them with the same expectations. That exact problem would have errored out if they were running clojure, and a thrown exception is good enough validation for many developers. But because they were duped into a false safety net by thinking clojure == clojurescript, it slipped right underneath their radar.
- didibus 8y ago
  I asked about this here: https://clojureverse.org/t/clojurescript-is-weakly-typed/3117 https://clojureverse.org/t/clojurescript-is-weakly-typed/311... And documented to what extent types are automatically coerced. Also got the rational behind this: performance. And that every new release of the compiler performs smarter and smarter type inference and can warn about more of these cases. Though it still misses some as of now.