ReScript critique article

I found it interesting to read this feedback from a newcomers perspective:


He’s hitting a compiler bug in section talking about error messages.
(probably issue with crlf on windows which is fixed on latest).

I don’t like his idea about truthy values (i don’t know how much time i spent debugging issues with implicit coercion, especially with boolean expresions).

The ffi part might be valid tho. I actually like the current ffi we got. as you use it more often, it gets more natural but I hear from others that they expect a cleaner/easier way to import js code. hopefully this will improve.

These kinda feedbacks would be help the folks in core team to find what areas to focus on and it brings some ideas to the table. Thanks for sharing Yawar!


While ReScript is still a work in progress i would hardly consider the error messages a deal breaker compared to the pain of coding in TypeScript vs ReScript. Since they considered ReScript yet another JS alternative it would have been nice to see a comparison from their perspective with PureScript, Elm, Fable (F#), etc.

Interestingly the author had another article on unit testing and they were using a simple function to add two integers as an example. It was quite humorous to see the excessive amount of code needed simply to validate whether the function was being passed two integers where ReScript correctly infers the types and you’re done. Incidentally TypeScript gives and error that the parameters have an implicit any type and requires you to actually supply the integer types because it can’t infer the types.

I’m glad ReScript came on the scene and I only expect it to improve–particularly since the developers are highly interested in making a ReScript a language where people can write understandable code that is highly productive as opposed to exercises in who can write the most impressively unreadable “functional” code. :clown_face:


the error message is a bug on windows which is already fixed and released


Being a ReScript newcomer, myself, I have to disagree with almost everything mentioned in this article:

  • truthy values: hell no. Implicit conversions are never a good idea
  • pipes: pipes show their true potential in deeply nested function calls (say f(g(h(x))) vs x → h → g → f). The example in the article is grossly oversimplified. Although I have to admit I don’t like → very much - I’d have preferred the Unix, F# or Elm variants ( | or |> ).
  • const vs let: apart from the fact that let has been around for ages in precursors to rescript and therefore is hardly new, he neglects to mention that let is also used for function definitions. Or does he propose using another keyword (like function) for that?
  • pattern matching as a (poor) replacement for OOP features: as someone who has used OO languages (C++, Java, Ruby, …) extensively, I find this statement ridiculous. OOP and FP simply use different approaches to the same problem - in OO systems, adding new classes is easy (since ideally, you don’t have to change any existing code) and adding new functions is hard (because you have to adapt your whole class hierarchy), while in FP systems, adding new functions is easy (you don’t have to change any existing code) and adding new types is hard (because you have to adapt every single switch statement, but a good compiler will tell you exactly what’s still missing)

Regarding JS interop: I can’t really comment on that. My first impression is that it’s easier than in Elm.

Some things that might be worth improving:

  • I found it quite confusing that unlike in ReasonML, the syntax for Arrays and Lists isn’t [|…|] and […], but […] and {…}. Seems unfortunate (esp. since what used to be lists are now arrays), but I guess that’s water under the bridge now
  • the online “playground” isn’t really a playground - granted, I can check whether my script actually compiles, but I cannot run it

But apart from that, I’m quite happy with what I’ve seen so far - the compiler error messages are almost as good as Elm’s (which to me, is the gold standard), and most things seem pretty straightforward.


I believe there were good reasons for this change, namely first-classing arrays and kind of discouraging linked lists. Because arrays make much more sense when you target JS.


That’s true - I hadn’t considered that arrays are a more natural fit when you target JS.