What keep you guys using Rescript?

1

Since I don’t work with rescript, it was always a passion for me, something to just imagine working with and spending some time with.

I love reason and rescript, and I hate ts, my mind thinks that we don’t have to type js, just use some lang to compile to it. But since there is not much thing to do I always get into the same problem, trying rescript between a gap of time, when I miss it.

I haven’t seen too many rescript jobs, so I imagine you guys have your motivations to keep on it.

And that’s my question, what keep you guys using Rescript?

3 Likes
2

I just kinda like writing code, more specifically taking something that’s complex and trying to make it easy to read and understand. Rescript’s variants, pattern matching, and pipe give me unique tools that I find pretty fun to use.

5 Likes
3

Well, I’ve been lucky enough to be able to work in a team that uses rescript for a few years, and now I’m starting a new company and I’m using rescript both on the front and on the back. There’s just no other stack that makes me as productive. And it’s not just being productive, it’s fun to use.

14 Likes
4

+1 on being fun to use.

Theres nothing like unpacking a Variant type in a switch statement and having it depict the control flow so clearly and concisely

No nested if statements, null checks, ? chains, try-catch abstraction.

I wrote this switch the other day and it just felt right.

let isSubroute = location.pathname !== "/"

switch (newestAnswer, newestQuestion) {
  | _ if isSubroute =>
    <React.Suspense fallback={<div />}> {children} </React.Suspense>

  | (Some({day}), Some({day: Some(questionDay)})) if day == BigInt.toInt(questionDay) =>
    <SingleVote.Newest vote={newestVote->Option.map(v => v.fragmentRefs)} />

  | _ =>
    <SingleQuestion.Newest
      question={newestQuestion->Option.map(q => q.fragmentRefs)}
    />
}

So many situations handled clearly and effortlessly. I’d say the only pain point in clarity would be unpacking the option

newestQuestion->Option.map(q => q.fragmentRefs)

6 Likes
5

I pulled ReScript into a few of my professional projects.

Why do I keep using it?

To be candid, ReScript isn’t amazing - at least not yet. It has its warts, and what bothers me the most is that it somehow feels castrated. Too much of the imperative paradigm has been ripped out. I want return statements, guard clauses, and so on. That would make ReScript better. I also miss comptime or macros (right now delving into PPXs).

Having said that, it actually is amazing in relative terms. Ocaml feels archaic to me, and ReScript is a fresh take. Rust hits the sweet spot in terms of imperative and functional paradigms, but it has its warts as well which I absolutely do not wish for ReScript to adopt. The closest competitors in the web domain are JavaScript and TypeScript - both horribly broken languages. My journey started back in the mid 90s with asm x86, then C, C++ and so on. TypeScript is a broken attempt to fix a broken language. TypeScript could actually be ok if it had nominal types instead of structural - and if it fixed constness which is just clownery in JS.

I think ReScript has ways to go for it to be a definite go-to like JS/TS has become. But I think JS also opened up the world of programming to many developers - especially those who are brilliantly creative but not super techy. It can get stuff done, but for anything beyond simple UI stuff (if even that), it needs to go in the bin.

3 Likes
6

I quit my job and started as a solo-developer where I had all the power to pick my tech stack. Since then I switch to Reason->ReScript. Sometimes I had some frustrations specially with bindings and so many changes in the API. But the type-safety, FP-first, switch patterns, compiler, and vscode ext make me very productive and able to build complex apps that I wouldn’t be able to with JS. And it keeps getting better and better. Frustrations tend to 0.

3 Likes
7

Github copilot is becoming pretty good at generating bindings to be honest.

4 Likes
8

Because it’s the best DSL for my business logic(mostly simple state machines) so far

2 Likes
9

I used heavily Rescript during 2020-2021 (still in 9.4 :sweat_smile:)
I really enjoyed my time with Rescript, it’ still my favorite language for the web, the interop is best in class.

The problem is that I don’t use React anymore, I use SolidJS, and I can’t write SolidJS code with Rescript :cry: . So I’m waiting for a JSX preserve mode in order to try it out again :slight_smile:

1 Like
10

+1 to fun factor.

I started my journey with ReasonML somewhen at the end of 2018, as a research to replace Typescript. My first language was JavaScript, and generally I like it as a tool to build quick abstraction, but when you read books like “JavaScript: the good parts” or “You don’t know JS” it’s really hard to not see Typescript as anti pattern for JS, or rather huge influence of Java that violently overtook JavaScript way of thinking. Even if advertise as good alternative to JS, even if it’s good to have any type then none… in practice TS is pure mess, the worst you can imagine from JS word with the worst you can imagine from type system, lacking basic syntax for reasonable coding.

Work with TS become increasingly frustrating for me so I started experimenting with other languages like Elm or Purescript. At the same time I started learning Rust for embedded systems, and found a lot similarities with ReasonML. I found Rescript a good alternative to Elm & Purescript because of way easier integration with existing JS ecosystems, and far more practical then Rust (with frameworks like Yew)… and because as mentioned by others it’s just fun to write!
It was huge factor to me as it keeps reminding me I love to write code. I was able to pull Rescript only in a single project and I struggled to keep time with the language. For couple of years besides FE I focused mostly on Rust development, but finally returned to Rescript as together with JS ecosystem is really powerful and versatile (both FE & BE).

As for now I spend couple of hours everyday afterwork to experiment with the language and do some small productivity tools for myself keep trying convincing new clients and hoping it will work out some day :smile:

3 Likes
11

Variants and exhaustive switching. Any language I use that doesn’t have these just seems unfinished.

5 Likes
12

Apart from above, compiler speed is +1 from me.

2 Likes
13

ts and scala both support this.

14

ts variants? You mean the discriminated union hack they bolted on? Its ugly and it doesn’t support exhaustive pattern matching

15

It did support exhaustive pattern match.

16

The native switch case statement is exhaustive?

One of the first libraries I add in every TS project is ts-pattern (GitHub - gvergnaud/ts-pattern: 🎨 The exhaustive Pattern Matching library for TypeScript, with smart type inference.) for adding exhaustive pattern matching.

2 Likes
17

The original tsc does not support exhaustiveness check, but you can use this typescript-eslint rule, it works perfectly in my project.
@typescript-eslint/switch-exhaustiveness-check

18

Tagged unions are not nearly as ergonomic as variants.

I agree you can do exhaustive pattern matching, and the type checker will prevent errors, but the fact that those objects are structurally typed makes them extremely unpleasant to work with on a daily basis (verbose, and type errors are hard to read).

Oftentimes it’s easier to just use less correct boolean or enums before going with tagged unions.

4 Likes
19

Inspired by the comment I’ll add one more point in favor of ReScript: You don’t need a lot of tooling to make your code safe. No more prettier and scary eslint configs.

7 Likes
20

This 100%!

You can get TS to a place where it’s decent to work with. You just need to install ts-pattern, fp-ts, ts-essentials, eslint, and prettier. Then make sure you have all of the settings maxed on in tsconfig.json. Also add rules to prevent people from using @ts-ignore, @ts-expect-error, implicit and explicit any, don’t allow using undefined, add rules for fp-ts to force using it instead of unsafe built ins, and don’t allow anyone to do weird type casting like let t: string = 42 as any as unknown and you will be able to work very, very, very slowly as you write lots of boilerplate and type annotations.

Oh, and all of those ESLint rules and plugins slow down VSCode :slight_smile:

7 Likes