6 ms·
I'm currently developing a web app with a Haskell backend and a ReasonML (OCaml with a different syntax) frontend. I'd been interested in ReasonML for a while a
by thinkpad20 8y ago
I'm currently developing a web app with a Haskell backend and a ReasonML (OCaml with a different syntax) frontend. I'd been interested in ReasonML for a while and so far it's been a great experience, but overall I wouldn't say I prefer it to Haskell. I've been using Haskell for many years and so the simplicity advantage isn't there for me. I also miss strongly some of the major Haskell conveniences like generic programming, type class derivation, higher kinded types, and yes Monads. I'm not a huge fan of the OCaml record system as it frequently gets confused and requires type annotations. In fact I've generally found OCaml to be substantially worse at type inference than Haskell, requiring frequent type annotations and cluttering up the code. Haskell's learning curve is steeper, but it is simpler in some ways, especially once you're familiar.
I think where ReasonML/OCaml wins hands-down is its compiler. Bucklescript (and I've heard similar things about other compilers, but can't vouch for it) is lightning quick, and the community has gone leaps and bounds to make it super easy to bootstrap (including with create-react-app). GHC can do amazing things but it's not the fastest out there, and the compiler for the JS backend is abysmally slow. The code Bucklescript produces is very high quality and performant. The library ecosystem is reasonably strong and I expect (but haven't done much testing) that because of the strictness and relative simplicity of the language, library code would tend to be pretty performant and easy to use. I've never found myself in OCaml wondering what string type I should use, or attempting to parse some absurdly complex type hierarchy in a library.
I think for a frontend project, to most programmers I would recommend ReasonML. For one thing, I think even most without experience with FP would find ReasonML to be a giant improvement over Flow (which infuriates me as a type checker), and it doesn't take a ton of time to learn. ReasonReact is a pretty sweet library and I prefer it to React even setting aside language choice. Compared to Haskell, its strictness means it doesn't require a special runtime, generate slow/impenetrable code, or hog tons of resources -- all things that are issues in frontend Haskell. For those who really want to use Haskell on the frontend I'd recommend PureScript instead (also you get the bonus of a kickass record system).
For backend, I think OCaml will get you up and running sooner, but in the long run you're going to find yourself missing the type system and language features Haskell has. GHC's speed on the backend is tolerable (especially if you use nix), and I think Haskell is competitive in performance to OCaml (perhaps better with optimization). Most importantly, I think Haskell is second to none when it comes to correct implementations of business types and logic, creating powerful and reliable abstractions, and eliminating boilerplate, and I think that forms a greater advantage in backend code.
EDIT: this turned into quite the essay...
- platz 8y agoPureScript is my favorite/preferred frontend language right now; I just wish it had a few more folks to round out the userbase's numbers.
- fxfan 8y agoWhat else have you used can I ask?
- platz 8y agoHonestly, I tend to avoid compile to js langs, so not much other than typescript. I would like to try bucklescript and F#'s Fable. Not interested in scala.js or clojurescript just because I'm not invested. Elm is too locked down and inexpressive. Reasonml just seems superfluous.
- thinkpad20 8y agoI did one small pedagogical project in PureScript. As a language, I really like it; in fact I'd prefer it to Haskell in many ways. The compiler experience is good, if not great. Compile times are a lot slower than Bucklescript but a lot faster than ghcjs. Performance is definitely worse, but for many apps I think it'd be fine (and you can always FFI out...). There is a webpack loader for it, although I've had some issues trying it. I've found the syntax to be quite confusing though, even coming from a Haskell background. Parser messages are vague and tracking down the bug can be very frustrating. Also not supporting things like trailing commas is lame (but the same in Haskell). Type errors are also often difficult to understand (even compared to Haskell). I think overall it needs more development, in particular in regards to UX and integrating into a modern development workflow. I'm excited to see its progress :)
- platz 8y agoAgree with everything you said, compile times and perf and tooling in PS is not great. I guess I just value safety and expressiveness more than the other things. For some reason, I really do not care about slow compile time; it just doesn't bug me, but I admit it is slow. I think GHC conditioned me to just roll with obscure error messages, haha - learning some rust and the detail put into error messages honestly surprised me (of course the type system is not as flexible in many ways too, though, so of course the errors will be more concrete).