At my work it's pretty OO, with FP used where convenient. People join and start reading/writing Scala with zero experience or training, and it works out OK.
At Stripe, I understand their Scala is pure FP, with the first onboarding docs discussing "What is a Monad". I assume they need more training for people who don't have a pure-FP background, but if it works for them who am I to judge.
My own personal style is somewhere in between, certainly more FP than at my work, but nowhere near as FP as those who are really into it.
I think that's where a lot of flames towards Scala from some hard-core FP programmers came from: trying to use Scala as a pure FP language, but having to grapple constantly with the quirks of the underlying OO desugaring.
But I do think your example of typeclasses is a great one. It's a good example of an FP concept (typeclasses thought of as logical constraints to a type variable) desugaring into an OO one (additional implicit arguments).
Regardless, scala3 will make that conversation so much simpler http://dotty.epfl.ch/docs/reference/contextual/type-classes....
True enough that implicitness is not an OO concept in and of itself (I think that was the operative word you're focusing on), but I do think it's the first thing that comes to mind if you're thinking in an OO manner. (Ugh... I keep needing to thread this parameter around... oh I know I could just use this DI library to implicitly insert this parameter for me!)
I would dispute the former means Haskell is getting OO features (more the case that it's finally realized that having proper records a la Purescript or Elm is pretty important for day-to-day code; records and objects are quite different beasts) and Go getting generics is Go getting functional (or OO features, I don't find Go particularly OO to begin with).
> Really, every language is converging on Scala
I think this is more symptomatic of Scala trying to do so much to begin with, such that any change any language makes can be tied to some feature Scala has.
That being said, I'm really happy to see Scala 3 reining in a lot of those choices (except a new parallel set of whitespace-based syntax... that seemed like a gratuitous cost to one's novelty budget, but time will tell; the community already seems to be warming to it).
To those starting out with Scala, lihaoyi's book is a great place to begin!
I'll offer one piece of advice (to those beginners, not lihaoyi, who I'm sure needs none of my advice). These days when I talk to people about Scala who've never used it before, I don't like talking about it as a hybrid FP/OO language.
I prefer to describe it as an OO language with a lot of syntax sugar and standard library choices to enable emulation of FP on top when desired. It is useful to think of Scala the base language, i.e. what everything desugars to, as an OO language.
This is neither good, nor bad. However, I think this realization helps illuminate a lot of strategies around coding in Scala. If your having performance issues, drop down to the desugared OO layer and you'll probably find ways to squeeze out more performance. If you're having a hard time understanding how some of the FP constructs work, step through their desugared OO equivalents (e.g. there aren't really higher-order functions, just an automatic instantiation of FunctionN classes wrapping methods at call sites).
Scala 3 has smoothed out a lot of the mismatch so that its most obvious issues are gone (monomorphic functions vs polymorphic methods, weird eta expansion issues, weird subtyping requirements for implicit prioritization, etc.), but I've still found treating OO as the core of Scala to be a general rule of thumb which is useful for new Scala programmers when they come across something they think should work but doesn't. As you work more and more in Scala and that conversion of FP to OO primitives becomes extremely fluid and natural for you, a lot of choices and quirks that Scala has become far easier to explain and a lot easier to deal with.