[runT1ME]

>I was on a team building good old crud apps using monads, monoids, categories

Here's the thing, if you look at a basic Spring crud app, you are also using Monads, Monoids, Categories, Traverse, etc. but you aren't expressing it in the type system. Seriously go look at modern Spring's flux stuff, it's all there minus the type classes.

I've seen teams that tried to over engineer Spring, teams that tried to over engineer Node applications, and yes there are teams that over engineer Functional style Scala.

All the teams I worked with (and managed) at Verizon leaned pretty heavily into FP style Scala without much over engineering and the experience was extremely pleasant. The only production issues in my three years there I remember were performance related, finding out how to get more throughput or lower latency out of FP Scala. I literally can't remember any 'bugs' that made it to production.

[wtetzner]

Yeah, I'd say that Spring is the Java equivalent of the same problem (over-engineering), just using reflection and runtime bytecode generation instead.

I agree that using Monads, Monoids, etc. isn't necessarily indicative of over engineering in itself. If used well they can make the code clearer/simpler.

[yw3410]

Verizon's Scala projects are very cool - I wish that they got more limelight and documentation/support.

[dominotw]

> Seriously go look at modern Spring's flux stuff, it's all there minus the type classes.

I don't use spring or plan to use it. Not quite sure why it needs to be looked up. What are you trying to say?

[runT1ME]

I'm postulating that any modern CRUD app framework has Monads, Monoids, and other categorically inspired structure, even if they don't call it that or have a way to abstract over it.

[dragonwriter]

If it isn't called that and doesn't have a way to abstract over it, there's a very good chance that many of the logical Monads/Applicatives/Monoids/etc. are subtly not implemented as those things, resulting in equally subtle bugs.