Seeing beyond the hammer nail thing is kind of part of growing up as an engineer. I had to figure out monads in the mid nineties as part of my functional programming course work. Lot of fun, not very practical at the time since all the mainstream languages of the day were basically not functional programming languages. The way people explain monads has not improved a lot since there. It still sounds like a bunch of gobblygook.

I usually translate in my head to side-effect thingies. Much easier. So, Maybe<T> is short hand for it could be there, or not, you'd have to check. Same with Result<T>. Or Optional<T>. Or Future<T>. It's nicer than having null as a default value and then triggering a null pointer exception because you forgot to check but a bit less readable if you start wrapping them.

But if you have a language with nullable types, like Kotlin, you can your cake and eat it. For example, you can have functions like isNullOrBlank defined on nullable strings (String?) which don't throw a null pointer exception if you call them on a null value. Just syntactic sugar for the common use case.

Likewise, Kotlin has more syntactic sugar that functional programming types would frown upon that is actually nice to use. Like suspend functions that you can use to write asynchronous programs that almost look like they are normal synchronous ones. With proper support for cancelled co-routines, error handling, threading, reactive programming, etc. Yes, they're colored functions. But, colored functions are nice and easy to work with. My compiler will tell me off when I do it wrong.

Is it all monads under the hood or just a pragmatic language?

I'm not sure you quite said this but nullable isn't just another word for Optional with syntactic sugar. You can have Optional<Optional<Integer>>, but Integer?? is not a thing. This means you can't (or shouldn't?) use it for, say, return value of a generic "get a value from a map" because you might want to be able to store nullable values in the map and probably want to distinguish "it wasn't there" from "it was there but the value was null". IIRC, in some languages with generics and nullable you can't actually write a function that applies ? to a generic argument, because there's no way to say that the generic argument isn't itself nullable.

I'm not disagreeing, but this is a very good jumping off point for what is an enormous discussion in the philosophy of programming right now. You've identified the correspondence between the programming language support and relevant monadic constructions. There's also the principle that programming is about applying relevant abstractions. The point of contention revolves around the question of "Should monads be available to programmers in the abstract where programmers are supported enough to write their own monads? Or should monads be reified into language constructs, thus making it a up to the language designer to choose the finite set of available monads and syntactify them into language constructs?

A vocal camp wants monads in the abstract and feels like reified monads as language constructs completely misses the point. The other camp is happy to accept new syntax and keywords to get their work done and see monads as ivory tower language enthusiasm. The choices that language designers make increasingly put their languages on one side or another of this dividing line.

I mean, the "curse" part is only being forced to live amongst people naive to this reality: seeing monads for what they are should be a blessing.

You can choose to see this as a curse or an opportunity, a la https://xkcd.com/1053/

This is true of any sufficiently general abstraction. Like a multi graphs and effects systems.

In fact overly general abstractions are an anti pattern in practical software development, at least in my opinion. Any problem can be successfully extrapolated to a more general case, that doesn't mean it's worth doing it.

They do give you a template for approaching certain problems though. Even if your implementation of the template in your head is specific and therefore easier to follow in the implementation. It's useful to have an understanding of them for that reason.

The results of those templates seems to be a lot different from regular old boring industry standard reusable code, which has design patterns(Developed over the years for everyday practicality) as the templates instead of abstract logic(Seemingly chosen for beauty and ability to express original ideas).

They say you can find monads everywhere, but doesn't that mean that by using monads as a starting point, you'll have more freedom and less structure and predictability than if you used a GoF pattern?

As someone who admittedly does not understand what a Monad is, do you have any recommended resources to learn about them?