Not something big enough to overrule other arguments, but the old fashion imperative java as in "mutate stuff in your local scope as if there's no tomorrow" is

Not something big enough to overrule other arguments, but the old fashion imperative java as in "mutate stuff in your local scope as if there's no tomorrow" is much nicer to consume in a debugger than the declarative "describe what you want and let the compiler figure out that it fits together or not once and for all" style that kotlin pushes even more than modern java. You certainly don't need the debugger as much for trivial mishaps that are simply not possible in the new style, but if something isn't working at all it's much harder to get your bearings with a quick step-through than in imperative. Of course it's just as possible to go all-imperative in kotlin as it is in java (even scala would allow it), but it's just painful to see an elaborate step by step block full of possible bug hiding places where a simple val...filter...map... expression could provide a clear description of the result. That being said, my mind still hasn't adjusted at all to thinking about names before thinking about types, guess that's very much to expect after a decade of naming 95% of variables "class name, but lowercase". (PS: I actually maintain the fantasy that there might be room for a language that abandoned the entire idea of local variable names and just referred to e.g. parameters as "the {type} parameter", pushing typical cases of more than one instance of a certain type sharing a scope into the type system)