Functional language developers are obsessed with side effects but I rarely ever see problems with it in real code. Like I can remember once in maybe 10 years setting a developer write a "get" method that also wrote to a file. Caught during code review, rewritten easily.

While, sure, get methods writing files could happen in side-effectful code, the side-effect concern is less about that and more of expectations. With OOP languages, class methods can create a dichotomy of expected returns: Using a list reversal as an example, will a list.reverse(some_list) function reverse the list in-place, or return a copy of the reversed list and leave the original in-tact? To know the answer, you have to check the docs or the type signature (which, yes, is easy, but the answer isn't obvious). Which, the main concern is trying to debug things "magically changing", since nested function calls and inherited function calls can modify something from layers upon layers of abstraction away.

FP languages tend to not have this dichotomy, with very few exceptions like IO in Haskell, ports in Elm and Gren, external functions in Gleam, or FFI in Haskell, to name some ways from languages I know, all of which usually move the control of the program outside the language's "default area", anyway. Outside the exceptions, to reverse a list a reverse function needs to be given that list explicitly, and it also will be returning a copy of the list reversed, only and always

Still, Not everybody Formats their Code 💀