I worked on a Scala system with two rookie Scala programmers who had been taught that `for` expressions were a simple and easy way of composing futures, because

I worked on a Scala system with two rookie Scala programmers who had been taught that `for` expressions were a simple and easy way of composing futures, because it was the monadic way. The code looked very neat, but we had an epidemic of swallowed Failures, and the ones that weren't swallowed were often interpreted incorrectly. (For example, a 500 from service A would be logged as a 500 from service B, because someone miscalculated how the Futures and Trys were being composed.) This was due to people not understanding the for expressions they were writing. Rather, I seemed to be the only one trying to understand the `for` expressions: I often had to mentally (or even manually) translate them into flatmaps and maps according to the language spec to discover that they were not doing what the person who wrote them intended. The other programmers, who had been promised that `for` expressions were obvious and self-explanatory, felt that this should be unnecessary, and that if they were making mistakes, then Scala was failing to live up to its billing, and we should stop using it. It was extremely frustrating. I love Scala, and I feel that promoting `for` expressions to beginners like that was ideologically motivated and bad for the language. It's much easier to just use map and flatMap. But that won't do, because the virtue of monads is supposedly the abstractions built on top of them.