- It is mature and rock-solid, but still manages to evolve, fix issues and simplify/remove features. Most other languages are purely additive, meaning you will have to carry on all the baggage since the languages' inception.

- It is a language which is interested in identifying the best way to solve common programming issues and spares you with all this ideological "OOP/FP is bad" bullshit.

- It has the largest ecosystem (plus it can use all of Java's, too).

- It has the best tooling.

- It has the largest community.

- It has some great learning resources, like the three (or four?) Coursera courses starting in a few weeks.

- Its JavaScript backend is stable and production-ready, Scala-Native is being worked on.

> That said, I come from a C++ and Python background, so do I need to know Java well before learning Scala?

Java knowledge might reduce the amount of learning (as many Java things like the JVM also apply to Scala), but isn't really necessary. You will be fine.

This comes at a steep price, as HM-inferable typesystems are very limited, and most languages have in fact a typesystem that might be based on what HM can infer, but have extensions that require type annotations.

In the end Scala's requirement to annotate input parameters is not a big deal, as this only enforces what Haskell/Ocaml/... consider to be best practice anyway.

It's a huge deal. I always write type signatures once I know what they are, but a lot of the time I get the compiler to infer them for me which saves significant headaches.

Yeah, build tools are usually terrible. Being "good enough" is enough for SBT to beat the other ones though.

(Best incremental compilation, fast artifact resolution, reliable dependency management, versioning support, fastest to-Android compilation, broadest plugin support, interactive REPL and project console ...)

I feel like turning Scala into a cross-platform language is the best idea possible. I'd love to see Scala someday be able to just dump out WebAssembly, or JVM bytecode, or LLVM IR, or whatever the next "hip" format is, while keeping the language the same.

I also find it shocking how hard people are pushing Typescript when Scala.js exists. Why would you ever subject yourself to TS?!?!

"The generated JavaScript is both fast and small, starting from 45kB gzipped for a full application." - 45kB... jQuery is ~80kB.

If you want to do practical things with the language, by all means count the bindings as an asset. It's still better to have a foreign-library binding to some capability than no capability at all, and it's not hard to imagine that using another language for some reason, even with the cost of the foreign-idiom binding, is still net cost/benefit positive.

Haskell's big pluses are purity and rigor. Most functions can't affect external state; they can only return results. Haskell also has strict typing, which is great for catching mistakes up front, and takes most of the pain out of using it through really great type inference. Unfortunately the community around Haskell is very small, so if you use it for a project larger than one person you could run into hiring problems.

I wrote some more about the pluses and minuses of Haskell here: http://short-sharp.blogspot.ca/2016/06/should-you-use-haskel...

Scala's big advantage is that it works well with legacy code in Java. Unfortunately it straddles the boundary of OO and FP, and making both programming models work requires a large and complicated language. I'd prefer something simpler.

If we were to take another swing at FP, I'd look hard at Scheme and in particular at the Racket system. The big plus of Scheme is a certain elegance, which is very appealing. And lots of people have learned Scheme in school.

Consider Kotlin: https://kotlinlang.org/docs/reference/comparison-to-scala.ht...

Mssql, Cassandra, CSV, and MySQL

MySQL and CSV were no problem. The Cassandra bindings were bitrotted and I had to do a good amount of work fixing the Cassandra dependency and the thrift dependency it has. Mssql bindings through hs-odbc have an allocation error I haven't had the time or energy to figure out.

If I were using Haskell in production and not having mssql was a showstopper, I'd need to take the time to fix this library to with fix my immediate case and then continue maintaining it.

I found that Haskell Library support seems to be stronger in the technically Superior Technologies Department. For instance postgres support is quite a bit better than MySQL support.

It makes total sense that the Haskell Community would put more work into supporting technically Superior Solutions using their technically Superior language, but I fear that's biting off more than you can chew.

At home for instance I've been struggling with Linux issues rather than putting time into my side project. It would probably be a better economic choice to buy something with more seamless Hardware support like a Mac, and then be bleeding edge with my side project using Haskell.

Point being, if every part of your life is bleeding edge you'll just end up bloody and never going anywhere.

However the main use of OCaml is in the higher-level utilities, for example virt-v2v (https://github.com/libguestfs/libguestfs/tree/master/v2v) and virt-builder (https://github.com/libguestfs/libguestfs/tree/master/builder) are substantial OCaml programs.

So yes, while you can use Java libraries you often have to jump through a lot of hoops.

Maybe I'm missing your point but as a professional Scala programmer I've never run into a problem with Jvm or Java integration

It's more a point against the "strictly better than Java, use the bits you want as you you go" point in the article. You have to understand Scala's execution model and make sure you are mixing the paradigms properly, because it's fully of leaky abstractions.

If you come from an OO background, I recommend to avoid using Scala's functional features at the start. Just treat Scala as a nice, conventional OO language until you are comfortable with the language. Then, slowly use some of the more advanced features. Case classes and pattern matching are easy and powerful next steps.

Enjoy the ride!

I'd say not knowing Java the language isn't a big deal. Also not a big deal, but certainly a point to consider, is Java the ecosystem. I can imagine Java pros bringing their knowledge regarding the JVM, threads, and other stuff, that's certainly a plus.

Since you have experience with a statically typed language, you'll be fine with little no to Java knowledge.

That, at least to me, is way more interesting/important than libraries, which can always be ported or otherwise interfaced with.