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
Super-fast compiler
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.)
Module system again: no need for annoying âwall of importsâ at the top of every file, just immediately use the modules you want in any file in your project. For better structuring try the guidelines here https://dev.to/yawaramin/a-modular-ocaml-project-structure-1ikd
Actual deprecation and tail-call annotations for code so you can evolve a codebase over time, and warn if a recursive algorithm is incorrectly implemented
BuckleScript compiler actually does constant folding for you, i.e. it just optimizes away anything it can evaluate at compile time. Code output tends to be smaller
EDIT: another important warning:
Warn on unused values. Very important for keeping a codebase neat and tidy 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.
Yeah. Itâs even possible that its JS-like syntax is doing Reason a bit of a disservice because some people expect it to work just like Javascript, whereas a significant portion of OCaml semantics is quite different (and also, I like the look of hd::tl better ).
Yeah, I really agree with the syntax similarity doing Reason a disservice. It really threw me off in the beginning. I was trying to do things the JavaScript way, but needless to say I had very little success
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?
Module system
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:
TSâs story is still a bit like: âadd types to your javascriptâ
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.
).
