It's not about saving a single return statement, even in the elvis case. How many times have you written code along the lines of "if this isn't null do this, otherwise return. If the result of that isn't null, do this, otherwise return" etc etc.
Elvis ops are a small QoL change, Promises are essential to async
Exceptions (much of the time) are kind of a "catch it pass it on" logic for me, and man do I wish I didn't need to write it every time.
With networking this really shines, or really just anything async etc
You need to be able to "wrap" values and then also "wrap" functions in the way you expect. That's literally it.
Btw, the list monad example is stupid imo and borderline misleading. The promise/nullable/Either examples are better. you "wrap" a function by putting it as the only value in a list, and "map" pretty much acts as your function wrapper, but technically this you need to jump through a couple hoops to make it monadic, and I'm just not sure the metaphor is helpful here
Somehow I hear this all the time, but the haskell people have to realize that code patterns are absolutely a thing in all languages, ever? A lack of syntactic sugar doesn't mean monads don't exist in other languages.
Typeclasses are a distraction, the point is computation ignoring annoying contexty stuff (file not found errors, null on failure, etc) and there's dozens of examples in literally every language ever.
Not all problems are solved with a technical definition.
Like many things in life it is far easier to give examples than it is to describe the thing.
Examples of monads are Promises and Elvis operators (for values that can be nullptrs). In a sense exceptions as well. Having heard this I think if you do a second pass at the type definitions, I think you may be able to parse them out
It really is just "a wrapper for values that sticks around when you do something to the values".
Think of it as a coding pattern, and it's much easier to grok
It's handy for IO because, well, did you see the examples I gave? A monad lets you basically ignore the failure mode/weirdness (the async stuff in the context of promises, null type in the case of Elvis) and worry about the computation you actually want to be doing.
Other places you might apply these would be fileio (file not found? cool, don't care, deal with it later) or networking (as long as the connection's good, do this.)
I mean, you can just... Not annotate something if creating the relevant type is a pain. Static analysis \= type hints, and even then...
Besides, there must be some behavior you expect from this object. You could make a type that reflects this: IntIndexable or something, with an int index method and whatever else you need.
This feels like an extremely weak argument. Just think of it as self-enforcing documentation that also benefits auto-complete; what's not to love? Having an IntIndexable type seems like a great idea in your use case.
If you define quality as "layered and meaty" there are many much better books.
Roadside picnic (and its less Russian counterpart, Annihilation), left hand of darkness, Solaris are all excellent.
If you want culturally influential, surely Starship Troopers, Stranger in a Strange land, anything by HG Wells, 1984/Brave New World, Frankenstein (duh)
The characterization in Hail Mary is just so damn weak, even space opera stuff like Bujold