> It affects the language very much, awkward currying and tupling, needing to wrap methods in objects.

That is a lot less true since Scala 3.

> Subtyping also has many complex consequences.

Sure. But it also means I can use any library from the Java ecosystem, and that's a huge reason behind the big number of Scala jobs compared to other FP languages.

> There is limited type inference and tail call optimisation versus functional-first languages.

Limited type inference is typically what I (and my team) want, for the sake of self-documentation. Scala's type inference is plenty enough, and the few corner cases that were annoying in Scala 2 should be fixed in Scala 3.

Tail-call optimization is done the compiler. The lack of tail-call elimination is bothering the few maintainers of functional libraries that need to implement CPS and trampolines, but not really something the average developer will have to worry about. And it should come to the JVM with Loom, eventually.

> F# has units of measure

Scala offers more generic ways to do the same thing. Would F# need such a feature at the language-level if it had typeclasses?

> OCaml has polymorphic variants

I believe most people don't want structural typing in their GADTs.

> It was not designed as a functional programming language first and foremost, that is my point.

I don't think Martin Odersky would agree. It's not an either/or situation. Scala was designed to be a full-fledged functional language, and OO hybrid, compatible with (and leveraging) the Java OO model, and offering a strong type system that goes beyond what you find in most FP languages.

> awkward currying

Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.

> Subtyping also has many complex consequences

But also substantial benefits!

> There is limited type inference

I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.

> tail call optimisation

This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).

> F# has units of measure

I dearly miss those. Type Providers even more so.

> OCaml has polymorphic variants

Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.

> It was not designed as a functional programming language first and foremost

This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.

More languages are becoming more and more like Scala, btw.

https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...

And the concept of a programming language paradigm is fake from the start anyway ;)

https://www.cambridgeblog.org/2017/05/what-if-anything-is-a-...

I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.

I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route.

I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!

> Scala is to Haskell what F# is to Ocaml

That's not quite precise, IMHO.

F# is an awesome language that I hold very dear, but it is a castrated form of OCaml. It has only a few features that OCaml doesn't have. For example Type Providers or Unit of Measurement. These are nice and useful features, they're not gimmicks, but they're not fundamental.

On the other hand, Scala isn't a hollowed out Haskell. Haskell, admittedly, is a more powerful language and has features Scala doesn't, like a linear type system. And it's just different, non-strict, whereas Scala is strict. But Scala is also very powerful in other fundamental areas, where Haskell is weak. Scala has a superior module system, it's biggest strength IMO. Haskell's modularity story is that great AFAIK.

I remember perusing a book on ML (the language) and having aha moments such as "so this is where the '_' naming convention comes from" and "this is where pattern matching was borrowed from". Monads (aka zio/cats) are not built-in, the "lazy" keyword is a far cry from strictly lazy evaluation. I say "Scala to Ocaml" on the JVM is equivalent to "F# to Ocaml" in the .NET world (there must be some category theory joke in this topology).