Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.

All of those require being familiar with the functional paradigm, or a data type conversion. And vice versa.

Sure, for code that doesn't interact, or that does only through an interface not defined by the language (i.e., through the OS, through sockets, whatever), the issues in style don't exist, and Scala kinda makes sense as a "single language that tries to be all things to all people". But on a shared codebase, with a 'team style', per the OP, that allows people to use what they're most familiar with...mixing paradigms is going to cause problems, and will force each dev to learn each paradigm in use.

Please note I'm not saying there's no benefit to mixing paradigms, or that a language that includes multiple paradigms is bad, but rather that by allowing more paradigms the codebase you increase the breadth of knowledge necessary to work on that codebase, such that letting people stay in their comfortable, single paradigm bubble is impossible, at least if you want them directly interacting with the code written by someone else in a different paradigm.

And an ST monad makes no sense unless you're interacting with imperative code (obviously, hence your bringing it up), which means you already understand what imperative is, and are still having to convert your immutable structure to a mutable one, for the imperative code to operate on, and to recognize it will be modified in place; to use the ST monad the functional programmer already has to understand imperative programming.

It also seems like it would fail to encapsulate the side effects an imperative function may have, since that function is able to interact with state elsewhere, that isn't actually encapsulated. I.e., the ST monad makes sense when dropping into update-in-place for performance reasons, but when there are side effects that are not ensconced within the monad (remember, the function you're calling was written by an imperative programmer, in a language that allows side effects outside of a monad; not Haskell), the ST monad does nothing to make it functional, and oh crap, now your functional programmer has the same problems as an imperative programmer, in having to figure out WTF this function just changed in some other imperative chunk of code, in some other process or object or whatever.

So given imperative and functional paradigms, even using the ST monad, if the functional code is to call the imperative, and the imperative is to call the functional, both the functional and the imperative developers have to understand the other paradigm, -and- deal with the considerations of both. You've upped the complexity of your system considerably.

The ST monad also does exactly restrict the scale of effect of mutability which can occur. It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region.

If you want, you can write a program where everything lives inside of a giant ST monad layer. You always do this if you replace ST with IO, in fact. Each bit which can be made purely functional will be embedded into this monad and, for sake of sanity and testing, those functional bits ought to grow and grow.

But it doesn't really demean the IO/ST segment. An imperative programmer can live happily there without much trouble at all.

I wasn't saying you couldn't set boundaries; you have them implicitly simply by dint of the fact that in Scala, mutable/immutable is based on the type, and the type system is enough to enforce that. But now you have a performance penalty being introduced based on who works on a given part of the code, and one that can easily compound.

"It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region."

But for the imperative programmer to know what not to do he/she has to understand functional coding, and choose to eschew certain techniques that might be viewed as acceptable from a purely imperative perspective.

Please note, I didn't say you -can't- do it. Just that it's asking for trouble, and that either you have to understand both paradigms or you suffer a performance penalty (converting from mutable to immutable and vice versa). And that if you ever want to touch someone else's code you have to be familiar with the paradigm. Not proficient, but enough to realize what you have to do to be able to interact with it properly/safely, that that requires a broader depth of knowledge on the part of each team member than if you picked one paradigm, and that leaving them to know only their paradigm will not work. The imperative person has to figure out higher order functions, working with immutable data structures, etc, to make use of some of the stuff the functional guy has written, and the functional guy has to be comfortable with destructive updates, side effects, etc, to be able to make use of what the imperative guy has written. Yes, they both can interface with the other, but what they have to know is much broader, and every time they interact you risk bugs and performance penalties that you'd not have if you picked one paradigm alone.

It's a good solution in Haskell though.