There are a lot of tutorials around monads and monad topics using Haskell because... Haskell is one of the few languages which uses monads in a principled and explicit way.
Haskell introduced monads as a way of solving certain problems Haskell had. So if you want to use Haskell effectively, you have to learn about monads. Monads are useful in Haskell.
But that doesn't mean they are as useful in every language. So other languages don't NEED tutorials on monads as much as Haskell does. This isn't because those other languages are worse (less "principled" or "explicit") than Haskell. It's because they aren't structured to make it important to have tutorials on monads. Instead you worry about whatever the specific issues are for those other languages.
Expanding on the other replies, monads are not useful in most languages because most languages are not powerful enough to use them. The syntax is too heavy, because you need lots of function closures. The type system is too weak, because using monadic values without higher-kinded types is much more difficult and less useful.
The fact that everybody tries to import monadic values into their languages is evidence that they would indeed be useful; the fact that such libraries are always useless in practice and incapable of even transliterating the Haskell, and often fail to even implement the full feature set of monadic values in Haskell even if you're willing to type reams of code, is why you don't use them in other languages.
You don't ignore monads in non-Haskell languages because the other languages are too powerful to need them, hurr hurr Haskell is teh weaks... you ignore monads in other languages because those languages are too weak to usefully implement them. If they could, you'd see them, and I am very, very confident over the next 10 years you're going to see more and more languages coming out that really have and really use monadic values, because they will be strong enough to do so, and once you have that, the value proposition is just too good to ignore. They are too darned useful to ignore.
> The fact that everybody tries to import monadic values into their languages is evidence that they would indeed be useful...
Could you give a bit more detail here? From where I sit, I certainly don't see people trying to import monadic values into the languages I use, and I don't see much evidence that they'd be useful. (I've been trying to get my mind around monads and when and how to use them, and one of the problems I have in learning them is that, as far as I can tell, they don't look like the solution to any problem I've ever actually had.)
"From where I sit, I certainly don't see people trying to import monadic values into the languages I use, and I don't see much evidence that they'd be useful."
By importing them, I mean by writing articles like this, which invariably produces code with such an overhead to use it that nobody ever would.
They don't appear to solve any problems partially because you're already "in" a monad; program execution flow is already a monadic value itself. They partially don't appear to solve any problems because you can't really "think" in them, because, as I mentioned, most languages are simply too weak to make them convenient enough to use. And they partially don't appear to solve any problem because the samples used by all the "tutorials" are all pretty trivial; it's sort of like dismissing Object Orientation because obviously it's only useful for modeling relationships between shapes, animals, and cars or something, since that's all anybody ever talks about.
The reason you don't discern the presence of any problem is that you happily purr along as an effective 'human compiler' in a language with a [relatively] lower level of abstraction. You cannot detect that you're actually doing compilation from higher-level constructs because those higher-level concepts have not been formed in your mind (and you haven't been exposed to languages which capture those concepts more precisely/succinctly). It's quite likely, in fact, that your [manual] compilation process is not consistent or repeatable and you end up with a lower fidelity translation (i.e., with lots of noise interspersed) than a truly mechanistic compiler would.
I probably should have said this in my previous comment (the GP), but I mainly work in embedded systems. I need to be able to reason about the low-level behavior of the system more than I need better high-level abstractions.
And getting to write large amounts of my system inside monads (because of lots of mutable state)... that doesn't look like a solution to me. It looks more like a problem.
Are there high-level abstractions that would simplify my view of this? Probably. Would getting those abstractions to behave as needed on the low level be a net win, or a net loss? My money is on the "net loss" side.
That's a bet I would take any day and I think you probably don't need the low level access you think you do. It's largely due to historical architectural decisions that people think so.
Atom is a Haskell DSL for designing hard real-time embedded software. At Eaton, we use it for automotive control systems. Based on guarded atomic actions, and similar to software transactional memory, Atom enables highly concurrent programming without the need for mutex locking. In addition, Atom performs compile-time task scheduling and generates code with deterministic execution time and constant memory use, simplifying the process of timing verification and memory consumption in hard realtime applications. Without mutex locking and run-time task scheduling, Atom can eliminate the need and overhead of RTOSs for many embedded applications.
"""
Yeah yeah, they are all strong independent languages that don't need no monads. What do I care.
EDIT: you don't strictly need something like monad transformers, though. In general, monads are just another type class. A special one since IO is implemented with them, but other than that, they are not essential.
