[miloignis]

I'm not a huge fan of this post - I feel like it adds to the confusion where it tries to enlighten.

First, a pedantic point - a proper pure functional language will not have "side effects", it will have "effects" (either through algebraic effects or through monads or something) - nothing "side" about them. Side effects are effects that happen in addition to the main value of doing something (this medicine has side effects). Effects are just things that you want to happen in the world, and many functional languages reason about them as first class objects instead of implicit behaviors. That is, a function has an IO effect or returns a value in the IO monad instead of being a C function that can arbitrarily write to the file system.

Second, the main point of the post seems to be that functional programming will not make concurrency happening outside of the language (say, when talking to databases) safe, but that's a pretty simple point that's not stated as clearly as it could be.

Hopefully I'm not being too harsh - I might have misunderstood something, and the core point that functional programming doesn't magically fix everything is true - but it's that very confusion that I think makes this post unhelpful.

[karmakaze]

The post is entirely useless from any technical perspective. It talks about pure FP languages. Then about OCaml and concurrency without much detail or distinction.

The only useful thing it almost says clearly is that FP doesn't have to be magic and can be used effectively by normal folks, but instead flips the title (for clicks) to imply it's not as good as they say.

[chongli]

Thank you. I’ve frequently found myself annoyed when people conflate the terms “effects” and “side effects”.

[cameronfraser]

I like to think of "effects" in this context as "managed effects"