a0

I think I don't mind lack types as much in immutable languages. Clojure and Erlang are like that. But they're also both simple languages with simple semantics.

One issue I have with Clojure is when I have to work with nested datatypes to perform transformations. It's just too hard to keep the shape of that data in your head. Types help with that.

Another important thing is modelling business domains with types. By this I really just mean record and variant types and not some advanced type-fu. It really helps seeing what kind of data your application manages.

> Common reaction from them I receive very often "We never knew that JS/TS can do that"

Maybe it's about what you cannot do in ReasonML, and not about what you can do in TypeScript? :)

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.

ClojureScript is beautiful! If only it had types :)

Being a Vim/Merlin user I normally just type `<Leader>t` to see the type of the value under the cursor (this maps to `:MerlinTypeOf` if I recall correctly).

What I do use type annotations for is debugging. If the compiler finds a type error, in some situations it helps adding type annotations to find where the actual error is.

One place where clean build times do matter is in the CI. Having very fast builds and tests is great for speedy deployments.

This kind of comments make me really sad. Most ReasonML developers are actually "JavaScript developers".

ReasonML was specifically designed for JavaScript developers. Being JavaScript-friendly is in it's DNA really. I even see ReasonML a language that was specifically designed to work with React.

I can understand why you would feel this way though. I think the main problem is that ReasonML introduces new concepts that simply do not exist in JavaScript. Learning those concepts is hard. But if it wasn't hard, would you be learning anything or just writing JavaScript in a slightly different way?

Are there any specific examples of things that look too "distant" from JavaScript?

I'll finish this by saying that ReasonML will make you a better JavaScript developer. As will probably learning any other language that challenges the way you think.

Many interesting points! :)

> Why do people care about this? Writing type annotations is not that much work (...)

I personally care about this when I'm prototyping something. Not having to write types means that I can simply write what's on my mind. The benefit of good type inference is that the compiler can still help me highlight any mistakes I made during this process.

Another benefit is that some production code can get very complex. Having to type every single value is just too cumbersome and distracting. It contributes to boilerplate and increases cognitive load, in my opinion.

> Having really smart type inference makes your compiler slower and more complicated.

I would actually disagree with this. First of all, ReasonML's compiler is absurdly fast. No, seriously try it. Sometimes I go and double check the generated JS code just to be sure it actually did anything.

Regarding the "more complicated" part – the only reason why full type inference works is because it is based on a very solid theoretical foundation. It might be somewhat "complicated", but it will never be as complicated as something ad-hoc that needs to account for all inconsistencies that exist in untyped languages like JavaScript.

Many modern languages support type inference to some degree. The special thing about ReasonML is that the type inference is much more robust and complete.

In practice you don't need to provide any types annotations at all at any point in your program and you should still get the same safety benefits.

Every value in your code will automatically have one single type assigned to it based on how it is being used. When the compiler finds contradictions it will let you know about it. On the other hand, Typescript will try to unify the type to some sort of Any, which is probably not what you want.