In my experience the main benefit of functional programming is function purity. I am completely fine with mutation inside of a function since the all of the mutation logic is self-contained in a single small block of text.

I think everyone should take a shot at writing a non-trivial functional program to see the benefit. Once you understand what makes it great, you can apply what you've learned to the majority of OOP/impure languages.

Flix has "regions", which are a way to allow mutation locally while keeping the language purely functional otherwise: See Region-based Local Mutation in https://flix.dev/

Does Rust not meet that description?

> I wish there was a mainstream, high performance language that made both styles equally ergonomic.

Unironically, C++.

So, one way to understand a monad is that it's essentially a container type with "map" and "flatten" operations. Let's say your monad is type M<T>. The "map" operation allows you to take a function T->U and a container M<T>, and transform each element, giving you a container M<U>.

"Flatten" takes a container of type M<M<T>> and returns a container of type M<T>. So a List<List<Int>> becomes a List<Int>.

Now comes the trick: combine "map" and "flatten" to get "flatMap". So if you have a M<T> and a function T->M<U>, you use "map" to get an M<M<U>> and "flatten" to get an M<U>.

So why is this useful? Well, it lets you run computations which return all their values wrapped in weird "container" types. For example, if "M" is "Promise", then you can take a Promise<T> and an async function T->Promise<U>, and use flatMap to get a Promise<U>.

M could also be "Result", which gets you Rust-style error handling, or "Optional", which allows you to represent computations that might fail at each step (like in languages that support things like "value?.a?.b?.c"), or a list (which gets you a language where each function returns many different possible results, so basically Python list comprehensions), or a whole bunch of other things.

So: Monads are basically any kind of weird container that supports "flatMap", and they allow you to support a whole family of things that look like "Promise<T>" and async functions, all using the same framework.

Should you need to know this in most production code? Probably not! But if you're trying to implement something fancy that "works a bit like promises, or a bit like Python comprehensions, or maybe a bit like Rust error handling", then "weird containers with flatMap" is a very powerful starting point.

(Actual monads technically need a bit more than just flatMap, including the ability to turn a basic T into a Promise<T>, and a bunch of consistency rules.)

> But for the life of me, no forum post or FP tutorial that I could find explained monads in clear language. I've googled "what is a monad" once a year, only to get the vague idea that you need monads to handle IO.

Another phrase to search for is "railway oriented programming"[0], which technically describes a monad called a Kleisli[1]. Still, there are many introductions in a lot of languages based on the term above.

HTH

EDIT:

Something to keep in mind is that the term "monad" identifies a mathematical concept having well-defined behaviors, not a specific construct. So searching for "what is a monad" is akin to searching for "what is a happiness."

0 - https://medium.com/geekculture/better-architecture-with-rail...

1 - https://bartoszmilewski.com/2014/12/23/kleisli-categories/

You've mentioned list comprehensions, map, and filter, so I suppose you mostly used these concepts with lists/arrays.

One question you could ask yourself is, how could you reproduce list comprehensions without special syntax ?

Another way to view monads is by following the types. With map, you can chain pure functions from one type to another to be applied on lists (hence the (in -> out) -> ([in] -> [out]) ) . How would you do that chaining with function from one type to another but wrapped in a list ( (in -> [out]) -> ([in] -> [out]) ) ?

Then you can think about how it could be applied to other types than lists, for example, nullable/option types, result types, async/promise types, and more hairy types that implement state, reading from an environment, etc...

https://tech.nextroll.com/blog/dev/2022/11/11/exploring-mona...

The thing that always makes FP concepts click for me is seeing them explained in a language that isn't Haskell or similar.

I don't know why people are so obsessed with using Haskell for tutorials. Its syntax is a nightmare for newcomers and you can do FP in so many other languages.

https://www.bi6.us/CO/N/20250330.HTML#/033002

I felt similar with lenses. The problem lens solve is horrible. You don’t even want that problem.

FP can be the pragmatic as well. You’re going to glue up monad transformers, use lenses like there’s no runtime cost, and compute whatever you need in days but at least you know it works. Maybe there’s accidentally quadratic behavior in lifting or lenses but that’s by design. The goal is to just throw software at things as fast as possible as correctly as possible.

As a Scala/FP newbie, i was stuck in this rut for years then i just stopped caring. it actually doesnt matter to me much. ZIO helped due to the eschewing of mathematical terms (compared to things like Cats ). In other words, you don't really need to know to get things done. Monads are incredibly intuitive once you start composing them.

Monads are just monoids in the category of endofunctors.

/s

Monads are, in my head, just a wrapper around a type. Or a box another type is inside. For example we can have an Int and we can put the Int in a box like Maybe<Int>.

Imagine Python code that gets a value from a function that is an Int or None, then another function that takes an Int and returns an Int or None, then another function that takes an Int and returns an Int or None. How hellish is that to handle? If not None, if not none, if not none, ad nauseam...

In Haskell I could use a Traverse function that takes a monad and passes the Int value to the next function or handles the None error, avoiding all the boilerplate.

Other Monads are like the State monad - a box that contains some variables I want to maintain over functions.

Or an IO monad to handle network calls / file calls.

It's probably not a perfect analogy, but I work with functional languages and it tends to hold up for my beginner/intermediate level.