So, I'm just beginning to dip my toe into functional programming and trying to figure out if and when this approach has real-world benefits. But I'm constantly surprised by the emphasis that articles like this put onto the advantage of having types as one of the reasons for making the paradigm shift to functional. If someone from the Rails world asked me how to get the benefits of a type system in server-side web app code, I would say why not just move over to C#/ASP.NET or any other procedural language that has strong typing built in. That alone is not enough to justify the learning curve, not to mention the business risk of adopting an 'experimental' technology (decades old, yes, but still relatively untested for ordinary enterprisey web applications) and thus have a much smaller talent pool when it comes to hiring.<p>I get that people coming from Ruby/JS/Python world will go "woo, types!" but you don't need to go functional to get that; I wish more of these articles would explain why the nuances of functional type systems, and other benefits of the functional approach, lead to concrete advantages when it comes to building real systems that do useful work.
> ... Java’s anemic type system (which forced complex class hierarchies where, in dynamic languages ...<p>It just occured to me that relationship between Java and more expressive languages that do more, parallels relationship between microservices architecture and monoliths.<p>Because in Java it's hard to make smart classes that do everything you need, you need to create whole ecosystem of dumb classes that only through their interaction are capable of doing what you need. But the language has no tools to deal with interactions between classes. For monitoring them and reshaping them just as there's no tooling in microservices architecture to deal with complexities of inter-service interactions.<p>So in theory you have nice isolated units that should be easy to change and swap. But you just pushed the complexities of your problem to in-between of your units where they are no longer well visible and very hard to manage and evolve.
I know that this isn't quite rails on ocaml (or, to be pedantic, ocaml on rails), but spring boot brings type safety and a lot of the joy of rails together.
The metaphor comparing Ruby to poetry and OCaml to prose feels backwards to me. It is typed languages that have you choose some kind of rhythm, commit to it, and follow it. Once you've committed to it, breaking the rhythm productively is difficult. It is done at your own peril, it can send the whole edifice climbing down, and it often leaves the reader dissatisfied. Untyped languages are comparatively free-form (free verse?).<p>I would like to see a typed-FP Phoenix for a typed-FP equivalent to Elixir: a language that builds on an existing platform with a great focus on the UX and the tooling. Perhaps Reason could become that language, or something derived from Haskell. (Although Haskell's Elixir would be in a difficult situation. It would need to compile faster than Haskell to have a really good UX.) Then again, maybe that language would build on top of a less obvious choice for FP aficionados, like Go.<p>Right now the Rails-like web framework with a focus on type safety I find the most promising exists in a multiparadigm language and isn't devoted to FP. It is Lucky for Crystal.
On a related note, Stripe may open source their ruby type checker at some point, sorbet: <a href="https://sorbet.run" rel="nofollow">https://sorbet.run</a><p>If you are interested you can email sorbet@stripe.com (it's been almost a year with no releases though).
I think Ur/Web is interesting to mention related to this.<p><a href="http://www.impredicative.com/ur/" rel="nofollow">http://www.impredicative.com/ur/</a>
What about Ocsigen and Eliom?<p><a href="http://ocsigen.org/home/intro.html" rel="nofollow">http://ocsigen.org/home/intro.html</a>