Gabriel Nordeborn

📢 A single command that automatically removes all unused fields from your GraphQL queries and fragments in your RescriptRelay project! Prevent overfetching with no manual intervention. So excited this is finally stable enough to ship in rescript-relay 0.21.1! A short thread:

Well hello there dictation!

Try the new reactive code analysis if you haven't yet: x.com/ccrisccris/sta…

We just released ReScript v12.2.0 github.com/rescript-lang/…

I'm definitely finding programming more fun now in the agentic coding era. Larger capacity + getting more done in less time is of course fun. But, I really enjoy the "how can I make this process work as well as possible for agents to work on" parts. It's fun and stimulating.

We are about to sunset the ReScript legacy build system. If you’re stuck, can’t upgrade, or worried about migration, we want to hear from you! Join the discussion: forum.rescript-lang.org/t/ann-sunset-o…

ReScript 12.1 got released: github.com/rescript-lang/…

This is pretty crazy black magic from @ccrisccris . Reanalyze runs whole program analysis to figure out things like dead code, down to the record field and variant constructor level. Incredibly powerful. In a real world project of ~1900 files and ~750k loc ReScript, doing the actual analysis takes just over 100ms. That's for the whole repo/program. And given the incremental rework here, rerunning that analysis even if files change adds almost no additional overhead. This means that we'll be able to provide whole program statical analysis (dead code, exception analysis) with real time feedback in the editor. This is massively powerful in itself, and by extension this opens up many many interesting use cases. Exciting!

Well, it's all client side, so I guess the client would have to either select them or suppress them. But a good solution could probably be to add an ignore list as well, to let the client suppress those warnings both on the config and field level. Haven't bumped into this issue myself yet though!

RescriptRelay recently shipped an "exhaustive" directive, that you can apply on unions/interfaces in your GraphQL to force you to always select all possible members of that union/interface. I just shipped an addition to that - "autoExhaustiveTypes". Point out types that should always be treated as exhaustive, in the Relay config directly. No manual directive needed, and you can opt out with the new "nonExhaustive" directive on a case by case basis. This is one of the most useful things I've come across recently. I already have a great many use cases for this. One example is content block types from a CMS. Always want to make sure we select and handle all of these. Out in RescriptRelay 4.1.0.

@davesnx Great post with great insights! This sounds very fun to work on.

I made html_of_jsx a bit faster and published a blog post about it: how it's done and some won'ts! sancho.dev/blog/making-ht…

@davesnx Good tip! 😀

while prompting If you ever need to over-engineer, try this: "We need NASA-level quality. Humanity depends on it." I’ve used that line to translate TC39/test262 tests into OCaml. Sometimes overengineering is actually great ^_^

@tsnobip @verdonckflorian 💯

@verdonckflorian haha we definitely needed your boost to bring it over the finish line!

@davesnx Thank you Dave, that really means a lot!

This is what pragmatism and 2 years of hard work (with a bunch of contributors) have done Proud of you folks

A very long time coming. Excited it's finally shipped!

ReScript 12 RC 5 is out. Hopefully the last RC before stable. Go try it: github.com/rescript-lang/…

The Dead Code podcast invited our own @TheJoshDerocher to talk about all things ReScript. Give it a listen!

I was on the latest episode of @DeadCodePod to talk about @rescriptlang! If you've heard the name and wondered what's going on with it in 2025, give the episode a listen! shows.acast.com/dead-code/epis…

Anecdotal of course, but it does quite well with ReScript already. Not having as much training data is problematic, but the fast feedback loop, soundness + we're actively improving error messages to work well with agents + experimenting with some basic MCP to help, makes a big diff. There's lots of cool stuff to experiment with here as well, given the "if it compiles it works" baseline, but also the type of static analysis you can do when the type system is sound. Something we'll be diving much deeper into for sure.

I haven’t seen anything about how well coding agents do with fully sound type systems, like ReScript or Elm or Haskell. My assumption is that a sound type system would allow the LLM to write more accurately, due to the strict verification checks.

In the next version of our vscode plugin 🚀: github.com/rescript-lang/…