I understand that some would agree with you. After all, there are some people who like Scala and not just for its "Kotlin subset". But can you understand why many organizations would think this is the wrong tradeoff? I, for one, do not like using stuff I don't understand, and I am unwilling to put in the time to understand Scala's types, especially because it's so easy to do without them. If I need Haskell-level type safety for some subset of a project, I would use Frege or another Haskell implementation for the JVM that is certain to come along. For the rest, I'm perfectly happy with Kotlin-level type safety, and for those portions of the project (over 98% for sure) I don't have to put up with a class library I don't understand.
> I am unwilling to put in the time to understand Scala's types, especially because it's so easy to do without them. If I need Haskell-level type safety for some subset of a project, I would use Frege or another Haskell implementation for the JVM that is certain to come along.
Learning Scala's type system takes time, yes; it quite possibly takes longer to learn Scala than most languages. But it's still going to be less effort than learning two different languages.
I think that most organizations are already using a lot of code that they don't understand. The JVM itself is many thousands of lines of not especially clear code; I suspect very few java-based organizations really understand it (and I've hit bugs in the JVM in real life, so it's not that there's no need to understand it). Likewise large, popular Java libraries like Spring and Hibernate (particularly given that they do bytecode manipulation, so you can't always even assume that the normal rules of the language apply).
I think standard library implementations are rarely read in any language, so the complexity of the standard library implementation in scala isn't a concern. I think the interfaces are important, and if users are unable to understand the method signatures then that's a problem. But documenting what a method does is often seen as adequate (e.g. in Python or Ruby the documentation is the only interface signature you get), so I don't see a fundamental problem with the "simplified signature in the documentation" approach (though it would be better to have some way of automatedly ensuring these were correct).
(The only alternative would be to give up the power entirely, or to have two distinct collection libraries; neither of those seems like a good answer. If you don't see having Haskell-level language power as an advantage, then yes the complex library interface is not worth it and you'd be better with a less powerful language. But if you see value in writing parts of your system in something like Haskell, I think it's a big win to be able to use the same language for the haskell-like parts and the kotlin-like parts, and learning a complex library is less overhead than learning a second language).
> I think it's a big win to be able to use the same language for the haskell-like parts and the kotlin-like parts, and learning a complex library is less overhead than learning a second language.
I think not, and here's why: we're talking about large organizations here, right? Because if you're a single developer or a small team, then anything from assembly to VisualBasic goes and it all pretty much boils down to personal preference. But in a large team (say 50 people and up), only one or two would need to master the "Haskell part" (assuming there was a real need for one), and the rest would use Kotlin. So there is no overhead in learning two languages. The developers would learn one simple language that they can understand, and the single star developer (there is usually one in any team) could probably master five different languages if the need arises. Throwing everything in a single powerful-yet-very-complex does not fit with how complex software is actually developed. This is one of the reasons many huge organizations abandoned C++ and flocked to Java pretty much on the day it was released (I'm exaggerating, but in a software-timeframe terms that's pretty much what happened).
So you're unwilling to use a library you don't understand the internals of, but you wouldn't mind if part of your project was written in an entire language you didn't know?
The worst company I worked for was the one where the dev team was split into three - the frontend guys working in PHP, the backend guys doing mapreduce stuff, and the middle team in Java. No-one understood what the others were doing, so there was no sense of the overall product, and bugs or features would get thrown over the wall to another team and then come back weeks later, by which time everyone had forgotten about them.
My last job worked in Scala, and had what was essentially a transactional framework using monads. I reckon at most three of the developers there actually understood the transaction library, and probably only two would actually have added new features to it. But everyone was able to write code that used it, and being able to see the code in the repository and their IDE, at least some of the other developers were able to pick it up gradually, from the outside in, learning more and more, starting to fix bugs that were similar to problems they'd seem elsewhere, and eventually reaching a full understanding. If that code had been written in a different language I think they would never have taken the first step.
> So you're unwilling to use a library you don't understand the internals of, but you wouldn't mind if part of your project was written in an entire language you didn't know?
Of course (as long as those responsible for maintaining that portion understand their libraries)! Since we agree that some parts of the code are specialized and reserved for experts anyway, what difference does it make if it's written in a different language?
This is not like your story at all about PHP, Java and mapreduce. In my scenario, everyone is using the same language except for the "expert portion", which comprises maybe 2% of the code. I think it is far better than having everyone use a complex language which they don't fully understand, just so that the experts working on that 2% will be nominally using the same language (I say nominally, because in the Scala case it would hardly be the same language – only the same compiler). I don't want to pay the complexity price for everyone for the power needed only for the 2%.
