Sadly while the language itself has excellent OO support and Java interop, the community support just isn't there (by which I mainly mean: too many people like DeGoes will shout you down rather than trying to help you).
My opinion -- and I mostly write Scala in my day job! -- is that Scala is in a truly difficult position. Its OOP (and Java) DNA hurts its FP aspects. If it goes full hardcore FP, it will probably lose relevance (because most programmers can't be bothered with it, and those who can will probably hope for Haskell on the JVM). If it stays like it is and tries to be a "better Java", it will keep losing ground to more practical and "easier" languages on the JVM, possibly including losing to Java itself!
PS: DeGoes didn't sound disrespectful to me, and bear in mind I don't know who he is. He seemed to be arguing out of practicality, not shouting people down. I don't if he is angrier in other forums, but his tone in this presentation sounded closer to a wake up call to me.
Well, to my mind the FP is a means to practical ends. I'm not attached to Scala qua Scala, I'm attached to HKT and typeclasses because there are practical problems I can't solve without them. As long as Scala has those things and Java or Kotlin don't, Scala will have an advantage - and if Java does adopt those things I'd say mission accomplished. (I mean, Odersky's original goal was to improve Java, right?)
That seems more of a strawman than a fiction: I've never seen anyone, especially in the Scala community, suggest this.
I've seen lots of people suggest that OOP+FP fusion is what allows Scala to provide an easy gradual on-ramp to FP for people and projects transitioning from Java, which is Scala’s key value proposition.
I feel like I'm at the tail end of that on-ramp, and while I'm still as a whole really appreciating scala, I'm starting to wonder what the end-game is.
Now that I understand and am comfortable with all the functional stuff, I'm left wondering why I still have the OOP stuff, and why some of the FP stuff isn't more natural. I guess you still need some OOP for java interop, but the pure-scala ecosystem is pretty significant already.
I guess what I'm saying is that the easy transition from Java is only a benefit for bringing people in, not for a language as a mature ecosystem. And I'm thinking maybe I should get into one of the full-FP languages.
In fact, if anything, what's keeping me from making the switch is not any OOP features, but actually just imperative! Especially for performance-sensitive sections, and some rare-but-necessary data structures, it seems you really do want a small amount of mutable state.
The end game back in the early days of Scala was probably to provide a gradual on-ramp to FP for people and projects transitioning from Java, but it probably changed to a commercial purpose once more people got involved in its development. It's long since become a self-preserving product, and probably even tries to hinder people moving from FP-only Scala on to Haskell and the like.
I only spent a few months on Scala way back so don't know for sure, but I did see Apache Groovy go through a similar business re-purposing. It began as a JVM-based scripting language complementing Java, useful for glue code and testing, but later became a competitor to Java and other statically-compiled JVM languages, and even tried unsuccessfully to target Android.
Take it slow, and don't expect to be using every Scala feature/library/pattern from day 1 - there is a lot of depth to functional idioms, the learning curve of something like Haskell has less to do with syntax than you might think. Write code that does things that are useful to you - even if you're only writing "Java without semicolons", you're getting value out of Scala - and adopt the fancier features one step at a time. I've been working in Scala for 8 years and there are still places I'd fear to tread (why do I care if my profunctor has strength?), but every year I've produced more concise, clearer, less buggy code than the year before, and even in year 1 I was doing as good as I had been in Java or Groovy.
It seems to me DeGoes is arguing that Scala's "key value proposition" is a losing battle, because other languages are starting to do it much better. It's likely that the "practical programmer" will go with Kotlin or even the next iterations of Java, and the rest... well, you can guess the reaction of the audience to his question ("how many of you would work with Haskell if you could?"), and I must take his assertion at face value that in Scala conferences, the more popular talks are about FP, not about OOP or even FP+OOP. Maybe he's wrong about this, of course.
Again, I'm saying all this as a Scala practitioner. I'm not leaving it for Kotlin either. Then again, I certainly would work with Haskell if I could!
edit: one more thing:
> "I've seen lots of people suggest that OOP+FP fusion is what allows Scala to provide an easy gradual on-ramp to FP for people and projects transitioning from Java"
In my experience, this ramping up to FP happens in one of two ways with Scala:
- Completely ad hoc, misunderstanding every principle and making a Frankenstein's monster out of it. No lessons learned, just a mess that "works".
- Understanding it and doing it with care, and mentioning Haskell a lot (as these people start to read articles and watch tech talks on FP).
This is entirely my personal experience and probably won't generalize to every workplace.
The core language is very much OO. The functional aspects of Scala are either syntax sugar that desugars to OO stuff (e.g. automatic eta expansion, special syntax for defining FunctionN vs new classes, case syntax for partial functions, context bounds) or decisions made by the standard library (e.g. the prevalence of immutable data structures).
Understanding this has been the key for me to understanding where most of the warts of Scala come from. For example some of the weirdness of functions vs methods, weird performance issues, the existence of some of the encoding tricks that libraries like cats and scalaz use, and strange decisions made in the collection libraries all can be fundamentally traced back to this layering.
That being said you can do a lot of FP in Scala because of the combination of ecosystem and syntax sugar, but you have to always keep in mind that you're encoding FP concepts with OO tools (not as equals) otherwise Scala's limitations will come back to bite you.
Proposition for discussion (i.e., I don't necessarily believe this, but I don't necessarily not either): The biggest challenge facing languages and their communities that focus on correctness is that the very personality types that are willing to focus on them are also statistically much more likely to be, ah, potentially less suited to the sorts of compromises and engineering discussions that are necessary to make a personal language than other more pragmatic communities. The sort of relatively uncompromising spirit necessary to swim upstream against the current general consensus of very pragmatic programming nearly entirely unconcerned with academic-type correctness is, well... uncompromising.
"Community" is largely a toxic concept anyway.
Oh, we have to have a community. Community this, community that. Nice project, but where is your community? I can't write a line of code without a community!
Tired of "community".
Here's a function that is only partial, because it can throw an exception instead of returning a value when b is zero:
def divide(a: Int, b: Int): Int = a / b
Here's a total function to accomplish the same basic goal:
def divide(a: Int, b: Int): Try[Int] = Try(a / b)
This function always returns a value of the type it's declared to return.
I swear, probably 80% of my problems in professional life are from overloaded terms.
;-)
Some partial functions would be disallowed, assuming you aren't including an actual totality check (which would exclude all partial functions and some total ones).
First, he poisons the well by talking about "integrity" and "intellectual honesty". This is a bad move at the beginning of a speech because it is far too easy to take it such that people with different conclusions are lacking in those qualities. Given his delivery, I suspect that he might actually believe that. It would be better if he just owned that this was his opinion and delivered it respectfully.
Second, the section on academic priorities was weak. He spent a large portion of the talk highlighting the mission statements of various languages, which is marketing language. But if Scala made no other changes other than its marketing language, it would not solve the problems he was highlighting. I thought too much time was spent on that part of the talk. There's another moment later in his rushed conclusion where he made stronger points that could have been fleshed out - how the academic influence leads to theoretical features that later get abandoned when the academic project is completed. (And I quite liked his revised marketing statement for Scala.)
I also didn't like that he brought up Cats vs scalaz as a flaw with the community, given that it became clear later in the talk that he had a clear bias on which was preferable. That seemed needlessly provocative.
I think the final conclusion of abandoning the OO path was interesting and fun to think about! I don't know if there's already an opinionated compiler plugin that discourages the more OO techniques while encouraging FP techniques, but I can see how that would be a lot of fun to play with, and educational in the same way that static analysis tools are. (I don't understand why "partial functions" was crossed out as something to abandon, though.)