Table of Contents Hide
Tooling in Reason is kept as basic and simplistic as possible. This is done by Merlin – Reason’s solution to editor integration that provides awesome support for type information, auto-completion, and general linting. When working with Merlin, you’ll require a
Verdict: Quick and straight to the point. Tools get out of your way and let you focus on what’s more important – actually writing code. However the lack of alternatives to choose from could also prove to be detrimental sometimes.
Ecosystem and documentation
- Frontend development
- Command line interface (CLI) applications
- Desktop (GUI) applications
- Mobile applications
- Backend development
Verdict: It’s got a robust and vibrant community where you can get all the resources you need.
ReasonML’s ecosystem is still young but growing. Most of the information gotten on it is derived from OCaml due to the fact that it is written in that language. Reason’s two forefront libraries right now are BuckleScript and ReasonReact – a library that leverages the features of Reason and combines them with React.
Although over 50% of Facebook Messenger is written in Reason, there’s still much work to be done. The Reason team just released version 3.2.0 which includes features like whitespace tuning, semicolon relaxation, and Unicode string printing. Other sources of information on the Reason ecosystem include:
- Reason’s community page points to chat rooms, Twitter accounts, etc.
- Awesome ReasonML is a page with Reason resources.
Reason’s documentation is well written and concise, so is OCaml’s, which complements Reason’s documentation.
Verdict: Still young thus it’s ideal for small and medium sized projects. Companies that want to migrate a large codebase might need to “wait it out” for a while.
Pros of static typing
- Earlier detection of programming mistakes – you’re more likely to prevent adding an integer to a boolean when working with static typing.
- One can refactor with greater confidence since a large class of errors introduced during refactoring will end up as type errors. Let’s say you’ve got a function that currently returns a single number, and wish to modify it to return a list of numbers. In a static language, updating the declared type signature and fixing any compile errors will catch most, if not all places that need updating.
- Using static types can ease the mental burden of writing programs, by automatically tracking information that you would otherwise have to track mentally in some fashion. Let’s say you’re writing a tricky function, and have two values in scope,
xyou pulled out of a dictionary, the
ywas the result of calling
foo(23). Is it safe to call
x(y)? Types provide an automated, precise answer to this question.
- Performance-wise, it’s easier to efficiently execute programs that are statically typed. Dynamic languages executed naively will have much more dynamic dispatch and runtime checks happening. And while it’s possible to execute dynamic languages efficiently, it’s more complicated.
Cons of static typing
- Types require some investment up front to become fluent in thus static typing takes time to learn.
- It is an additional layer of complexity. You are basically writing the code again, on a different level.
- Some tasks, especially around generic programming, can be very easily expressed in a dynamic language but require more machinery in a static language. For instance, a generic serialization library can be written in a dynamic language, without anything fancy, but providing the same thing in a static language requires more machinery (an example is Haskell’s generics support), and is sometimes more complicated to use.