Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I understand not everyone will agree, but I find this to be a deficiency of ReasonML compared to strict TS.

Types offer inline documentation to developers that come after you. They should make it easier to establish and maintain a mental model.

Obviously, this requires buy-in from all parties, but if the tool itself doesn't encourage buy-in, it is a bug, not a feature.



One problem with people selling ReasonML's type inference is that it's not depicting the actual developer experience.

The first thing to note is that you do interact with types to build a mental model! The editor will show them to you as you move your cursor around the code. It will do that for every single value. Just move the cursor over that `requestContext` argument and voilà, it'll show you the type.

Another important aspect is that you still have to define types. Have a person object with a bunch of fields? You do have to type annotate every single field. Have multiple actions to handle in reducers? You need to tell ReasonML in advance what those are using a variant type.

And finally, if you care about composition/abstraction you should provide interfaces for modules. This requires writing types for all functions explicitly to ensure that you are exposing a correct protocol. This is optional, but it helps both the author of the code and the consumers.

Type-inference is just a nice to have feature for the low-level implementation details.


Nothing stops you using type annotations in ML, and good developers will do so where it is useful. But it doesn't require them in cases where they are redundant, for instance when you have a parameter `foo` of type `Foo`.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: