Just pitched using rescript at my company and was shot down

,
1

Sorry for the new anonymous account, just want to make sure this doesn’t bubble up to anyone I know.

I work at a company with around 30 react developers and my small team manages the architecture for our website.

We hit around 100k lines of typescript and everything started to break. VSCode couldn’t keep up and the TS server would crash.

So we decided to split things up into a mono repo to ease the burden on TypeScript. It’s much better, but we spend a lot of time maintaining the monorepo configs and ts configs to keep it all running smoothly. We also run eslint which is another layer of complexity.

Our website can build (babel and webpack) even if ts types fail and there are eslint errors. This leads to a bad DX loop of building a feature and then hammering on a PR until those pesky TS and eslint errors go away.

These all are issues that go away with a compiled language. The DX when working with a compiler is much better than trying to satisfy PR checks for things that don’t stop you from seeing the new feature locally or on QA.

I’ve been watching reason and rescript for years, and they help solve this problem. We have a small project coming up that uses React and I wrote a lengthy document proposing rescript for this project. It’s small and isolated, probably under 1k lines of code, and it felt like a good place to try out something new.

I’m not interested in trying something just for the sake of new and shiny, but the TS ecosystem is so bloated and slow. It has real issues and it doesn’t have a great feedback loop. I want a compiler to yell at me before I even see results on the screen. I don’t want types to be an after thought. I don’t want handling errors to be an after thought. I want it there up front.

Anyway, I thought I was offering a good solution to a real issue, and it was dismissed rather quickly. Just to be clear I’m an engineering manager and architect, not just some random dev pitching a crazy idea. I had a few thousand words In a doc that included a business impact, a backout plan, and the pros and cons. I have 3 repos set up using typescript and a handful of devs on my team have opened PRs and tried it locally and expressed in interest in continuing to work with it.

I’ve spent probably almost 100 hours on ReScript between personal tike and business time exploring the tech and documenting why it should be considered, and it was shot down in less than 10 minutes. I don’t think anyone considered the arguments or looked at the docs I created. It wasn’t seriously considered. It was just dismissed because “it’s not typescript” and “learning new things would slow down velocity” .

I tried, but the status quo won again today. I’ll keep evangelizing, and maybe someday TypeScript won’t be the default answer to everything.

Not really looking for anything here, just wanted to share with a hopefully sympathetic audience.

11 Likes
2

Not trying to dissuade you from ReScript. But I maintain my company’s monorepo, from yarn to bazel/pnpm and have generally good grasp of the minefield that is JavaScript tooling.

We’ve never experienced any slowdown in our VSCode regarding TypeScript. I think there must be something else that goes wrong in your monorepo. We have way more than 100k lines of TypeScript.

But yes, TypeScript’s ecosystem is slow. You can tweak it to make it acceptable though.

2 Likes
3

So I love typescript and have used it for a long time. 99% I have no issue with it.

But one of my packages uses aws-sdk and zod and I swear my editor just gives up on me sometimes lol. I think it depends on the libraries you use, some of them do some wild meta programming within the type system, and I think that hogs the TS compiler down

One of the pros of rescript I like is how straight forward the type system is

4 Likes
4

I see, interesting. That could be true.

5

Switching to a monorepo was a huge improvement, but it’s still not as fast as other options.

We also use zod and it can take a few seconds on a good day for intellisense to start up for a file.

1 Like
6

I probably jumped the gun with my initial post. I had a few people approach me to discuss it further and ask some follow up questions.

The initial reaction was “he’ll no, we aren’t changing anything and adopting new tech”, but I did get some actual meaningful conversations over the past few days.

We’ll continue to get more feedback and bring it back up with leadership again in a couple months.

So maybe the lesson is don’t give up and expect the first reaction to adopting new tech to he overly pessimistic and close minded, but that doesn’t mean the conversation is done.

8 Likes
7

Glad it worked out for you, but consistency also pays. You present your solution, they shoot it down, next time whenever there are any pains of continuing you can point out that there are better systematic solutions so the problem they are facing.

2 Likes
8

I’m in a somewhat similar boat. I’ve been slowly sowing the seeds with developers on different teams about the benefits of ReScript and how it solves some of our overhead dealing with TypeScript and how we have to use eslint rules to encourage people not to do things to weaken our trust in the types.

We also use fp-ts and encourage people to use Option instead of null or undefined, but null related errors still pop up in production on occasion.

The speed is also a very nice benefit, and I’m a fan of a language with a compiler that blocks you from shipping code that has type issues or eslint errors.

Good luck moving forward, and i hope it works out for you!

5 Likes
9

I think it’s partly due to a couple of factors.

First, there has been a lot of churn in the AltJS languages ecosystem in the past decade or so, and people are kind of burned out over it. From the early days of CoffeeScript, to ClojureScript, PureScript, then the fall of Elm, and some people even remember ReasonML and don’t want to take a chance on ReScript because of their perception that ‘they changed it for no reason’. And of course there was also Flow which TypeScript beat over a long period of time (mostly by being shipped by default with VSCode).

Second point derives from the first. People just want stability. Most devs actually don’t want to throw away their existing hard-earned skillsets and have to start from scratch with a new technology. Managers want that happening to devs even less so.

There is an inflection point at which the cost of learning the new technology is offset by the benefits from the greater productivity, developer velocity, and maintainability of the new tech. And I get that you are trying to make the case that ReScript can bring that inflection point closer. But without the innate desire among a large number of the devs to adopt this new tech, you won’t make that case.

But I would still keep doing what you’re doing, maybe just at a smaller scale. Maybe try it out with a teammate if you ever do a hackathon. Maybe try to deploy it in an internal app or a helper script that demonstrates the power of the compiler and type system. It doesn’t even need to go into ‘production’, just be around and be usable for some small task.

Btw, I am talking to people in general, not specifically giving you advice. I know you don’t need it.

5 Likes
10

In my case, I was a member of newly building team, adopting ReasonML at the time and moving to ReScript later. So I can only imagine how difficult your endeavor is. I’ve been using ML-like languages for about three years now, and the advantages of ReScript as an AltJS language over TypeScript are clear to me.

  1. Fearless refactoring and development efficiency
    The biggest difference with languages that don’t have a sound type system is that even if we get a PR that changes a few thousand lines of code, if the compiler builds it successfully, we can trust that our team will be safe at runtime. The benefits of this are obvious. It saves time in code reviews, allows us to focus on business logic, and speeds up the delivery of our product.

  2. The learning curve isn’t as high as you expect
    During team building, I helped onboard about 30 developers who had no experience with ML-like languages or ReScript. I was worried about the learning curve of ReScript, but in reality, they had no trouble writing code on a React project in about a week. I had more trouble leading React, Relay, and GraphQL.

The irony is that in order to feel the benefits of ReScript, a project needs to reach a certain size, and it’s hard to build a project of that size with ReScript in the first place. This seems to be the deadlock.

We’re all afraid of change, and it’s natural to be intimidated by the prospect of starting a new language and technology stack, even for small projects. I think it’s only possible in organizations that are building new teams, or in companies that already use ML-like languages, or in organizations that understand sound type systems.

Good luck!

11 Likes
11

I’d like to add my notes: There’s an interesting way you get to experience development efficiency - Refactoring in ReScript is often adding one more case to a switch or adding a function which you can add to a pipe-line. The beauty with this way is that your existing code does not need to change, as long as you’ve got the basic function right - the job of the component and the functions you are defining.

For example, last week my colleague was blown away by how we just needed to change a Recoil atom to a Recoil selector for a page component (that we did not modify in any way) and things just worked. The equivalent change in the old JS (angular.js) implementation involved modifying how the data was being loaded and modifying the page component itself.

But the irony holds true - your project needs to reach a certain size to see the advantages or ReScript. For us, it was when we hit around 20K LOC of ReScript, we started to experience that huge refactors due to design or logic changes were just not a pain compared to our old codebase. It was as if the compiler was guiding you around the codebase, enabling you focus on what the new logic should be, and not worry about your application crashing because you missed some changes somewhere or because the structure of the data became inconsistent due to changes.

7 Likes