What are some good arguments to use when pitching ReasonML contra Typescript? ReasonML is a lot more elegant, variants are much cleaner than disjoint unions. However this is not really enough to convince someone to pick a much smaller ecosystem. Features like GADTs and polymorphic variants are really handy if you understand them but if someone is new to the language, why would he/she care?
How should I go about convincing a team to use Reason instead of Typescript if they are evaluating those two options?
But here are a few more bullet points (comparative to TypeScript):
Type system with soundness guarantee
Powerful module system with all sorts of benefits, e.g. opaque types (i.e. newtypes), functors enabling higher-kinded types, enforced modularity especially with non-recursive modules by default (i.e. module A can’t refer to anything in module B if B refers to anything in A. This might sound annoying initially but is actually a godsend for maintaining a comprehensible codebase over time.)
Inference and ergonomics is the primary selling point for me. 100% soundness with a fraction of the annotations TS forces you to write is a big thing imo. Also, it feels like the language is much smaller and more restricted, which I think is a good thing.
But I also think it’s important to be clear about Reason being quite different to TS/JS, especially if your team consists of JS developers with little or no experience with other languages like Reason. I’ve had bad experiences with people expecting “just a bit stricter TS” when in fact the difference is quite large.
But for the type of developer who appreciates and sees great value in type safety, a compiler that does not let you ship bugs, and the ergonomics of a language, ReasonML is just plain awesome. To me it just makes so much sense and the positives outweigh the negatives by far.
The great thing about ReasonML is that you can write straight OCaml syntax code in any Reason project if you want. E.g. bucklescript-tea provides a very Elm-like developer experience, thanks in part to the DSL-like OCaml syntax for creating virtual DOM nodes.
Well, it probably wasn’t that bad for me, since I’ve read a bit of Real World OCaml and did some exercises at Excersism before starting with Reason syntax. And anyway, whichever way you learn that difference, when you did learn it, Reason is plain great
I have too little experience yet to tell wether switching between OCaml syntax and Reason syntax in the same project is too much cognitive overhead. Besides, even for modules without any ffi, I’m beginning to like Reason syntax for the autoformatting. I find OCaml autoformatting too dense: in comparison, autoformatted Elm has much more air.
As for TEA, what’s your sense of TEA in OCaml? What I mean is, Elm is the purest functional language I know where effects are declared by reducers and implemented by the framework. By contrast, OCaml is able to set state and dispatch actions imperatively, just as it was done in React since before Reason. Do we need TEA?
I find that people can get used to any syntax after a while. Syntax doesn’t really matter. Providing a syntax choice is mainly done to onboard people as gently as possible.
Yes Or at least, the people who are using it in production need it. To my mind it very effectively demonstrates that OCaml/BuckleScript is fully a superset of Elm. Regarding effects, it doesn’t really matter too much. We are moving towards a pure-in-impure approach nowadays in a lot of languages, even in libs like React with hooks. It’s always better to have that brute power and not need it, than to need it and not have it.
The TEA (and other dataflow styles) is to remove imperative hard-to-follow code paths, it makes everything reasonable and simple to follow, which makes maintenance significantly easier than things like (non-functional) react.
These are some questions i ask myself, with some side notes for each:
Can you afford/be bothered with the time cost of writing bindings?
TS has come a long way in terms of authors shipping declarations with their JS, and the DefinitelyTyped repo.
I rarely need to write TS bindings/declarations.
Reason is getting better though, so if you’re starting a new project after some time why not see its progress? https://redex.github.io/
Can you sacrifice some of the IDE experience to use Reason? TS wins here imo
Caveat with TS though: It can be painfully slow at times in a very large project, especially a multi project monorepo. It’s getting better though.
How willing and able to use reason is your team?
What matters most (imo) is the productivity and happiness of your team. Its one thing for them to not be open to new ideas, but it’s another to reject their perception after they’ve honestly evaluated it.
How scalable and maintainable do you need your project to be?
Use reason if this is high, for a number of reasons which other people in this thread i think have answered.
Key points for me?
Type system soundness and awesomeness
Super fast compiler
High quality ecosystem (vs high quantity in JS+TS case)
Another thing around scalability for me:
If you can afford to convert a JS library to TS or reason, do it. A JS project that has separately maintained TS or Reason bindings is good in the short term but not good in the long run.
This also contributes back to the community if thats your flavour
Some other reasons to choose reason over TS:
albeit it has come a long way.
The point here is that there is still a massive disconnect between JS, build systems, and types. Take for example babel macros and webpack loaders. Each cause very non-trivial differences to the logic and types of your code. TS has no mechanism of knowing about them. I guess you have the same issue in Reason + Babel + Webpack, however you can write a PPX, and the community is making more of them.
For us a big part was that we were constantly running in to compile-speed issues using TypeScript. If you’re having similar issues, that was a big part of getting people to agree on giving Reason a try.
TypeScript’s m(any) “escape-hatches” and need for explicitness was definitely also a factor.
Pattern matching, variants and other language-specific goodies also play a big part of course, but features aren’t always as helpful as arguments like speed.