You can avoid a lot of side-effects with C++'s const specifier. It also has more powerful type system than Java, to the extent of allowing higher kinded types via template construction. I read a bit about that topic but it's still too abstract for me to grasp. At least, Optional has a clear use case and I actually used it a lot in my recent project. I think real world examples of problems that can be elegantly solved with monads (as opposed to any imperative approach) would help a lot. Because I'm not interested in a language feature if I can't understand it without understanding the whole language first. If I decide to learn Haskell I'll learn about monads in the process anyway. I don't think Go fans would switch to C++ just because it has templates or exceptions; rather they'd like to learn how to implement them in Go.
As for Optional's .get() — true, that's an oversight in this class design. I'd prefer to only have .map(), .flatMap(), .isPresent() and .ifPresent() but who am I to judge. At least Sonar has a rule that highlights .get() without prior .isPresent() but I try not to use it at all.
So, yeah, maybe these languages don't support all the pureness of the functional ones, I still believe the core idea can be expressed so that people would find it useful right away. I'd love to see some monad examples aside from Optional and their implementation in a mainstream language. Maybe incomplete (if so, you may describe what exactly the language misses and why this is so important) but at least it would be approachable for regular developers, not category theory graduates.
Oh I fully agree you shouldn't need to know a lot of Haskell or category theory to get a basic understanding of monads. That's basically why I wrote this article with imperative programmers in mind.
I guess that due to the potential for side-effects, even in the standard library, java devs just never really took to monads. Nor would I: if I'm using monads, why would I use java? But I haven't used java in a long time so I'm not the best person to comment on this.
Optional - which is equivalent to Maybe btw - is a bit of an odd one out because it's primarily a useful data representation that happens to be a monad, much like arrays, lists, trees etc.
Well, that's the main problem: if you're using monads, you'd use a language that already supports them natively. That assumes you're already familiar with the language and surely know what monad is and how to use it. See, these concepts from FP are bit too abstract for imperative languages that are far more common. So it's a chicken and egg problem and unfortunately explaining monads in a functional language doesn't help to break this cycle.
I've always seen Haskell as a purely academic language. Not much known software is written in it that I can name right off the bat. Only xmonad perhaps. I don't think it's a coincidence that it's not widely used in solving practical problems. Can't tell anything about Elm, didn't see it. So, why would I want to write my own monad? What exact problem would I solve with it that I can't without? Just a real life example. Everywhere monads are explained on Maybe and yes, I know that Optional is more or less that. But other than that? Java also has streams since 8 and they feel monadic, like you can apply a function on Stream and get Stream in response. That's cool and I don't see why you need a functional language to do that.
Also, this article, despite explaining everything in Haskell again, was pretty informative. It has a lot of pictures without confusing analogies, totally recommend it. Unfortunately, it's yet again about Maybe.
Sounds like you've already got a feel for what's monadic and not :-)
Mind though that streams can only be monadic is they are finite: an infinite stream of infinite streams is a higher-order infinity (∞2) which mathematically cannot be mapped to infinity, so no chance for a flatten function. Neither can you 'follow up' on infinity (andThen or bind), ergo not a monad.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.