O'Reilly Media – Learn by doing — Python, data, AI, machine learning, Kubernetes, Docker, and more. Just open your browser and dive in. Learn more and keep your teams’ skills sharp at oreilly.com/changelog
Square – Develop on the platform that sellers trust! Use API Explorer to interact with, test, or play with your applications in Square. You can build, view, and send HTTP requests that call Square APIs with API Explorer. Get started with Square, check out the API Explorer, or the API Explorer docs.
Sentry – Build better software, faster with Sentry’s application monitoring platform. Diagnose, fix, and optimize the performance of your code. Cut your time on error resolution from hours to minutes. Use the code
PARTYTIME and get the team plan free for three months.
Click here to listen along while you enjoy the transcript. 🎧
How’s it going, Jerod?
It’s going good. Hey, you launched a new thing, it’s called Wormhole… How’s that going? Good?
Yeah, going pretty good. It’s fun times.
Tell the folks what it is real quick.
Yeah, it’s a tool for sending files to people with end-to-end encryption, so you can safely send your files across the interwebs.
Yes. It’s like Firefox Send, only they shut that down and this is probably even cooler, because you’ve built it… Maybe you’ll have to give us the skinny sometime; remember we did the nitty-gritty on BitMidi…
We might need to regroup and get one for Wormhole.
Yeah, let’s do it.
Awesome. Sounds like a plan. We’re also joined by Patrick Ecker, who is with the ReScript Association. We’re here to talk about ReScript. You may have heard of ReScript, or maybe not; maybe you’ve heard of BuckleScript, maybe not. Maybe you’ve heard of Reason, maybe not. Maybe you’ve heard of OCaml. Maybe you’ve heard of none of these things. We’re gonna sort through all that, and hopefully dive deep into this cool language and ecosystem for building web apps… And maybe even more. Who knows. Patrick, welcome to JS Party.
Thank you for having me.
We’re excited. I thought we would start with all of that because I had never heard of ReScript, but I had heard of Reason… And I hadn’t heard of BuckleScript until I read the rebranding post… But y’all have been around for a while, in different forms, and there’s multiple tools that have come together to kind of unify and hopefully have a cohesive story going forward… But give us the background of these disparate tools, or involved tools, and then kind of the coming together. Maybe sort through that from that start, and then we’ll get into the nitty-gritty from there.
Ever since we did that, suddenly people get it. People get to the platform, they get to one cohesive website, all the resources are on there… We have a cohesive story for React development, we have cohesive stories for how to integrate it with Next, how to integrate it with any React application that already exists… And we made it really clear – we also removed all the diverting for ReasonML or OCaml because it’s not relevant anymore. We care about minimalistic design, minimalistic CLI, no configuration or low configuration, and also a syntax formatter without any options. Without any of them. Not even the [unintelligible 00:07:11.02] not even semicolons, nothing. There is just one style basically enforced, and we are really glad we did that. We’re really happy that this is now such – now it’s easy to understand, and now we are happy, and now we want to start out again with a fresh brand and a cohesive story.
I just have to say, the more you kept talking, the more excited I was getting. All the words you were using - minimalist, no configuration format, or without any options, no semicolons, focusing the website down… I’m really curious now to try it.
[07:46] Right, right, right. It’s so exciting also for me, because I’m also not the biggest fan of these bulky, huge languages that give you 15 different configurations and every project looks different. And the second thing is the major selling point of the platform is that it’s fast, ridiculously fast. It’s hard to describe, actually. We try to build a platform that doesn’t really [unintelligible 00:08:08.26] So we can compile (I don’t know) 3,000 files in a project once, and then can start a cold build… Or actually, we cache files on the file system level, but we don’t need an extensive, incremental background service which requires two gigabytes of RAM, like in TypeScript. If you want to have a fast build, you need to wind up this huge server, and then it indexes all your files, and then caches get invalid in between in memory, and then you switch branches, and then suddenly all your type information is kind of corrupted, and then you need to do a cold build again and this takes 20 minutes… If you have a big codebase, like a serious codebase. For smaller projects it’s probably not a problem…
ReScript really scales with the amount of files you have. If you start out with a ten files project, it’s instant. It’s 20 to 50 milliseconds per build. It doesn’t matter if it’s an incremental build or a cold build. And then you have huge size projects, like – I have one client who has 3,290 files, or something; the first initial build, if you completely clean this whole thing and build it once, it takes like one minute and thirty seconds, and this is not even optimized. There are a few things you can tweak to make the compilation faster. But after that, you change a file and it doesn’t take forever to just recompile this one file, and it doesn’t really rely on these caches I was talking about. And then things get way less complex if you can just rely on one simple command that winds up when you need it, and then winds down when it’s done.
We also don’t have – in the core language, if you just write ReScript code, you don’t have any null pointer exceptions, because we don’t have any null. We don’t have the concepts of null. Instead, we have a few other niceties which help you build very complex applications. For instance, we’ve got variant types, which are also very well known in languages like Rust, which is a data structure to design complex domains. If you think about like TypeScript, when you’re using a tagged union, you usually have an object type, and then you have an attribute type on there, and you call that type user, and then you have some certain attributes available because this is like a user type… Which is kind of like abusing the object type of some sense, and then gradually refining the type. In ReScript we have the variants, which look a little bit like – I don’t know how to explain it. You would define a type user, and then you have constructors values; call that (I don’t know) admin, or user, or privileged user, or moderator, and then you can attach data to it.
[12:28] So you can have an admin constructor, and this one contains a string for the user name, and then you can just use that as a value in your program, and then you can pattern-match on that with a very powerful switch-like expression. So you can really design your domain just with types, and then later on use these values to manage your application code.
So no bugs. That’s what I want. I want no bugs.
I mean, you will still have bugs…
Alright, I’m out.
…but it’s very easy to at least say – if I change the interface or something, the compiler will really help me; the compiler messages are really good, especially with those variant types I was talking about. When you change something, then the compiler will say “Okay, this interface doesn’t match here and there.” If you do pattern-matching and you’re for instance adding new cases to a variant; for instance, I have my admin and my moderator, and I want to add a user variant constructor or whatever, then pattern matchers, wherever I have a switch expression, the compiler will tell me “Hey, you forgot to add the user constructor case.” And when I remove the user constructor, it says “There is no user constructor.” This is super-useful when, for instance, you’re building React components. React components in the beginning are super-easy. You’re like “Oh, I need to have a button.” Okay, HTML button. That’s it. Then it’s like, “Oh, but we need accessibility”, right? And then you need like, okay, I need to annotate different states; when there’s an hover state, or when there’s like a click hover, or when you have touch, and other interactions… Suddenly, the code gets really complex.
When you look at things like – Tailwind did a really great library for doing the heavy lifting for you, where you get React components and then you just use them, and they implement a complex logic in the background. Maybe you check that out; check out how complex this code can get with TypeScript, just because they’re using these tagged union objects, and then they try to shoehorn it in with some switch statements. It’s really hard to read, and then you need annotate everything, because the type system needs more help inferring all your types. In ReScript, every type that is inferred from the compiler is 100% correct. This is also very nice, if you can trust the compiler there to do the right thing.
So let’s say I’m like Feross and I’m excited, I’m like “Hey, ReScript. Let’s give this thing a shot.” I know nothing about it, I write React-based web apps, and I’m at least interested enough to hop in and see what it’s all about. What do you tell folks? Where do they start? What should they avoid? etc.
Yeah, so the most important thing is we have everything on our website, ReScriptlang.org. We’ve hopefully structured the documentation in a way that it’s easy to follow. We usually recommend to start out with the manual, which is more written in a narrative style. So you start at the introduction, and you go through the installation, and then you can dive through the most basic features.
It seems kind of like Swift in that way. When Apple was trying to encourage everybody to switch over to Swift, they had these larger decks of C codebases… And you could just sprinkle Swift in, file by file, or maybe even class by class; in this case maybe component by component. You’re like “Well, I’m gonna write this component in ReScript, and it’s gonna generate this nice-looking output.” Do you check that in the source code as well, or…?
Yeah. We also generate version headers, so it’s usually a warning on top that this is generated.
Yeah, very obviously generated.
I’m still trying to wrap my brain around zero-cost, immutable data structures.
[31:59] So in practice, if I was using ReScript – just a totally random question, but I’m just thinking of what I would actually experience as someone who’s decided to introduce this into my project. When I use a dependency that I just found on npm, what’s the process for most packages that I would find in an npm search for bringing that into ReScript? Is it a lot of work to write the bindings and all that stuff? Doesn’t it have the same problem as TypeScript, where the definition files will get out of date or out of sync over time?
I’m gonna let Feross ask all the questions from here on out.
[laughs] Yeah, this is exactly what we are trying to figure out for the community as well. This is actually a philosophical problem - how do you make sure that all these npm dependencies, or these ReScript bindings to these libraries are always up to date? My current approach, my practical approach is you don’t try to write these bindings for the general community. It sounds a little bit weird.
So there’s a lot of opinions into “How do I write these bindings?” and that’s why I recommend to learn the external syntax and just – you define it like a variable, basically. It’s like one line of code, you’re like “Oh, I want to map to the event DOM handler type”, or like one method of it; I just create one binding with this particular interface, and then use it.” Later on you can extract them into modules and just reuse them very easily. So you can either share them – I usually actually copy paste them around in some projects. If you’re really cautious about that and you want to share it in your different codebases and you want to make sure that it’s always up to sync, you can of course extract it into an npm package… But many of us actually don’t have that many ReScript codebases and it’s actually easier if you have it in-line, and then you can edit it as you need, and then later on publish it independently from that.
But this is more like this vendoring problem… So you can have N dependencies on npm, and those have another N dependencies, and then you’re like “Okay, how do I fix this one bug, which should be easy to fix, but then I need to go to five different maintainers to fix that?”
So my recommendation would be write them ad-hocly, and if you’ve got a collection of useful bindings that have practical proof, then it’s a good point to start sharing them with the community… Because some people start it, and then they get overwhelmed with how complex it is, and then they stop it. Then some people rely on that, and that is a problem. So we try to educate the people to really think about what they want to depend on, and if they need to depend on it.
So Patrick, if you were to meet some developers and interview them, and at the end of these interviews you could pick one to be like “This is the person that ReScript is for. This is our perfect user today”, what is that person like? Are they senior-level, are they experimental, are they building production apps? Are they in a large team, small team? Give us an idea of who should be adopting ReScript right now.
Good answer. So if you’re that person out there – actually, Feross, you’re kind of that person, aren’t you? You’re a product person, you like to build stuff fast, and high-quality, and kind of in small teams, and you also work somewhat autonomously a lot. I think a lot of the difficulty is large teams, like “How do I introduce ReScript?” That’s why the incremental aspect is cool, because it’s hard to sell that to your boss when it’s going out on a limb for benefits, but how obvious and clear are those benefits. But you’re in a kind of position - and myself as well - where we can make the calls on the technology choices, and build cool products quickly and with high precision and high reliability, it sounds like.
What are the big wins for somebody like Feross? I know we’ve kind of touched on them, but if you could say like – I mean, zero bugs was nice… If it compiles… And no tests. Don’t worry about tests. It’s kind of like the TypeScript of as long as the types make sense… But there’s no any type, so you actually have to have types. All of my types are just any types, because I’m just a dynamic kind of a guy. But what would Feross win if he just picked up ReScript for his next startup or his next side project? What would he feel, what would he appreciate?
I was kind of joking about the whole testing thing, but is there a testing story, or is there tooling around testing? Or do you just say “Don’t worry about tests, because we’ve got you covered”?
Yeah, we – of course, testing is important. We tend to test business logic…
Because that would sell me, you know? Wouldn’t that sell you, Feross? It’s like, actually, tests - I know they have their value, but with our tool, with our language, just go ahead and forget about them. You’re not gonna need them.”
Yeah. Anytime you’re asking “Did this other part of my program send the right thing I’m expecting?” It fixes that problem. But like you said, any typed language does that. What I would love to do is not write any tests. Wouldn’t that be the ultimate productivity? Just write the code, and it’s gonna work. [laughs]
That would be the golden dream, right?
Yeah. So that would get me on ReScript right away. I’d be done with every other language. I’d be like, “Alright. No tests, no bugs, ever. Boom.”
Yeah. We definitely need testing, and we usually – we’re currently tinkering with very simplistic recommendation for testing… Because right now you can use Tape, or you can use Jest, or whatever… But we are not too fond of it, because it adds another layer of complexity again. When you add Jest, suddenly you have a lot of configuration again you don’t want to necessarily worry about… So what we are currently tinkering with is like a minimalistic test “framework”, which is like a hundred-lines file [unintelligible 00:43:51.26] code, and you drop it in your project and then you can just use that test framework, with the standard set of test functionality you usually expect, and just run it with Node. Just run a Node script, and you can run every test individually, like with tape, for instance. I really like this idea of reducing complexity on the tooling side, and we try our best to always follow this philosophy. So hopefully, the testing story will be as clean as the rest of the toolchain.
[44:26] Well, there’s lots of stuff here, and it’s worth pointing out it’s not Patrick just working on this, on your nights and weekends; this is a long-time effort by lots of people. As we mentioned at the top, different projects kind of came together, different people came together and created ReScript out of these other things that were all working together. The core team is seven folks, which is a pretty big core team. So there’s lots of people working on it. Tell us about the community. I know there’s also the ReScript Association, which is kind of like a foundation, like an entity that is building this thing… So flesh out the community story so that people who are thinking about giving it a shot know what all is there. It’s not somebody’s side project toy language that they wanna learn how to do a compiler in, so they built ReScript. It’s not like that; it’s serious business.
Yeah. So the original project started out in Bloomberg, where Hongbo Zhang, the author of the compiler started this whole effort. I think this was five years ago already; he started working on this until Facebook came out with ReasonML, and got the idea, and Cheng Lou got this really nice idea of making these two things work together, the Reason project and the BuckleScript project back then. Facebook and Bloomberg kind of collaborated on this thing until it grew a few years, and the community started to shape around it. We had a few startups in there, we had a few bigger plays in there; for instance, we had Sotheby’s, which is a bidding platform for expensive artwork, which is located in [unintelligible 00:46:09.22] I think… And we have companies like Draftbit, a startup which has an online editor for creating mobile apps, like a no-code tool with a lot of interactions and a lot of complex workflows. They’re really happy with that, of course. And Facebook, they have been using it in the Facebook Messenger app, on the web version, which is also fully written in ReScript.
One of our core team members is Ricky Vetter, who is also working on the Messenger team… So we’ve got the insights from that, as well.
We have companies like Ahrefs using it. They are a huge player in the SEO sector, for analyzing SEO data. There is Ubisoft Club, or Ubisoft Connect now; I think they rebranded. They use parts of ReScript in their React Native app. And there’s also some interesting companies, like in Japan, Elm Inc. - they built an app which is called [unintelligible 00:47:06.12] It’s a smartphone platform for the field triage of stroke patients. So when you think about these medics or paramedics currently in the field, and someone has a stroke, and they have a response app where they can ask for help, and ask for symptoms. This was very important that the app doesn’t crash. And for these use cases, where things should not crash, no matter how tricky it is, ReScript is really good, so these companies adopted it.
Or [unintelligible 00:47:37.12], which created an app for mission-critical railway safety. So when there’s a train passing down, like in Swiss or in France, passing down a red light, they stop the train and then they need to fill out this form, and there’s a very complex logic behind it. If you make a mistake, you can get in trouble, because there’s a train standing on the tracks, and if another train goes by, then you have–
You want that formula to work, is what you’re saying.
[48:07] Yeah, yeah, sure. And companies like TinyMCE - they are building a rich-text editor platform with ReScript, and for that it’s also fantastic. These really complex domains - this is where ReScript shines.
On the team, we’ve got, as I said, Hongbo Zhang, who is now also working for Facebook, Cristiano Calcagno, who is one of the cleverest scientists I know. He has been working on the Infer project, if you know that, for code analysis and static analysis of all kinds of languages. He has huge knowledge about analyzing code, which is great for us, because we have a lot of dead code elimination analysis going on right now for ReScript, because it’s fully typed. Super-nice to analyze.
We’ve got Cheng Lou, who has a huge vision on products, and designs, and lean, clean interfaces. I love that as well. Maxim Valcke, who is our master brain on the syntax level. He has been investing so much time into writing a syntax parser that is efficient and small. It’s super-fantastic work. And myself, of course, for working on the documentation; I’ve been doing this within the ReScript Association, as you already mentioned. The ReScript Association was founded with the goal to support the community and support a language with financial infrastructure, so people can send donations to it who are relying on the technology. So if you are a company who wants the language to succeed, the best way to invest money is to invest it in the association. They’re reallocating the money for developing the documentation, growing the editor tooling, working on core essential libraries, finding other projects, organizing conferences… We had like two conferences already - ReasonConf 2018 and 2019, and also a Reason conference in the U.S, which will most likely of course be rebranded to ReScriptConf.
So in the past 2,5 years we also collaborated with research institutes and companies, we collaborated with Ahrefs, which I already mentioned, with the Tezos cryptocurrency - they’re also really invested in this, because they want their crypto wallet apps to be stable, and they chose ReScript for their web frontends, and stuff like that. Or subsidiaries of Tezos, of course. Tezos is a huge project.
So this is how we try to set a foundation for the language on the community side, on the open source side, but also we have a strong commitment on the business side with the core team, who is working at Facebook, and all other companies that depend on it.
How about you personally? How are you paying the bills?
I’m getting funded, of course, with the work at the ReScript Association, but I’m also doing contracting right now… But I’m actually gonna start working together with another company who is using ReScript, which is [unintelligible 00:51:17.22] They’re building a sales-enabling platform, and I’m really excited about this… Building something neat.
Building cool stuff is always fun. How did you come to the project? We didn’t cover your personal journey to ReScript. What got you excited, what got you into it?
I don’t know, I started out in FlowType, basically. I was trying to contribute to the FlowType project, which is kind of the equivalent of DefinitelyTyped for Flow… And I tried to get involved with this work. This excited me, and Flow was a really nice project with the type inferences and such, but TypeScript kind of won this war, I would say, or the marketing… And I kind of felt disappointed, because I didn’t like the idea of TypeScript at all; the performance metrics, and stuff like this.
[52:10] In 2017 I got introduced to Reason, and I got really hyped up with the idea of having this polyglot platform, like having one language but it compiles to different things, and maybe you can have alternative syntaxes mixed in together… Which was the initial pitch I got in my head; but later on I got more involved in this, and started meetup groups, one in Vienna and one in Munich. And I also organized the first Reason conference in Vienna in 2018…
This kind of grew in me, and I was like “Okay, there is one thing that’s terribly missing in the Reason community, and that is a unified documentation platform.” Because every platform was one separate website, and it was really hard to figure out where to find what information, and define a user flow/funnel. So I started this project naively, I was like “Oh, I will just unify all the platforms into one website.” I did this for like 1,5 years, and at some point people started to like it because it was very useful. Then at the second time we said “Okay, maybe we should raise some funding for that” and we started to think about this ReScript Association thing. Then I got to know all the people, like Cristiano, who has been very supportive of our work, and he liked the ideas, and he introduced us to the team… And ever since we started growing. Then in 2020 we really started the new brand, and then said “Okay, we have this core team, and now I’m part of this.” I don’t like this idea of having a core team, but I think it’s important to have someone reliable for the technology you’re using… And if nobody feels reliable, why should you use this? That’s why I’m excited that I’m on there.
Pretty cool stuff. Feross, any other questions or thoughts from you before we call it a show?
No, I’m gonna try and find a nice simple project to give this a try on.
Yeah. Let me know how you like it.
That makes me wonder, are there good example apps or is there a version of the to-do MVC? Is there a real-world open source app that has a lot of frontend implementations? Is there anything like that, where folks can just poke around and look at a – not a complex ReScript thing, but maybe like a semi-complex one. Anything out there we can point folks to in the show notes?
Also, is there anyone who’s using it for specifically cryptography code? I’m just thinking the project that might make the most sense for me to try it on is a little cryptography module that we just open sourced for Wormhole. It’s not that many lines of code. It probably wouldn’t take too long to port it to a new language. That’s the kind of code too that you really want correctness on, and it’s worth the extra cost for maybe making it a little bit harder for a random contributor to contribute, but you get more correctness guarantees. I’m just curious.
[55:12] That’s a tough question I cannot answer, but maybe I can follow up later with that…
…because I have some ideas in mind, but I’m still not sure if – because some things are already existing, but they’re still in Reason syntax, and we don’t want to particularly point people to Reason resources, which doesn’t make any sense… Even though it’s the same compilation platform. The best real-world example app is ReScriptlang.org. It’s a Next.js app. Check it out.
So the playground as well?
Yeah, the playground is also written in ReScript. I’m not entirely proud of it, but it’s pretty damn stable. So that’s at least something.
That’s something to be proud of, yeah.
Yeah. And there are some open source apps… One is called Pupilfirst, but I’m still not sure if they’re still on Reason syntax, or if they already converted… Because we have this one command to convert the whole codebase and that’s it.
Well, why don’t you do this - hit us up with links afterwards, and we’ll put them in the show notes, if there are any ones that you would point to…
…that way you don’t have to come up with them on the spot. And then – I mean, surely, Feross, the Tezos team is doing some aspect of that. I don’t know what exactly they’re using it for, but… They’re a cryptocurrency, but there also is cryptography involved. [laughs]
Yeah, yeah. That’s what I was thinking. It sounds like a great use for it.
Yeah, totally. I would definitely be interested in seeing the results of that conversion, Feross, if you ever end up doing it. I think it’d make a good blog post, or even just like tweeting out the links of the before or the after of that module would be pretty cool.
Yeah. Well, listeners, links to all the things, even some things maybe not brought up, which Patrick has hooked us up with, will be in the show notes… SO check those out. Definitely keep up with Feross in case he does that port. He’s @feross on Twitter, maybe he’ll tweet about it… And check out rescript-lang.org as well.
I should mention that this episode was requested by a listener of the show, long-time Changelog member and a friend of ours, Brett Cannon, who also happens to be on the Python core team. So you have his interest. So there’s smart people who are interested in learning more about ReScript. Hopefully, this episode gave some people a start on a path down that way, at a very interesting language and toolkit and a view of making web apps.
That’s awesome… Patrick, thanks for joining me. Feross, thanks for hanging out. We appreciate it. That’s JS Party for today, we’ll talk to you next time.
Our transcripts are open source on GitHub. Improvements are welcome. 💚