Yeah, I was also excited about Scala. Went to a conference in 2010; eventually took the Odersky course and tried it for some personal projects. I ended up abandoning it, and for me Bruce Eckels captured a big part of why, talking about it as a "landscape of cliffs". [1] Every time I thought I knew what was going on, I tripped over something and ended up in a chasm. With much study and effort I could dig myself out of that hole, but soon enough I'd be in another one, trying to understand some abstruse bit of type magic when I just wanted to render a web page or something.

It also reminds me of the famous Kernighan quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [2] Scala might be optimal for some group of people, but definitely not for me, and I think not for a mainstream developer audience either.

[1] https://www.bruceeckel.com/2015/08/29/what-i-do/

[2] https://en.wikiquote.org/wiki/Brian_Kernighan

I must say this comment reminded me of LISP and the many criticisms put against it. Perceived as overly flexible ("custom architectural patterns") with snobbish people ("colleagues will not allow to"). But at the same time many people will find LISP (or Scala) their "superpower" that allows them to perform really well.

no one flavor of scala will ever be a standard. you have to adopt coding styles and stick to them. once you get to the point where you have a pattern and you’re just coding-by-number scala isn’t the problem anymore

I was asked to join a team of scala developers. Most except one had started learning about 6 months earlier. I was asked to learn it while making small contributions to the project. I quickly found out that there were statements that could be interpreted in multiple ways, can't remember now what it was. Then I got stuck on something and even our seasoned very enthusiastic Scala developer could not solve it. I then and there decided not to pursue learning the language and quickly have myself transferred to another team. It's a difficult language, one should not spend thinking on the language but spend time thinking about the problem itself. Probably what I say is not doing justice to Scala as I was just a newbie but I did not have those problems with Clojure which is another not that mainstream language.

And that's the whole problem with Scala. When you work with it, you are having a battle with types and compiler more often than you should. Funny but it is not the first typed language I had to write code in. Never did I have to do so much unnecessary dancing around and asking senior colleagues for help. I guess not all of us are capable of grasping such expressiveness at the cost of such complexity. The majority just need simpler tools to be productive.

That's what led to ZIO.

Going full FP in Scala with Scalaz and "tagless final" (I still have no clear idea what's that) and whatever else that's hip, leads to madness. Sure you can write maximally polymorphic code. Great. But you end up doing the extractions/refactors that the type system and the compiler allows, not those that would help the code the most. Because those are too slow (too much boxing and GC churn), or the compiler has a bug (or the library) so you end up putting a TODO comment in the code with a link to a github issue.

Or it's a feature that's not supported by Scala, so you end up with a FP spaghetti. :(

IMO, it really depends on the team you join, as with most programming projects. Scala can be used in a classic mutable OOP manner, as if you were writing Java in 2005, or if you heavily buy into pure FB libraries it can be used basically like it's Haskell, but IMO neither of these approaches embrace the strengths of the language. It's meant to be a true mix of OOP and functional paradigms, not going extreme one way or the other. The object oriented aspects let you embrace great OOP software architecture patterns like Domain Driven Design, so that you can really model the business domain clearly and faithfully. Then the functional aspects allow you to implement a "functional core, imperative shell" style, that's really easy to reason about, and easy to make concurrent (safely), while also having excellent/safe/descriptive types like Future/Option/Try and ADTs.

It sounds like you've worked with a group of people who want to treat Scala like it's Haskell, but that's a minority community that IMO isn't really embracing the strengths of the language. I've worked on projects that go all-in on libs like Cats and Scalaz, and I agree that they're mostly unnecessary complexity that also obscure the modelling of the business domain. You're going to massively confuse newcomers with all the Applicative/Effect/Monad/Monoid/Functor/etc. talk, for next to no benefit. Actors are a bit of a different story - excellent for the 1% of times where you really need them (lots of mutable state and lots of concurrency), but 99% of the time you don't need them. Some devs are enamoured with the mathematical purity of pure functional programming, without properly considering how hard it is to understand for most other devs. If you let these types take over your company, that’s a cultural problem, not really a language problem.

Odersky describes why he created the language here: https://www.signifytechnology.com/blog/2018/01/why-scala

> ... programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges.

I completely agree, and have yet to find a better language than Scala for the above demands, assuming you really embrace the OOP/functional mix. I've been writing lots of Scala at my day job for the past ~5 years, and it's my favourite language. I've worked on backends in Scala, Java, Go, Python, PHP and Node, and prefer Scala to all of them.

I also agree with Li Haoyi - it's becoming a really solid, stable, reliable language, with improvements focused on the build tools, compiler, and the odd language wart, without significant changes to syntax/style, which is great. It does take awhile to learn, and you do have to be careful about what style you program in, but I think if you just embrace the language's OOP/functional fix, and for "core style" mostly stick with the standard library (Future/Try/Option/etc.) vs. going crazy with Cats/Scalaz/Akka/etc. (unless you REALLY need Akka specifically), it's an outstanding language.

What types of projects you have been working on?

Exactly my experience too.

It's hard not to fall in love with Scala in the first months you start using it but downright impossible to like the language after that.

Kotlin has won my heart. So far, anyway.