Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
ReScript: A Better Typed JavaScript? (with Gabriel Nordeborn)
0 Plays2 seconds ago
ReScript is a strongly-typed programming language that compiles to JavaScript, and that puts it squarely in competition with TypeScript. So why would a JavaScript developer choose to learn it next? What does it offer that makes it a tempting proposition? And how are the ReScript developers making life easier for anyone who wants to make the switch?
To answer all these questions and more, I’m joined this week by Gabriel Nordeborn, one of ReScript’s compiler contributors.
--
ReScript: https://rescript-lang.org/
ReScript & React: https://rescript-lang.org/docs/react/latest/introduction
Reanalyze: https://github.com/rescript-lang/reanalyze
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
Gabriel on BlueSky: https://bsky.app/profile/did:plc:c55mqp6e6r24rrrypkmx7ker
Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Recommended
Transcript
The Rise of JavaScript Alternatives
00:00:00
Speaker
For a while in our history, there was a huge interest in developing alternatives to JavaScript because lots of people wanted to use JavaScript because it lets you write for just about every user in the world.
00:00:12
Speaker
But lots of people didn't want to use JavaScript because by the creator's own admission, the design was rushed. And it all solidified a bit too quickly. And JavaScript didn't get the necessary luxury of an early access iterative beta phase where it ironed out the kinks in its design.
00:00:32
Speaker
So JavaScript is what it is. Some people love it. Great. Not taking anything from them. But plenty of people wanted an alternative.
TypeScript's Success and JavaScript Evolution
00:00:40
Speaker
I think the first big success there was probably CoffeeScript, but there were plenty of others.
00:00:45
Speaker
Very interesting time in the web, but lots of interesting research and new ideas about design happening. And then eventually, TypeScript came along, and my personal surprise succeeded in fixing most of my problems with JavaScript.
00:01:01
Speaker
Didn't fix all the sharp edges, but it certainly felt like it gave you safety gloves. For me, it really transformed the experience. It made it sane, quite pleasant. I like TypeScript in a way I don't quite feel about JavaScript.
00:01:16
Speaker
So what of all that interesting research into alternative languages for the web? Is there still a big enough problem to be solved, a big enough demand? Is there a big enough question to be answered?
00:01:28
Speaker
And my guest this week, Gabriel Nordborn, would absolutely say, yes, there is. This research must carry on, and these ideas must be explored, and we have other things to say.
00:01:38
Speaker
That if JavaScript had had that luxury of more time in the oven, It would have looked similar to how it does today. Perhaps it would look similar to how TypeScript looks today, but it would definitely be different.
00:01:51
Speaker
If the TypeScript compiler authors had the luxury of occasionally saying, no, we're going to change the language here and there, they probably could have spent less effort on type checking all the edge cases and perhaps use that time on things like compiler speed or code analysis or other language niceties that make life a little easier here and there.
00:02:14
Speaker
And maybe in that alternate world where JavaScript had had more design time, maybe it would have looked more like Rescript. So what does Rescript look like?
Introducing Rescript: A JavaScript Alternative
00:02:24
Speaker
What makes it an interesting alternative to JavaScript that's familiar but different?
00:02:30
Speaker
What does it offer to those of us who just want to get the job done but would quite like to enjoy getting the job done a bit more? Let's ask an expert. I'm your host Chris Jenkins, this is Developer Voices, and today's voice is Gabriel Nordborn.
00:02:58
Speaker
Joining me today is Gabriel Nordborn. Gabriel, how are you? I'm good, thank you. How are you? I'm very well. very well. I'm pleased see you've got a on the wall behind you. Yes. After this is done, you're ready for a jam session.
00:03:12
Speaker
I'm ready, yeah. I used to i used to have um i have an electric guitar and a bass as well, um and they usually hang over there. But my my girlfriend, she um teaches at the university. she She gets so many questions about whether she plays or not whenever she's lecturing, so I have to kind of remove them.
00:03:29
Speaker
So if you're an acoustic one, is it's fine, right? yeah yeah. That can also look decorative, right? it Yeah. yeah Okay. So the shared video room, I hope you've got exclusive access for the next hour or so. Yes, yes. I hope so.
00:03:41
Speaker
yeah We'll find out. We've been interrupted by cats before, but never by humans. Yeah. Okay. So, so let's move on from music and, uh, spousal arrangements to, ah re-script, which is something I know a little bit about, but I'm going to get you to give me the the details on.
Rescript's Type System and Performance
00:04:01
Speaker
Rescript? It's something, something JavaScript, something, something OCaml? Give me the proper definition. Yeah, Rescript is um a programming language that compiles to JavaScript. I guess that's the the easiest possible way of explaining it. It compiles to JavaScript.
00:04:17
Speaker
It integrates with the JavaScript ecosystem. It integrates with your JavaScript tooling. It's essentially... trying to be optimized JavaScript. and And it's, ah yeah, so it's that's that's the that's the easiest possible way of describing it. But it kind of approaches it from another angle than what TypeScript does, ah for instance, which is also JavaScript. But yeah. Yeah, because I sort of feel maybe, ah tell me if I've got the history right here, but there was a huge interest in JavaScript, but not JavaScript languages.
00:04:50
Speaker
For quite a long while, I think CoffeeScript is the first one that comes to mind, historically. yeah And it feels like that market has been chewed up a lot by the emergence of TypeScript.
00:05:04
Speaker
Yeah. So what does Rescript offer today? Yeah. So Realscript, comparing it to to TypeScript, TypeScript is trying to type JavaScript, right? And TypeScript has, I mean, the reason that yeah a lot of the compiled-to-JavaScript languages have kind of ah been eaten up or or close to it is because TypeScript is pretty fantastic. I mean, it's pretty great that what it's trying to do. It's been wildly successful in in bringing types into the JavaScript world. This is a community, I mean, I'm ah originally
00:05:39
Speaker
a JavaScript developer. I was around when Flo first came out from the type from Facebook back when TypeScript was a thing, but not really a thing, kind of. And then of... remember competing for superiority.
00:05:52
Speaker
remember thinking neither of them would succeed. Oh, really? Yeah. Yeah, yeah. Yeah, I know. I mean, looking back at that time, the the what I remember is primarily two things. One, the the the feeling of... I'm not from a typed language for for starting out, so the feeling of catching bugs in the build, which was fantastic.
00:06:13
Speaker
And then also the feeling of the Christmas tree that's the errors in the editor at every version upgrade, where they learn to type more of JavaScript yeah in each version. And we would have...
00:06:25
Speaker
back where I worked at that point, we would have um hundreds, sometimes thousands of errors. ah and And this was like an effect of of obviously of of um the type checker getting better and better. ah But still, like that was pretty taxing on the mind. so and so But to get back to the original question, like where um TypeScript, where Flow is still around, Flow is still really cool. I think it's very effective and has worked out really well for Facebook, but they haven't really cared about it.
00:06:56
Speaker
becoming mainstream, whereas TypeScript has really cared about that external usage. and But yeah TypeScript is essentially, in my view, then the idea that we take JavaScript, which we already have, and we still want JavaScript, right? And we want to make as little adjustments as possible in in the actual JavaScript that we write.
00:07:16
Speaker
and We just want to apply types on top of this. So we want to take something that already exists and then apply types on it. Yes. um And that, because JavaScript is the way JavaScript is, it's a language that's been around for a long time that drives a huge part of the web that explicitly doesn't want to break any backwards compatibility because it would potentially break 10-year-old sites, 15-year-old sites that are perfectly fine and around and should work.
00:07:44
Speaker
Right. That's the yeah the main goal. um Because of that, JavaScript has evolved a lot as a language because it's so incredibly popular, but it hasn't really cleaned up any of the the old kind of baggage. Yeah, you get explicitly, you get bugs in the spec. If you don't have this bug, you are not compatible with JavaScript. Exactly. So you have to code the bugs, which I mean is kind of cool. I think the the trajectory of JavaScript is just...
00:08:11
Speaker
It's amazing and and really, really cool. And the engineering that goes into the various JavaScript engines to optimize and everything, is it's fantastic.
00:08:22
Speaker
yeah and But TypeScript is kind of trying to tame this beast, but they're also taking the approach of we want to tame it just enough for it for it to be kind of productive for you. So our goal is not not to make everything typed, per se. We are fine with there being inconsistencies. We are fine with there being ah weird patterns that you can do that will that are pragmatic choices, essentially.
00:08:48
Speaker
we're trying to go go from the top and just apply this this type system on top of JavaScript. yeah Rescript is the idea of what if we instead go come from the side? We take something that's established.
00:09:00
Speaker
In this case, it's ah the roots are in OCaml. So we we take OCaml in this case. um Another entirely separate thing, ah entirely separate type system, conventions, everything, paradigms. We take that and then we try and mold that into something that comes as close to JavaScript as possible ah without making too bad trade-offs.
00:09:21
Speaker
Right? So... And when you say mold it, do you mean you don't just mean molding the output, you mean molding the surface language too? Yes, exactly. yeah Syntax, language features, the type system, a bunch of things.
00:09:36
Speaker
Try and make this move as close to JavaScript as possible. um while not like throwing away all of the good things from the origins, like the sound type system, for instance, and all of the speed of compilation, everything around that.
00:09:54
Speaker
So it's another angle. And what what comes out of it is still JavaScript. It's ah very optimized JavaScript. Since it's a compiler, since we kind of did made that trade-off, we can do a bunch of things that are really cool. like We can rearrange... um the Even if you if you have a type definition of a user that has a name and an age, for instance, and then you and define several instances of that inside of JavaScript code. And sometimes you let age come first when you define it, and sometimes you let name come first.
00:10:24
Speaker
and Perfectly valid to do that. yeah But the JavaScript engines generally don't like that. They want things to be in a uniform shape so they can do optimizations behind the scenes with, I don't know all the terminology, but shadow classes and whatnot.
00:10:37
Speaker
Oh, okay. it's yeah it's and If things are always the same way that they were defined in JavaScript, it's generally beneficial too ah to the engines. Yeah, can vaguely imagine like just-in-time compilation taking advantage of that kind of thing. yeah And a bunch of caching and the i know all of those things, yeah essentially.
00:10:57
Speaker
and So what Wearscript can do, since we already made the decision that, you know what, this is a compiler. we're not like TypeScript we is um lets you write annotations essentially on the code. But the idea is that if you remove all of these annotations, what you have is JavaScript, the same JavaScript that's going to run in in the browser on the server or whatever, yeah um with a few like small, small, small deviations from that, like enums and stuff that are aren't really JavaScript. But yeah. By and large, TypeScript isn't trying to rewrite your code.
00:11:28
Speaker
No, not at all, exactly. It's very much trying to do the opposite, just be the same thing but with added types, essentially. um And that's a trade-off that's really good in certain situations as well. But Reskip, we've already made the decision that we have a separate compiler, we have a step that takes code that's something else than JavaScript, although it looks very much like JavaScript, it behaves very much like JavaScript, still it's something else.
00:11:53
Speaker
And we have a build step that produces the actual JavaScript that runs in the browser or on the server. And with that, we can do a bunch of things. Like, for example, going back to even if we define in our Rescript code age first and name second and name first and age second interchangeably, what's output in the JavaScript is always name first and age second.
00:12:14
Speaker
So it always becomes the right shape, which is beneficial to engines. And this is something that you don't have to care about. You don't have to think about that. It's just done for you, essentially. Yeah. um Rewriting performance for free, which is what a compiler should be good at, right?
00:12:30
Speaker
Yeah, exactly. And I mean, it's always a trade-off because one of the main goals of Rescript is also to produce... We want to produce JavaScript that's as close to what you'd write by hand yourself as possible, right? And that's important because one of the like the biggest challenges that you face as a language like Rescript, where you're trying to make people not use the industry standard, make people, or like, yeah, use something else than the industry standard in addition to what you're already doing.
00:13:02
Speaker
We're starting at a at a very... We're starting... and with a lot of deficit in trust, right? We've got to build up the trust and show that this thing, this bet that you're taking, yeah and we understand the bet that you're taking and we're actively trying to work on it playing out well for you.
00:13:19
Speaker
um So the the the part about emitting JavaScript that looks handwritten is a very big and like important part of that. Because That would suggest to me that your target audience, because there are two potential target audiences for this that spring to mind.
00:13:38
Speaker
OCaml people that want to be in the browser and JavaScript people that are lured towards the idea of OCaml. And that suggests you're looking at the latter. Yeah, exactly. And not like ah if you're interested in OCaml, that's great. And that's you're going to feel right at home with few differences. But like we're what we're targeting is JavaScript developers or TypeScript developers that want another type of, and in our view, then another web dev or JavaScript developer experience that makes other trade-offs than the things that they're currently doing, but that has a lot of concrete, very clear benefits and
00:14:16
Speaker
like very many answers to problems that you face as a TypeScript developer at
Programming Productivity and Flow
00:14:23
Speaker
scale, essentially. OK, give me an example of a high-scale TypeScript problem that you've solved. So, yeah.
00:14:31
Speaker
So ah one there are two like things that regularly come out when someone starts using Rescript and then goes back to TypeScript. And one is compilation speed. and That's a massive difference. And it's a pretty big problem in larger TypeScript code bases. And that affects...
00:14:48
Speaker
Both building your actual application, or rather type checking it, building it is incredibly quick because it's all about just removing the type annotations, right? So actually getting from TypeScript to JavaScript that runs in the browser on the server, that's fine.
00:15:03
Speaker
um because but But validating that that also type checks, that takes time. Right, so it's developer experience rather than CI pipelines. Yeah.
00:15:14
Speaker
Exactly, exactly. Or like you want to type check in your CI pipeline as well, probably, but still. yeah am And that also affects and feed the feedback loop inside of the editor, for instance.
00:15:27
Speaker
um It's pretty common in in larger TypeScript code bases to have lags in autocompletion, for instance, in hovers and everything. um Give me an idea of what counts as large.
00:15:40
Speaker
i mean, what size of project am I going to have to be at before this starts to become noticeable?
00:15:46
Speaker
I think it's ah TypeScript is getting faster and faster and better and better, of course, as well. um But it's it's still pretty noticeable. I notice things in in there projects that are around 100K lines,
00:16:01
Speaker
It depends entirely on what libraries you're using as well. And that's another part of this. Yeah. and Because the type checker is so advanced in TypeScript, which is really cool. like The things that they've been able to do and let you do is is amazing and fantastically fascinating.
00:16:21
Speaker
and Like being able to build in an entire parser inside of the type system itself that can figure out... like It can type GraphQL, it can type CSS, can type... and extract and variables from...
00:16:37
Speaker
um path strings for route strings and things like that. So it's it's amazing. But it comes with um lots of pitfalls in performance if you don't know your TypeScript wizardry well, essentially.
00:16:53
Speaker
Right. And do you have the equivalent then in... You're saying you have the equivalent in Rescript, but faster? No, we don't. So that's another point. So Rescript makes a very conscious choice of we're trying to be simple.
00:17:08
Speaker
and the If you contrast the Rescript type system with um the TypeScript type system, the TypeScript type system can do virtually anything, almost. It can do so much and you can wrangle it and you can kind of make it molded into Very many different things. Whereas um the RISCIP type system is much more simple, but also much more predictable, both in terms of and how it works, but also in terms of speed, for instance.
00:17:35
Speaker
There are no larger pitfalls in terms of performance of type checking, for instance, like there are in in TypeScript. um And I usually like i like to liken it with TypeScript is a...
00:17:47
Speaker
a massive amount of tools that you can do virtually anything with. um And those tools are are many in numbers and they are usually kind of not super sharp, but you can combine them together to to create almost anything.
00:18:02
Speaker
Whereas ReScript is a small toolbox that that you can't where you can't do the same things in all instances that you can do in TypeScript. But the tools that you have in your toolbox are incredibly sharp and are well thought through to fit together very well.
00:18:16
Speaker
And this, in my view, and since I'm i'm originally a type like a JavaScript TypeScript developer, and and I spend still spend a good chunk of my time in my day job too and working on TypeScript toolbases stuff, what I miss primarily when I go to TypeScript is and how much how many little things I have to do manually in order to achieve achieve the same thing as in Rescript. like how You're going to have to give me a concrete example of that. Yeah, of course. So one one thing is ah immutability, for instance. Everything is immutable by default in RISCIP. There are great tools for using mutable values and working with mutable values, but you're never ending up in a situation where something's accidentally mutated. It's always a an explicit action.
00:19:06
Speaker
and That's one thing. Exhaustiveness checking when working with... I mean, in in Rescript, I work with pattern matching. That isn't really a thing in in TypeScript, but you can kind of force it to force the compiler to have you in within certain limits make sure that you handle all cases, for instance, in and with ah for of the value of a string literal or whatever.
00:19:30
Speaker
yeah In Rescript, that's done automatically always in all cases. So you always have to handle all cases. And the compiler is not going to compile unless you do that. um yeah Yeah, that's one of those features I really like when someone adds an extra case to the data. And then you've got to find all the places in the code base where it might affect things. Exactly.
00:19:49
Speaker
yeah yeah And it's it's ah again, it's one of those things that's it's doable to a certain extent in TypeScript, but you kind of have to do it yourself. yeah You have to yeah ah either use a library that's tailored for it, which comes with its own kind of potentially performance issues and type checking performance issues. Or you have to make sure yourself that you tell the compiler that I want you to make sure that this thing down here never reaches essentially so you you have to move another step into it and kind of do the work yourself you can do it but you got to do it yourself whereas in risk it's all built in yeah in the wall yeah yeah yeah okay those are two very good advantages anything else on the top list
00:20:31
Speaker
Yeah, so in Rescript, everything's an expression. So you can assign anything to a let binding, for instance. You can assign ah an if for switch to that binding. um You can put expressions ah like switches or ifs or whatever anywhere in the code nested inside the father code and and the kind of things that you can't do in in TypeScript where you'd have to use either ternaries because those can be nested in line, right? Or you have to assign things to a variable or break it out to function.
00:21:01
Speaker
And these things add up, especially around making your code kind clear to understand and co-locating and logic with where it's supposed to be. Like, for instance, say that you're deep in somewhere and and you're submitting something to an API. an api And you have ah an object that you're submitting, and one of these props are the status of the current user or something like that.
00:21:24
Speaker
um You have something else inside in your scope that you want to derive the status from. um And in Rescript, you can just put your switch at that that exact object prop. right You can just switch right there and say that the current status of the user, as I'm submitting it to the API, is this switch. And then you switch on something else. Oh, it's online. Then it's supposed to be this instead. Oh, it's offline. Then it's supposed to be this instead.
00:21:51
Speaker
Whereas in in TypeScript, this would have to be either a long chain of ternaries, because that's the only way to kind of put expressions directly in the code. It would have to be an immediately invoked function, because that will kind of give you a a block kind of thing as well. Or it would we have to be a variable, which is the most common thing that you do, or a function that you call.
00:22:12
Speaker
but yeah Neither of those are are as good for maintainability and clarity as having the logic put exactly where it's supposed to be, where it's applied.
00:22:22
Speaker
Yeah, I've often felt this distinction between like statements and expressions is very arbitrary and unnecessary these days. yeah So would you say then that Rescript is a functional language? Is it pushing people away from something like OO?
00:22:38
Speaker
It has definitely has its roots in in a functional program. We're not trying to kind of advertise it as a functional program only, where you can still do lots and lots of functional things in it, but we're trying to be pragmatic. like but we want We want people to build good stuff and to be able to use this for the things that it's good at being used for. So we're not trying to say that you have to do functional programming differently only if you use Rescript, but there's no denying that it's quite easy to do functional programming and you're going to end up doing a lot of functional programming because there are no classes, obviously, and those types of things. So there's no OO in that sense.
00:23:18
Speaker
um So yeah. Right. so But we're not trying to be dogmatic about it, I guess, is the point. yeah if ah If I had the equivalent program in JavaScript I wanted to rewrite in Rescript, I would not just be rewriting, but also rethinking how was architected.
00:23:31
Speaker
Yeah. okay that's That's a pro and a con, depending on where you're standing. Yes, definitely. it's And that's the like the usual trajectory. since i i work a lot of with people who are introduced to Rescript um and usually come from JavaScript or TypeScript.
00:23:48
Speaker
I also spend a lot of time talking to the various companies that use Rescript in production to try and understand like what can we do better, what are you valuing, what's important for you, and those things. And the story I typically hear is that ah You introduce Rescript and...
00:24:05
Speaker
It takes some time to getting into. It's another paradigm to what people are used to. If you come from another language that's similar, obviously, it's going to be a lot more smooth sailing. But if you come from JavaScript and TypeScript, you're kind of used to doing things in a certain way. And it does take some time to kind of get get up to speed with the paradigms in Rescript, where you will be working much more with functions. You'll be working with using pipes, for instance, to and transform things and um and everything around that.
00:24:34
Speaker
and But then when when they kind of get over the hump and start getting productive in it and then eventually come back to TypeScript, it's usually the same kind of um experience that they find themselves missing the things that I stated, of course, and other things um in a way that they hadn't really thought about before.
00:25:00
Speaker
Like, all of a sudden, when they're writing TypeScript code or or pure JavaScript, there are things like that I now have to do manually that I did perfectly well before manually, and I wasn't bothered by it.
00:25:12
Speaker
But now that I kind of know that you could potentially do this in another way, it's becoming kind of a... yeah Yeah, I definitely think in programming, there are some things that are obviously like better than what you've currently got.
00:25:27
Speaker
But there are some things it's like, why would I need that when I can do it myself? And it's only when you go over there and have the thing, the tool that does it for you, that you suddenly feel like the old way was primitive.
00:25:38
Speaker
Yeah, this is um this is very um this is especially a thing with like compilation speed, which is hard to kind of tell people that this is important, that the feedback loop is really important for how productive you are and how much focus you can have over how long a period of time.
00:25:55
Speaker
And I have a fun story with a project I was working on. where we were using TypeScript for the back end and ReScript front end. And the front end built really quickly and incremental built really quickly. And ah the back end started getting large and it kind of built. It took maybe sometimes seven, eight, ten seconds before you got things to kind of reboot and and you had type checking and everything.
00:26:22
Speaker
And I worked together with ah and a Java developer. And he was like, this is so fantastically fast, the 7, 8, 10 seconds. And I was on the other end, like, this is so slow. I can't lie.
00:26:36
Speaker
I keep going to to check the newspapers whenever i start compiling. So it's all about perspective, yeah essentially. Yeah, but it's it's definitely something you can get used to any compiler speed, but yeah I think things get chronic when you when you find that you've often forgotten what you were doing before you started compiling. Yeah, yeah.
00:26:56
Speaker
And that's ah a thing that I value a lot, and I've been reflecting on this a lot through the years. And for me, one of the most important things for me when programming is that I can stay in my focus, deep work kind of state as long as possible.
00:27:10
Speaker
That's where i when I can transfer ideas to my editor in a quick way and stay in thinking in the system and everything without interruptions. That's when I do the best work and when I can do much work for a long time.
00:27:25
Speaker
It's when kind of when I get slowed down or I feel friction around, oh, now I have to do that manually in order to just reach the next kind of step in in in figuring out what I'm supposed to do. That's kind of when I get much, much less productive and than just the time it takes to do the things manually.
00:27:41
Speaker
Because it kind of wears out the the enthusiasm for me for in programming. And I'm very driven by by being in a flow state and ah kind of zoning out from the outside world and and and just digging into a problem, essentially.
00:27:54
Speaker
Yeah, you want that constant and interactive flow with what you're building. Yeah, I want to be inside of the kind of the screen and just work on the the the thing I'm working on and they have all of these things float around here and think in the system and work everything out, essentially. And I want to be in there as long as I can, and because that's when things happen and happen quickly, essentially, with working.
00:28:17
Speaker
yeah yeah and And so for me, it is like the feedback loop is incredibly important because the second that's too too slow, it means I'm going to start doing other things and switch context then and everything.
00:28:31
Speaker
Yeah. And it's it's a small thing, but it actually has a fundamental difference on your experience of building something. Yeah. and I very much believe that that is a... a um A very important factor, originally I'm a behavioural scientist, so I started out, I majored in psychology and experimental psychology. It's not therapeutic. I bet that's not as exciting as it sounds.
00:28:54
Speaker
It sounds much cooler than it actually is. It just means that i don't like I don't know how to treat people, but I do know how to do experiments, essentially. um But I did a a a class in sports psychology or performance psychology that affected me a lot in my thinking, essentially. And it kind of ties into ah to this thing a lot and very well in that your goal...
00:29:20
Speaker
should be to stay to get into and stay in flow state as long as possible. And for those who don't know like what what flow state is, it's essentially that when you're completely engulfed in ah or consumed by a task that you're working on, you know how you can sit down and essentially forget the outside world for a couple of minutes, an hour even, if you have the... You lose your sense of time as you're just yeah completely swimming the problem. You're completely focused on just one thing, and you're focused deeply on that. And that's where like not all things that you do in programming is going to require flow state.
00:29:54
Speaker
But a lot of interesting stuff requires you to be in flow state in order to really, really think ah think things through and work things through. And that's something that that's what they work on in in in performance psychology and sports psychology, trying to figure out how do we get to flow state and stay in flow state longer.
00:30:11
Speaker
And I'm trying to... i think like... it resonates a lot with me in terms of programming programming as well. And maybe that's just how I work as a programmer, but I think like staying in flow state and getting to flow state, that's what but the focus should be, because that's when you're doing your your best work, when you're completely consumed.
00:30:30
Speaker
Yeah. problem yeah It's reminded me, for different reasons, i've kind of stopped using Clojure, but having a language that has a REPL where you're constantly in yeah conversation with the compiler yeah gives you that feeling. And I kind of miss that. yeah Yeah.
00:30:46
Speaker
But okay, so so give me some, tell me how this is done in Rescript. Because why what's Rescript doing that TypeScript isn't to make this fast? Yeah.
00:30:59
Speaker
Yeah, so like the the um there's a bunch of things. like a lot comes down to the type system being much simpler and much more predictable, ah yeah which which means that you can optimize the compation compilation a lot more, for instance. But there are just so many fewer kind of things few kind of things that the type checker needs to care about than what the TypeScript type checker needs to care about.
00:31:25
Speaker
at It's also written in OCaml, which is a very fast language, great for for building compilers, for instance. And that's been proven in this industry for long. The first Rust compiler was written in OCaml. OCaml itself is obviously written in OCaml.
00:31:39
Speaker
So it's ah it's a... So it's ah it's a it's a great language that's really fast as well. um So that's obviously also difference. TypeScript is written in in in TypeScript itself.
00:31:51
Speaker
Although, like honestly, i I would assume that yeah that is it is a big factor. But these days, like you don't know. You can write pretty fast JavaScript as well. And maybe it's not it's not always the whether the language is super fast or not that makes a difference in the end, and depending on what kind tasks you're doing, of course, and stuff. But does multithreading play into it?
00:32:10
Speaker
Is the OCaml compiler multithreaded? it is It is now, but we're not using any of it. The compilation model, though, makes a big difference because um there are no cyclic dependencies allowed inside of Rescript. There are in TypeScript. So you can always ah build up a a tree of the if most efficient possible compilation where you start somewhere and then figure out, OK, now I need to do these things. And the compiler in Rescript works on...
00:32:38
Speaker
each file in isolation and in parallel, so it can it can do as much work in parallel as s yeah as possible, essentially. um so So it can compile each file in parallel, you're saying?
00:32:52
Speaker
Yeah, the compiler for each file. Yeah, so it's not multithreaded in the sense that the compiler itself is multithreaded, but you run the compiler in isolation per file, and you can do that in parallel, of course. Oh, OK, yeah. Because it's stateless in that sense that when it does it, it takes a file, and then it produces an artifact from that file by using artifacts from other compiled files that it depends on and things. But it's...
00:33:19
Speaker
Oh, okay. So it's compiling... Is it compiling some kind of binary or is it compiling some kind of summary? Compiling a a binary. Binary version compile thing.
00:33:31
Speaker
Is that incremental? if i then che it if does it Do I need to recompile if I haven't changed the source? You need to recompile the things that, starting off from where you're triggering recompilation, you need to recompile the things that might have been affected by what you did, essentially.
00:33:47
Speaker
Okay. Okay. So anything that imports the file I've just changed? Yeah, and then there are there are like a multitude of things that are affecting this. like you could have There are interface files in Rescript, for instance, where you can put your type signatures, and then and that could speed up compilation by a ton because you would only need to check internally that the interface still holds. And if the interface still holds, you won't need to do anything else because this couldn't have changed, right? Okay, yeah, yeah.
00:34:15
Speaker
Yeah, I measure imagine you've got... because ah To hark back to something I said earlier, it's like... um one of the reasons The big reason I thought originally that TypeScripts and Flow would fail, i admit it, I was wrong, happily wrong, I thought they would fail because the scope of JavaScript, the language, designed as it is, untiped and with some documented specced bugs, the surface area of what a compiler for that has to do is so huge that
00:34:48
Speaker
yeah I thought they'd never be able to type check everything. Maybe it sounds like you're saying they can type check everything, but they're just optimizations they're not capable of making. Yeah, I think... um I think they've um they've gotten very, very far in terms of how much they can type check. But it's also a matter of type checking how much can you figure out by yourself as a compiler. Like how much can you actually figure out without having the developer have to tell you what what types you're expecting something to be and those things. Oh, like inference.
00:35:20
Speaker
Yeah, inference. Rescript has, um has but just like Okama, has fantastic inference, where depending on kind of how if you like how you design your program, you might not have to write any annotation at all, essentially.
00:35:32
Speaker
And this is another thing that's that's very important to me personally, because it most Rescript code snippets that you look at, unless the person has wanted to annotate, is going to look much more like JavaScript than TypeScript in the sense that there won't be a bunch of annotations around for four. four And it's still going to work.
00:35:51
Speaker
um And that's a very important thing, looking back to the kind of flow state and and those things, in that writing annotations, unless it's important for the task I'm doing, but writing annotations just for bookkeeping to the compiler is a manual task that does slow me down and cause friction, right?
00:36:07
Speaker
Yeah. Yeah, so yeah if I can avoid that, I can just focus on writing my code, understand that the compiler is going to help me. It's going to infer things. i'm going I know how I can make it infer things the way I want it to, essentially, and how to structure my code without having to tell it explicitly what everything is.
00:36:26
Speaker
ah yeah Outside of the parts where I tell it because this makes sense for maintainability, might be much easier to scan the code if I have a type annotation here, for instance, to tell it. um If I can avoid that, that's another thing that's not going to slow me down and pull me out of flow state, essentially, or or not allow me to get in it. Because i'm so i'm I'm going to be able to focus on writing my program and my logic, not bookkeeping for the compiler, essentially.
00:36:52
Speaker
Yeah, yeah, because there are at least three flavors of type checking, right? There's type checking in order to please the compiler. yeah There's type checking for us humans. And there's type checking because there is a genuine argument about what's right. Yeah, yeah exactly, exactly.
00:37:07
Speaker
And that's that's another thing that people, um when they come back to... types usually miss a lot in that typescript because of like again typescript is is fantastic and it's uh it's uh it's amazing what they've been able to do and but the way javascript is like the task they have isn't it's not super nice to type javascript right yeah yeah so so typescript people must have said if only we could change this one thing about javascript our lives would be easier yeah Yeah, I would assume
TypeScript's Popularity and Challenges
00:37:38
Speaker
so. And also, like they are so since half the world is using it, if not more, they're probably so incredibly swamped in just trying to figure out how to get to the next day in terms of there are so many people using this and all of these weird kind of problems surface face because there are so many people using it. Essentially, like how do we how do you figure all of this out? so like yeah
00:37:58
Speaker
Must be terrific for finding bugs, but yeah bit of a headache at some point. Yeah, they're probably going to find any like every bug there is, which is cool. um But yeah, this is another thing that like when you come back to that you're you're you're usually missing. And and um again, like part of it is is because TypeScript is trying to do what it's trying to do. It is very hard to infer...
00:38:22
Speaker
what JavaScript, what you're trying to do in JavaScript, because there are 10 different ways of doing everything in JavaScript. And there are very loose type rules around. You can use a plus for concatenating strings or adding numbers together and a bunch of other things that like make it hard to type check without making a statement in terms of, oh, we think this should be this.
00:38:42
Speaker
um Yeah, yeah. like You're making me think of like, doesn't I think I'm right in saying that string, if you've got a string that's a number, string plus an actual number has a different type result than number plus a string number, yeah depending on the order of the arguments to the plus operator. like Exactly. that's it Yeah.
00:39:02
Speaker
that is um That is something I'm glad I don't have to deal with as a compiler kind of contributor, so to speak. But but again, like there are all of these things in in TypeScript and and JavaScript that's not like not TypeScript's fault at all. This is just how JavaScript works, right? It's just how it how it how it how someone made it back in the day.
00:39:23
Speaker
And that can't change because the entire, or half of the world at least, depends on it, so to speak. and And it leads to kind of all of these... small paper cuts in, for instance, truthy and falsy values. like It's pretty common to use truth and falsy values for doing ifs in TypeScript.
00:39:43
Speaker
But sometimes you get tripped up by the rules and you make a comparison that might not be the comparison that you you're making, a com comparison that's not the com comparison you think you're making, essentially. And the little bug comes in there, and it's really hard to figure out at a glance.
00:40:00
Speaker
And Rescript is strict in the sense that you can't compare a string to an int unless you make the string an int or the int the string, essentially. You can't do an if on something that's truthy, whatever that means. and um and You have to make it on a Boolean, essentially.
00:40:17
Speaker
So it's annoying when you start out and when you're used to just being able to do a truth check, for instance. um But it kind of adds up as you move along and use the language for longer because you don't have these kind of weird bugs anymore. And anyone who's worked with React Native, for instance, in JavaScript, especially back when I don't think this is a problem anymore in the same sense that it was. um But um since there are no since not everything is an expression, like in RedScript, for instance, you end up either using ternaries or and-and operator to kind of to do conditional rendering.
00:40:56
Speaker
and Right, yeah. Yeah, and for those of us who work with UI, I'm originally a front-end developer primarily. We know that building UI is just conditionally rendering stuff. That's all it is, right? That happens a heck of a lot, yeah. yeah Yeah. so so um But if you don't have the tools for it, kind of weird stuff can sneak in. And and but back with React Native, the the thing is like you use the end end operator AND to conditionally render something. If this thing is true or truth in this sense, then return this other thing.
00:41:28
Speaker
yeah otherwise return undefined, which is the kind of implicit paper. um And in React Native, the pro like the the app would crash if you tried to emit certain things inside of the text or inside of the React kind of element tree.
00:41:44
Speaker
um And there was a common pattern people used where they would sometimes accidentally end up with zeros being emitted because of how the AND operator works. Mm-hmm.
00:41:57
Speaker
which would crash the app. And this has happened to me in production a bunch of times as well, back in then. And that's that's also kind of thing that you, sure, you have to pay the cost in that it's you have to think a little bit more about what am I actually comparing here when it's strict.
00:42:12
Speaker
But still, like you don't have those types of bugs where what you're doing isn't really, what you think you're doing isn't really what you're doing, essentially. Yeah, yeah. And it's kind of the hard to figure out. Yeah.
00:42:24
Speaker
It shouldn't come up because you should think more clearly every time you're using the operator. But yeah if it's a thing where you need to be infallible as a human, the computer should be doing it for you. Exactly, yeah. And it's also hidden. like it's it's because you have um you you may it's Maybe it's a surviv it a variable that you you do your end-end on.
00:42:43
Speaker
And in a code review or whatever, just looking at the variable, yeah, I mean... probably fine, right? Whatever's in that variable in runtime, who knows? but Essentially, yeah. so So it's hard to kind of catch as well.
00:42:58
Speaker
But now there are but like there are lint rules for that as well. And I think it's been fixed in React Native as well. But that's that's one of those things that kind of, because you don't have the tools to do inline pattern matching, which you might have wanted to use in this case instead, you end up doing this other kind of um method using this other kind of method that's really not safe.
00:43:19
Speaker
and will not where you You don't fully understand how it's working, but it's working as you want it to in 90% of the cases, or 95%. But then the 10% or 5% case comes along and kind of ruins your day, and alarms go off, and you have to wake up and go fix things and submit to App Store.
00:43:34
Speaker
Yeah, you don't want to program by workaround if you can you can avoid it. exactly Okay, so since you've mentioned React Native, I want to move on to this because um what's the story for interacting between Rescript and things like React, React Native, Vue, any JavaScript library?
Rescript's Front-End Focus
00:43:51
Speaker
What's my interop story?
00:43:52
Speaker
Yeah, so one of the goals of Rescript that we're working towards is that this should be as interoperable as we absolutely can make it with JavaScript.
00:44:03
Speaker
So today, if you want to try Rescript in your TypeScript JavaScript codebase, which is something that we we very much think that like we're not We don't want you to think that, oh, let's throw everything out and just use Rescript.
00:44:15
Speaker
No TypeScript, no no JavaScript. like There are perfectly valid use cases for using just JavaScript or using TypeScript. we don't like We don't care about whether it's that you're using it only or using it together with other things. We want to make it as easy as possible for you to just get started and use Rescript together with everything else. and So it's a single MPM package that you install through your regular kind of MPM workflow.
00:44:38
Speaker
the compiler, and then you set up a config file and the rescript file, and then you compile and it spits out JavaScript in a separate file that you can just import inside of your TypeScript and the other way around. You can import ah JavaScript and TypeScript by by writing bindings from the outside world. So integrating um integrating your TypeScript inside of your TypeScript or JavaScript app is a five-minute thing, essentially, which is one of the very important things for us.
00:45:07
Speaker
OK, so to make sure I've got this, for Rescript to JavaScript, it's emitting JavaScript anyway. So that's fine. so For JavaScript to read, to call JavaScript from Rescript, I need to get like annotate the types in Rescript syntax?
00:45:22
Speaker
Exactly. You need to write bindings for them, which is a pretty easy process. And something that we're, we're because this is one of the the the the hurdles that's left for us, like figuring out the binding story. Well, it's like,
00:45:35
Speaker
It's always something that trips up and people who are new. But once you kind of learn the ropes, it's pretty convenient and easy. And you can you can write bindings easily for for for most things. But still, it's something that we really want to improve and to make that story better as well. And when you go from Rescript to JavaScript, you obviously just use the JavaScript files that are emitted. They will look roughly the same as the other JavaScript you have in your project. But when you want to go to TypeScript, there's also, built into the compiler, a way of generating TypeScript types.
00:46:05
Speaker
Oh, okay, that's useful. From your Rescript. Yeah. And that's also something that we're working to... It's working really well today already, but we have a few tweaks we want to make to it to make it even like better. And that means that you can export things from your Rescript file and get actual TypeScript types and types ah typed experience and from TypeScript. Okay.
00:46:26
Speaker
Yeah, but the intro story with... So like we want to make it as... We want to be a part of the JavaScript ecosystem. We want you to be able to use anything from MPM and everything. Currently, you have to write bindings, of course. But other than that, it integrates like the JavaScript you produce. it ah You send that into your build step. You send that into VIT or Webpack or whatever it is that you're using.
00:46:45
Speaker
It's all like inside of the the normal workflow that you have. um And for React and React Native, we have a ah good experience around JSX. It's first class in the language.
00:46:58
Speaker
yeah So it's actually built into the parser itself, and native support for JSX. so And we've spent a lot of time making the interop story with especially React as good as we can.
00:47:13
Speaker
So I know that there are lots of people who use it with React primarily, but also with React Native. um So that works well. ah In terms of Vue and Solid and Angular and stuff, we like some of it is usable in a good way if it's using JSX.
00:47:30
Speaker
But things like single file components and other things that Vue has, for instance, and other tools as well, is is currently you have to kind of compile your Rescript to JavaScript elsewhere and import it into your single file. So it's not the seamless experience that you'd have in in normal Vue, so to speak.
00:47:48
Speaker
yeah And again, like it's it's something that we our goal is to to be perfectly interoperable with JavaScript. so So this is something that we eventually want to solve. But what we've also realized is that we need to focus on selecting a number of use cases that are um important and then do them really well.
00:48:10
Speaker
And that means that we focus our energy on those and then we will get to everything else also, like eventually, but we have to we have to start somewhere. And you know again, like going back to as being in a trust deficit when you you want to like introduce us instead of an industry standard at some place.
00:48:29
Speaker
we need to make sure that the experience of doing that introduction is as good as it can be. So we try and focus on a few use cases and then master them, and then we move on to others as well, essentially. That's fair. That's fair.
00:48:44
Speaker
For a project with finite resources, that's fair. Yeah, yeah. It makes me think then that... It sounds like one of your big targets that you're currently working you're actively working on is um what React. I don't know whether the name dropped from my head there. React and React Native.
00:49:04
Speaker
is it Would I just use it for the front end? or would Because you said you were on a project that was um re-script on the front end, TypeScript on the back end. Could it have been type re-script on the back end?
00:49:15
Speaker
Yes, very much so. But again, moving back to the use cases, I use Rescript in in the a number of projects on the back end as well. I know several companies use it on the back end as well. But going back to focusing on single use cases, we focused on the front end first, essentially.
00:49:30
Speaker
But it's it's all just JavaScript, right? So you can use it in the back end perfectly fine. What am I going to miss? Am I not going to find the type the type definition bindings of popular libraries? is that Yeah, exactly. You're going to find less less ready-made bindings, essentially. That doesn't sound like too big a deal.
00:49:53
Speaker
Yeah, it's it's not too big a deal, but it's also a matter of the kind of ecosystem thing. like So um and you'll find less like ORM bindings, database stuff, like those types of things. Although I've been trying to work on that as well. I have several projects, again, like that that uses Postgres databases, SQLite, all of those types of things, and does it in a pretty pretty nice and typed way. But it's it's a matter of that part of the ecosystem not being built out as as much as the front end has been.
00:50:23
Speaker
ah so So it is an ecosystem thing rather than the language itself. Yeah, there's not like ah in terms of in terms of Rescript and interoperability with JavaScript, there's nothing there's nothing lacking, except that it would be nice to kind of have generator functions or something ah closer to that, like yeah it cetera better iterator support, which you use more in the back end than the front end. But still, it...
00:50:50
Speaker
There's nothing missing in in terms of that. It's more a matter of ecosystem, I would say. Okay. That makes me wonder things like ah async. yeah Do you have async support?
00:51:01
Speaker
Yes, we have native support for async await, the same as in JavaScript. okay So it's the exact same thing, with a little twist. So the the cool part about async await in Rescript is that you can switch directly on an await expression and you can handle actual promised rejections through handling exception rejections in your parity matching, essentially. Okay.
00:51:22
Speaker
okay So that's another thing that's kind of an ergonomic or not asergonomic as ergonomic as it maybe could be in JavaScript, that in order to handle like using asic and wait, you have to wrap things, your wait, in a try catch in order to catch that potential promise rejection.
00:51:41
Speaker
And then you have to to use var for ah for the scoping or you have to have a predefined let variable to assign the await result to. But if you have a predefined let variable, if seeing as TypeScript can't really infer what it is, you have to type it right away what it's supposed to potentially be.
00:52:00
Speaker
right So there's lots of steps involved. But then you have your try catch and you can handle the promise rejections and and things. But in Rescript, what you would do instead is you'd write you'd write a switch for pattern matching and you'd await your value directly in the switch. And then you could handle the promise rejection as a JavaScript error, which is the same thing that you're doing try-catch as just a branch in the pattern matching.
00:52:25
Speaker
And what's emitted is still a try-catch, the same thing that you'd write by hand in. Does that mean I'm going to get exhaustiveness checking for the error side of async code?
00:52:36
Speaker
and you Yeah, you'll get exhaustiveness checking for that. And there's also another interesting thing that we haven't built out as much as as I would like, but that we'll also get to eventually, is there's a yeah tool called reanalyze in Rescript, which is a static analyzer for your entire code base that can detect dead code, unhandled exceptions where you might end up with exceptions that you haven't handled and that type of thing.
00:53:03
Speaker
And that is a really cool thing that I also miss immensely whenever I go back to TypeScript. Because and the the background for reanalyze is that since the TypeScript type system is sound in the sense that if it compiles all the types agree, and all of the positions in in your files have actual types, right?
00:53:23
Speaker
So there are no there are no and there's there's no ambiguity in in and the types themselves. You can always figure out exactly what and what something is at a position, um as long as it compiles.
00:53:33
Speaker
OK. So given that and given how kind of records in Reskip works, where it's a nominal kind of shape, re-analyze can figure out things like, oh, this everything from like oh this value this function is never used.
00:53:52
Speaker
So this function this argument in this function is optional, but it's always supplied everywhere. So you could make it ah not optional if you wanted to. yeah It can figure out, oh, you have this this record. Let's take the user example that I used before.
00:54:06
Speaker
name and Name is a string, and age is an int, for instance. Oh, you have this this this user record. um you're never actually reading the name field here. So you could just you could just remove that. Nowhere in your app are you reading your name field.
00:54:21
Speaker
um Or the other way around, like you're never actually constructing. um If you have a variant, for instance, and you have ah multiple constructors for that variant, oh, this this variant you're never constructing.
00:54:31
Speaker
Okay, that's quite advanced. Yeah, it's advanced. And and the the big thing that I use it for is it makes cleaning up stuff so much easier. Because you can literally go into codebase, switch that on, just get thousands sense of errors probably around like things that are dead or... or And then you can just go through it and remove one thing at a time, remove, remove, and just understand things, find things that we've... like I regularly find bugs around, oh, this thing that I wrote the helper here, but I forgot to use it, um for instance.
00:55:07
Speaker
andnna Oh, that's that's a bug. like Yeah. I probably had an idea with with writing that those types of things. And that's been ah an incredible help. But it's also cool because you can kind of build tooling on top of that because Rescript can figure out or reanalyze can figure out exactly what from a record that's actually used throughout your entire program. Doesn't matter if it's in the same file or if it's passed through a number of files, it's still going to be able to figure it out. So I, for example, I use GraphQL a lot and I i have a Rescript project called Rescript Relay, which is bindings to
00:55:39
Speaker
Yeah, it's going to be very front-end now, but bindings to Facebook's Relay GraphQL client, which is a very advanced and, in my view, a great client for building UI, essentially. And but the big thing in Relay is that you you kind of co-locate your data dependencies with the code that's actually using them. So um you you write GraphQL fragments. Sorry for everyone who's not familiar with GraphQL.
00:56:03
Speaker
But still, you write fragments where you essentially say that, oh, this code down here, it's using... ah it's selecting fields from the user and it's it it needs the name and it needs the age.
00:56:14
Speaker
And maybe yeah needs the best friend and the ID of that and the age of the best friend, something like that. So you kind of... Yeah, it's almost listing which bits of data you export, right? Yeah, exactly. so it's kind of like, it's I like to liken it with, it's like the component model, and but for data, essentially.
00:56:31
Speaker
You have your... You define your kind of props and then you... You select those, and that's what you end up with getting inside of your components. um So you define your data, and you say that say that we're working on an avatar component here, and I want to render the name, obviously, in the avatar.
00:56:47
Speaker
ah So I have i select the name, and I select the avatar yeah URL from from the type user from my API. Fine. like That works well. um But then I i stop using...
00:57:00
Speaker
the name. I no longer need a name. like I just need an avatar URL. I remove the hover or whatever on my avatar. and Now I have to remember to also remove that selection from my data, right? Yeah, yeah. Otherwise, it's going to overfetch. In this case, it's not going to be a problem, obviously. It's just a name. But still, like you could potentially and forget to remove selecting heavy fields that are like expensive to compute and those things. yeah, yeah.
00:57:27
Speaker
I have definitely seen this in startups where but they go through the first couple of years and the product has evolved a lot and changed a lot. And we have no idea which bits were old experiments that have actually long since died. Yeah, yeah. yeah and this is like this is the type of thing that I just love in that...
00:57:45
Speaker
this this is what happens in reality, right? It doesn't matter how how like how smart you are or how used you are to to building stuff. It's the same with me. i'm ah like I've built but a bunch of things around this tooling.
00:57:56
Speaker
I should be very mindful around removing things I no longer use. I still find stuff all of the time that I forgot to remove and old experiments and whatever. So like, it's again, like to what you said, like the the machines have to help us with this, right?
00:58:10
Speaker
Yeah. we We need help. They are diligent in a way we can't be expected to be. Yeah. And honestly don't want to be like, I want to be in my flow state and then I want someone else to come and clean stuff up. Right. I want do like what what I'm good at and then, then have a bookkeeper come in and fix that or whatever.
00:58:26
Speaker
Yeah. Yeah.
Enhancing Developer Workflow with Tools
00:58:27
Speaker
So this tooling bit, but what it can do, thanks to the type system being sound, for one, so that if it compiles, everything has a type. it You can trace any type throughout the type system.
00:58:38
Speaker
and Thanks to that. And also thanks to reanalyze and a couple of other things around GraphQL. um There's a CLI in the Rescript Relay project that and can take your entire... um but all of the selections inside of your GraphQL and figure out, is this actually used inside of your application? Are you accessing this anywhere, this type? And if not, it can automatically remove those things from your GraphQL selections.
00:59:04
Speaker
And you can put this in CI, which means that you'll never ever ship any overfetching from production, right? Oh, nice. So that's that's one of the things that is... it's it's I think it's cool technically also, but it's also like for me as a developer and as someone who needs to care occasionally about not fetching too much about servers and whatnot, like it's it is massively useful in the pragmatic sense that this makes a difference in the real world, so speak.
00:59:34
Speaker
And also what you what you mentioned about old experiments and stuff, that's also ah one thing that we regularly get feedback on when people start using reanalyze in their code bases.
00:59:45
Speaker
Oh, this old thing. and we We kind of... yeah Been a while since I see this. Obviously we don't use that, but it's also important for newcomers that there's not a bunch of code lying around that they try and understand that's no longer actually... Yeah, it's all mental overhead that you didn't need to spend. Yeah, yeah.
01:00:01
Speaker
Yeah. As well as network bandwidth and everything else. Yeah. So like to to to wrap up this long, long um sidetrack on Reanalyze, the cool thing that we want to explore more with it is that since it can track...
01:00:13
Speaker
um Exceptions also, like, oh, here's code that might throw raise an exception. You haven't handled that exception anywhere. and Please either tell me that you don't care about handling it or handle it. That's kind of what re-and-a-das can do.
01:00:27
Speaker
It can do that same thing for promise rejections, right? So it can do the same thing for async await. Make sure that you've handled every possible potential promise rejection as well. Something that's pretty hard in in regular JavaScript or TypeScript to kind of do and track.
01:00:42
Speaker
Yeah, yeah, definitely something I would want done. Yeah, yeah. There's too much programming just for the happy path. Yeah, exactly. And that's, the I guess, like one of the main criticism of of async await, that it's very easy to do happy path things. It's hard to to do um error handling because you have to, in JavaScript, then wrap it in a try-catch, for instance. And that, it's again, like, it's...
01:01:07
Speaker
It's both more code, but it's also it's also another step that you have to take that people are going to not take because, yeah, if I can do less work, then that's usually good as well, right? So people are going to forget about it. It's going to sleep through reviews and everything.
01:01:20
Speaker
but So what we're trying to do there is is, given the things I talked about in using a switch on the await and stuff, it's much easier to handle the case like the the errors as well.
01:01:32
Speaker
So we're trying to make async await slightly easier better as well in Rescripts. In addition to, its it emits an actual async function in JavaScript then actually waits and stuff. so yeah Yeah, because this is why I like to use typed languages, because I want to get my problems up front.
01:01:50
Speaker
If there's going to be a problem, I'd rather find out today. Yeah, yeah. Unlike most of the rest of my real life. But in that one respect... There's one time I want this too. Okay, so I have to ask, I have to dive behind this because I'm curious. Because you said you were a JavaScript TypeScript reactor.
01:02:09
Speaker
Tell me about your journey going from that to now being something of an OCaml compiler tweaker? Yeah. How deep are you in and how did you get there? It's it's a long story. So, like, I... am I've always been very technically interested, so speak. I made a decision early in my life to use Linux, and which means meant I got to move system files around while my friends got to play computer games, which I couldn't play because the state of Linux back then wasn't really good, yeah um essentially. and
01:02:43
Speaker
i did like I enjoyed that still. I enjoyed the technical parts. i like There's nothing quite like the feeling of power from moving a file inside of the terminal, especially if someone else looking that doesn't know how to do it immediately like end up as the hacker.
01:02:59
Speaker
Yeah, you feel like a proper old school hacker. Yeah, yeah like the world is my oyster, is my feeling after after doing that. um but But so I always started, but like i enjoyed that. i did the You mentioned the guitar back here. I did a lot of like yeah music production back in the day as well. And i i used I decided to use open source tools for that, which was really cool. I got to be in a very cool community, which is the Linux audio community, filled with brilliant people who are very good at digital sound processing and and very driven by the open source kind of thinking and and everything around that.
01:03:35
Speaker
ah Amazing time. and But then for for so i like at that point, i I learned to help out in open source projects, not by programming. I did some programming too then, like back when PHP was a thing and you made guest books in MySQL and those types things.
01:03:52
Speaker
Back when CSS wasn't a separate file, it was always attributes on the DOM node, essentially. I think the pendulum is swinging back that way at the moment, isn't it? Yeah, yeah. I love it. and my All my knowledge she is certainly back.
01:04:06
Speaker
coming back um But yeah, so I helped out with like debugging yeah various C++ plus plus programs for crashes and stuff like to try and help out. And I always liked it.
01:04:17
Speaker
I always enjoyed the technical parts. But then when I came to choosing what to study for university, I had this kind of angel-devil kind of thing where it's like, oh, sure, you can go and be an engineer. And that's the obvious path. And you'll be stuck at that computer the rest of your life.
01:04:34
Speaker
you want to do that sure go ahead um but i actually ended up uh choosing behavioral science instead uh so like i mentioned so i studied psychology uh essentially but then towards the end of the program i i that devil kind of switched sides and was like oh but you'll have all of this like interest in technical stuff are you going throw all of that away like you should you should just you should do do something that's like tailored towards um combining technology and and um and behavioral science, essentially. And back then, UX started becoming a thing, but it wasn't really a thing like it is today.
01:05:13
Speaker
and So that wasn't an obvious path. So I did kind of a web experiment in my my master's that led me into working with WordPress and PHP and stuff. And then when I came out into the the job market, there was two jobs for as a behavioral scientist and like 2,000 jobs as a developer, so to speak.
01:05:31
Speaker
and Yeah. So I kind of got into into that from the side. and and I always known that if i If I get hooked on programming, I'm probably going to enjoy it very much. Like it's it's it's very aligned towards like what I like to do. Again, the flow state stuff and and and everything around building stuff and thinking thinking about things is nice, right? But also like thinking about things that actually I'm not theoretical in the sense that i like to think about theory too much. I like to think about how to do things in the...
01:06:03
Speaker
real world, so to speak. Yeah, you want the brain food, but the kind of brain food that leads you to actually seeing a real world result. Yeah, exactly. So so i'm very I'm very much a a yeah a product engineer, so to speak, and I still am. like I'm very much focused on, i want to build things and I want to build new stuff. I want to understand what...
01:06:22
Speaker
and what users need, what they think they need, and so on. That's very much my focus. yeah So i got into I got into programming, and this is now 10 years ago or so, 11 years, yeah and and just slowly moved deeper and deeper into it. And as I told you, i kind of ended up, I used JavaScript and React came out. I was using Angular before.
01:06:46
Speaker
My first impression of of React was, oh, ah I never want to use this ever. This looks terrible. And then I ended up using it. like It ended up being fantastic. that was like I don't think it was a too uncommon view of React back when it came. Yeah, we must learn as programmers not to absolutely trust our first instinct. Yeah, just super judge right away, right? Yeah, yeah. Yeah.
01:07:08
Speaker
um But yeah, i so as I moved deeper into JavaScript, I saw Flow and TypeScript. But back then, Flow was the thing. like TypeScript wasn't at all as good as it is now, of course, but not even it wasn't close to Flow either. Back then, flow was really the Facebook had all of this hype around React and and everything in open source. and And they came with Flow, and that was kind of universally...
01:07:33
Speaker
what people looked at, essentially. so I started looking at Flow, and I had the experience I told you about before that, oh, this is so nice. I can see things before it kind of I get paged in the middle of the night. I can see things in the build step instead.
01:07:45
Speaker
And there are nice nice colors in the editor, and it tells me right away what's talking to me, kind of. Yeah. That was my experience. But again, like i had I didn't have any experience from typed languages before right in ah in a larger sense. So the the fact to have something like a compiler tell me what's wrong was an experience that was really nice and something I hadn't really had before.
01:08:07
Speaker
The browser console used to tell me what's wrong otherwise right with big red. Oh, blah, blah, blah, and the find is not a function or or those things. yeah But yeah someone actually telling me inside of my editor, there was ah that was a a new experience.
01:08:19
Speaker
um So I started moving into Flow, started using Flow for all the things. Again, TypeScript wasn't a thing back then. um And then came ReasonML and Buckelscript.
01:08:30
Speaker
um And i I started looking into that. This must have been around 2018 or 2019 when I first got into it. Started looking into that, started looking into like um the parts of OCaml I needed to understand to kind of understand what ReasonML was and what Buckelscript was. And kind of... and thought that, OK, if I take a few steps back and I look at what this is compared to what flow is and where so where flow is going, this thing, ReasonML and Bucscript, looks much more like the thing I would want this other thing to eventually become, right?
01:09:05
Speaker
Inference, strictness, pattern matching, variance. It just felt like this is the end game for this other thing, for me, at least, essentially.
01:09:17
Speaker
Yeah, I can totally appreciate that. Yeah, so that was that was kind of my entry to it. And then i as I started trying to work with Bacuscript and ReasonML, I hit a major wall, and which is, I don't think, uncommon, still not uncommon for for people coming to either languages. But speaking of Reescript, it's not at all uncommon that people come in and...
01:09:37
Speaker
and they hit a wall. And my experience was kind of, OK, I know all of this JavaScript. I think I'm pretty good at JavaScript and and flow then back days. Here I'm in a new language. Everything looks cool. I can read code. It's readable. I understand when I read it.
01:09:52
Speaker
I don't know how to filter or map an array. Like, how do I do it? I have no idea. And I look in the docs, still doesn't quite click for me.
01:10:03
Speaker
So I had in like an initial hump and where where once I got over that, I started seeing the light, essentially, like and and everything, all of the benefits. But I did have a ah major hump, so I'm pretty glad that I stayed with it and tried to try to understand um things a little bit in depth. But that was my prevailing experience. and am but That experience is something that we're trying to, it's always going to be there in some certain sense, right? It's another paradigm. You are going to hit or like you might, some people make it over perfectly fine.
01:10:35
Speaker
Yeah, but the odds of hitting that point where all the stuff you've got a familiar pattern in your short term memory for, you've got to relearn that stuff in a different way. Yeah, exactly. And and you're in a the the thing that bothered me the most is that I know all of these things. Like I can build UI in whatever. I can work with the DOM. I can do this. I can transform data.
01:10:56
Speaker
I can do that in in in JavaScript. I'm not learning a new thing. I want to do these same things, right? But I just don't know how to do it in the language. And there's just no obvious...
01:11:09
Speaker
like it's not clicking as as fast as I hoped it to click kind of. yeah yeah So that's very much ah an experience I take with me and and where we work in Reescript to try and again minimize the odds. Like you are probably, you might hit a wall, but we're trying to make that wall much softer, smaller, and kind of less likely to to actually be hit. um That raises one question, which is how?
01:11:31
Speaker
Yeah. Oh, and so many different small things we do to try and make that more. I have a ah very recent example that let's hope I can and explain this in an understandable way. But for those who are familiar, like Rescript has pipes.
01:11:47
Speaker
yeah That means that you take yeah the result of something or you take a variable, you take a value, and then you pipe that into a new function yeah that that you call with maybe some some other functions.
01:11:59
Speaker
arguments as well, and then you pipe that result into a new function, you get this nice long pipe chain ah that the equivalent in JavaScript would be method chaining an array, for instance, where you have a filter, array map, then now you have a map, and then you have a join. Yeah, exactly, that thing.
01:12:16
Speaker
But in in in Rescript and in other languages that have the same functionality, you can do that with any function. It doesn't have to be something on the prototype. You don't have to wrap it around. like It kind of inverts how things look.
01:12:28
Speaker
If you look at an example, if you don't know this from before, if you look at an example, you're going to see right away kind of what it... how it simplifies things. And this exact same experience I had, where I had an array of something and then I tried to map and filter that inside of what was back then in BucketScript and recent ML.
01:12:52
Speaker
Like that that that same experience is It's like very common when you come from and JavaScript. Because you you usually map and filter arrays, right? yeah um and But in in Rescript, you do the same thing. You can you can map and filter arrays. Don't worry. like it's It all works. But you do that through piping instead. So instead of writing myArrayVariable.filter, you're writing myArrayVariable.pipeArray.filter.
01:13:20
Speaker
So you're calling a function through the pipe on the thing that you have. And this has the added benefit of... It's actually pretty clear when you look at code, even though there aren't type annotations, you can see that, oh, you're you're doing an array map because it says array map right ah inside of the code as well.
01:13:35
Speaker
yeah So it's nice. but But discovering that thing and and making the um connection that what you did with the dot before... It's the same thing that you do with a pipe and the module name plus function, essentially.
01:13:48
Speaker
Making that connection takes time. And it's not obvious. but When you're in my back, Gabriel, from 2018, and you you try and do this this filter, there's literally nothing helping you to figure out and that you're supposed to write pipe array dot map.
01:14:06
Speaker
Nothing yeah whatsoever. Maybe it's somewhere in the documentation, but that's hard to Google for as well, right? Yeah, exactly. You're going to find it in the documentation. You're going to be able to dig it up. But there's nothing in my editor. There's nothing helping me out. There's nothing telling me that I can do this.
01:14:18
Speaker
There's no immediate flow state feedback. exactly yeah so i get stuck kind of yeah uh so uh and we still like we've uh improved things somewhat in risk by making sure that pipes if you write the pipe you get all the completion from the main module of the type that you're piping on so if you have an array There's an array module available that has all of the like filter join and map stuff.
01:14:44
Speaker
um So if you do if you write a pipe after something that's an array, you're going to get completions from array and have array map, array filter, but blah, blah, blah. Perfect. like You can now see that these things exist. So that's one of the big things. And actually, a developer experience thing that i'm and we we in ReScript are like really proud of because that makes...
01:15:04
Speaker
makes it you can also tailor that kind of to your own types and control autocomplete for your own types and make sure that like the experience is nice ah for the developer. but That will also work when you've got a custom type with your custom library. Yeah, it'll look inside of the... And you can even... Recently we've added that you can even configure your type to say that, oh, also draw completions from this other module if this is the type that you're piping on, and charlie or or these other two modules, essentially, so you can have have it draw from from... And we plan on doing more autocomplete...
01:15:34
Speaker
customizations, essentially, that you so you can tailor your experience more to your project and stuff. um But yeah, but' going back to... So where we did that improvement and that's good, that's great, that's helpful. But you still have to understand that you're supposed to do a pipe here, if you want to do what you want to do.
01:15:49
Speaker
You're used to doing a dot. You have to understand that you've got to write the pipe to get the autocompletion right. So there's still a step left yeah in order for this to be obvious. So what we've worked on now, and that's inside of our review or preview VS Code extension, is that now if you have yeah have your array variable, if you write a dot, you get completions but from pipes.
01:16:13
Speaker
So we've kind of taken the pipe the pipe, the thing like the behavior that you're used to. And when you do that behavior, you're going to get completions. It's not going to be a dot. It's going to remove the dot and insert a pipe instead than the thing that you select.
01:16:26
Speaker
But still, like your way into this is still the same thing or can be the same thing. The regular pipe still works, of course. So you're actually explicitly generating LSP code actions tailored towards someone coming from a different language.
01:16:42
Speaker
Yes. That's first time heard of someone doing that. Yeah, see how much people like this. But but like it's ah it's a ah for us that try to be pragmatic, try to understand our target group, try to make it as easy as possible to both sell this to your colleagues, sell this to your boss.
01:17:03
Speaker
have it yeah like It's so important that you have a ah good first experience. and or or a good first week a couple of weeks, essentially, when you work with this. like That's going to massively and improve the chances of you sticking with it and keeping it around in your company and everything.
01:17:18
Speaker
like We have to do what we can in order for this to kind of work out. And I use it still because it's one less character to type, and it doesn't really matter. A dot is one less than the pipe, essentially. So it's also um that kind of thing.
01:17:32
Speaker
But yeah, so that's that's ah I think that's a pretty good example of what we're doing to try and make it easier. And it's again, like I want to highlight that this is something that It's not changing anything in how the language works.
01:17:48
Speaker
If you leave that dot in there, it's still not going to compile. It doesn't change anything. It's just a tooling thing that can help you kind kind of understand things quicker without necessarily costing anything for the one who doesn't use it, right? It's just an
Community Influence on Feature Development
01:18:07
Speaker
addition, so to speak.
01:18:08
Speaker
yeah and then yeah Yeah, totally. Yeah. so so but what So I have to ask, what's your role in that feature? Are you are you the behavioral psychologist figuring out that we should do this?
01:18:22
Speaker
Are you the person hacking on the LSP server to make it actually work? Yeah, the latter. The idea is from a great new community member we have who who kind of, it comes from...
01:18:34
Speaker
from redesigning the bindings to the DOM API. That's also been a a major... We have some great open source bindings maintained by the community for that, but Rescript has evolved a lot since ah since those were made, and there are a lot of like new features that you can use in Rescript that makes it feel more idiomatic and makes the developer experience better.
01:18:55
Speaker
So while trying to figure out how can we do good DOM bindings in a more idiomatic Rescript way, we kind of hit a wall with... There are like overloads and and stuff in the JavaScript APIs, right? There aren't too many of them inside of and the DOM API, but since RedScript doesn't have any overloads, you can't define multiple fields in a record, for instance, and that points to the same underlying thing but has different and
01:19:29
Speaker
different types, you have to define ah function instead that works on the the main type and that has like different functions for different overloads, essentially. um Oh, so you have to wrap the different overloaded versions in a kind of dispatch? Yeah. Or rather, like you make distinct functions for each case. So if you have an API that can either take a string or an int, you could do two functions.
01:19:55
Speaker
myAPI string, myAPI int, and they would take either a string or an int, and that's how kind of you... they would bind to the same thing in JavaScript. They would emit the same JavaScript code, and calling the same JavaScript method. But
Aligning Rescript and JavaScript
01:20:07
Speaker
for the type system's sake, it's different functions, essentially.
01:20:10
Speaker
Okay. So that's kind of how you model. and And so we ended up in a situation where, okay, we have all of these things. We can't really model them like we... we would, in a perfect world, model them, which would be... So it looks the same as JavaScript. Like, it looks... If you have an HTML button, for instance, you can do HTML button dot... Yeah, some prop on the button itself, and it looks the same as as JavaScript, essentially.
01:20:37
Speaker
So we hit a wall with, like, okay, we have a problem here. um how do we How do we make people understand that some of the things that you want... is regular record fields that you get when you complete for on the HTML button.
01:20:51
Speaker
But some of them are things that you want to apply on the HTML button from using the HTML button module with all of the helper functions, essentially. So with our overload, for instance. Back to 2018 again, right? like the the The answer is there. It's perfectly logical, but there's just no quick way of of making people understand it and getting it into their thinking.
01:21:16
Speaker
So Florian, and the community member, he he kind of kind of said, what if we just make completion return pipes as well, in addition to the... like figure out what but what from the main module we can apply on this to our overloads, for instance, like the functions that we want to apply, and just return that in addition to to um um to the record fields essentially or the fields on the button itself so and then i started hacking on the feature itself inside of the editor tooling of course and then eventually um ended up shipping it a couple of weeks ago i think nice nice so really are getting really granular on the developer experience not the language features
01:22:00
Speaker
yeah Yeah, exactly. And that's been but the the big thing with Rescript has been trying to figure out how do we move closer to JavaScript, the good part, so speak, like and how do we make this this better in terms of that, more idiomatic, move closer, cover more use cases, make it more familiar to JavaScript developers. And when I say that, I don't mean it as bring in everything that JavaScript has, all of the faults as well. like We're trying to be very picky about what we bring in and how we bring this closer JavaScript.
01:22:30
Speaker
to to JavaScript. There's obviously a clear limit on how close we can get without eroding the nice things that we've inherited from OCaml, for instance. Like, how close can we get without destroying those things?
01:22:41
Speaker
We are very mindful of that. So we want to make it... It's pragmatic. It's driven very much by ah JavaScript and real-world usage of JavaScript. um yeah But also, yeah, it's it's important. And we have many, many features around that. One of my favorite things um that shipped last year, I think, is and we have untagged variants. And the best way to explain that is that you can, in Rescript, um to a certain extent, you can model all of these weirdities that you have in JavaScript in in that something can be either a string or an
01:23:17
Speaker
number or a function or an object or an array at runtime, and you have no idea unless you check at runtime what it actually is. yeah And this is something that's been notoriously difficult to handle in in Rescript before, because there's no just no way to represent that, right?
01:23:35
Speaker
There's nothing like that in the language itself, because that's not thing in in in its origins. um So normally what you do is you even either have unwrapping code that takes that thing, identifies it through JavaScript, and and figures out, OK, what is this actually, and then maps it onto to an actual rescript type.
01:23:53
Speaker
um Or you just use rescript structures, and that's going to be fine as long as it's internally your app. But as long ah as as soon as you end up working with the outside world, which you usually do because you use libraries and and like API responses and whatever. You're going to have to use third-party JavaScript. Yeah, exactly.
01:24:12
Speaker
And then you end up in a situation where you have to do all of this, again, manual bookkeeping that, oh, this thing deeply nested inside of my API response might be a string or nint, and there's no way for me to to handle that without making sure that I explicitly myself unwrap this at all times.
01:24:27
Speaker
So untag variants adds to to the type system and especially like yeah the compiler itself to... be able to model this so you can model a variant and say that this at runtime, this variant constructor is true.
01:24:44
Speaker
This variant constructor is the number 12. This variant constructor is an int. This variant constructor is a string. This variant constructor is exactly this string. And this variant constructor is a regex. This variant constructor is a and function. Yeah, the list goes on, obviously, for... for um and then So that that's that's been hugely helpful because that means that the the surface of what we could bind to idiomatically in Rescript and JavaScript kind of increased by ton when we shipped that.
01:25:15
Speaker
um Because there are, again, like JavaScript is fantastic and it's wonderful, but there are a lot of weird APIs in JavaScript, right? Yes. Maybe not fully thought through stuff still. yeah So we need a way to kind of handle those things. um And and what what this led to is, of course, that we can we can kind of um interact with much more of JavaScript.
01:25:40
Speaker
and But also, a side note, we we it led to us now being able to model JSON with just j j with their language constructs. So JSON can now be... be yeah It's just a variant. just a variant definition that has all of the potential... a recursive variant definition that has all of the potential values.
01:25:59
Speaker
So and this is really cool because this means that you can do JSON encoders just by using the language. And you get all of the the kind of... um features like all of the niceties of variants by doing that, since it's all in the language itself.
01:26:18
Speaker
And then so that that kind of solved that. you could take You could have your user, ah come back to the user example, the user record naming it, you could turn that into something that's actually guaranteed to be representable as JSON by using the variant representation, representation right, for that.
01:26:35
Speaker
um Just taking your record and, you know. Because i've I've found with, like, typed languages speaking to JavaScript that you always have this problem of serializing and deserializing JSON.
01:26:46
Speaker
Does that make my life easier, explicitly? Yeah. It does make your life easier. um Then again, like if you do a lot of serializing and stuff, maybe you don't want to handwrite encoders, decoders anyway.
01:26:59
Speaker
And there are other libraries also for solving it that helps you decode. um But again, like you can write all of this just using the language. And what we added a couple of months back is we added pattern matching for dictionaries.
01:27:12
Speaker
ah So dictionaries in Rescript compiles to a regular JavaScript object, but it has its own dedicated syntax inside of Rescript, where you can kind of construct dictionaries with static keys and then add your own. And then now you can also pattern a match on it. So you can pattern a match on essentially ah um um a dictionary saying that, oh, this brand should match if this prop has this exact value and this prop doesn't exist, for instance, or or or that kind of thing. yeah um and
01:27:43
Speaker
And that's, again, like in other situations that might not be super useful. In JavaScript, it's very useful because so many things are modeled as dictionaries in in in JavaScript, especially yeah in Drop.
01:27:56
Speaker
um And what this did is it kind of made the the JSON support full circle because this now means that you can write JSON decoders just using the language because a a JSON object is in Rescript represented as a dictionary of other JSON values, right? So now you can, if you want to if you have a some JSON value and you want to check if it's a user you can now pattern match on it being a json object that's a dictionary that has a name key that's a string that yeah that's it has an age key that's a number and yeah so it kind of made it go full circle and the cool thing about this i think then is that it's all native features in the language right there's nothing else to it which is cool and kind of show i think shows the the potential in trying to
01:28:48
Speaker
come closer to the everyday kind of use of of of javascript yeah yeah okay i'm very tempted to try this out now very tempted yeah it love what if you did is it production ready in your opinion Yes, definitely.
Looking Ahead: Rescript Version 12
01:29:01
Speaker
It's been in production for a long, long time at many companies.
01:29:04
Speaker
We are like were were we're currently rescript is currently at stable version 11.1, and then we're working on version 12. And version 12 is going to have a fair number of changes compared to 11. We've kind of slowly made a transition towards where we want to be language-wise.
01:29:24
Speaker
And when version 12 ships, we've finally... cleaned up a lot of things that has been um like a lot of uh old kind of things that we've inherited that doesn't make sense anymore for us as we're only targeting javascript and made made streamlined the experience more so risk of 12 is going to be much easier to get started with um and many ah less less kind of holes to fall into the aren't really relevant for building things um Oh, so i so like you you had some baggage from your OCaml days, is that what you're saying? Yeah, but like yeah but baggage is is... Yeah, we had some stuff that that made sense when the idea was to compile to not just JavaScript.
01:30:08
Speaker
ah But, yeah but i mean yeah, baggage is a hard word. It's just not applicable anymore, ah probably. it's It's more of a Yeah, so we've taken the opportunity to kind of streamline things as well and make it more...
01:30:20
Speaker
and Yeah, again, closer to JavaScript than and and to a good experience. 11 is still great, so like try it out. But it's getting even better in 12. Okay. when When do you think 12 is coming without committing to a deadline?
01:30:34
Speaker
and We're aiming for Q1. Q1 2025. Yeah. yeah we' We'll see. we're We're aiming for that, but we'll see what happens, essentially. So where do I go to get started?
01:30:45
Speaker
Give me the best place to start. rescript-lang.org.
01:30:49
Speaker
Okay. that's the That's the best to get started. And we have a forum as well. It's linked to from the web page. and But I would encourage you to just go and try it. There's a playground as well on
Conclusion and Call to Action
01:30:59
Speaker
the Ruskip Lang website.
01:31:02
Speaker
And again, like try a few things out. Just see if you can... Get some basic stuff going. And then if you're a JavaScript TypeScript developer and you don't have the experience from similar languages before, like stick with it for a while.
01:31:16
Speaker
yeah I dare say that it's very likely that you are going to like it a lot. like that's that is That is the experience that we have in the real world, mostly. like people People don't want to go back once they're hooked, essentially. So stick with it.
01:31:30
Speaker
but There may be a hump like to to learn a new paradigm from everything. but If you get there and you find you would never return, that's that's treasure, right? Yeah, exactly. Okay, on that point, I think I'm going to go, I've got a couple of hours before I have to do some productive work after this call, so I think I'm going to go and kick the tires.
01:31:47
Speaker
Gabriel, thank you very much for joining me. Thank you very much for having me. Oh, thank you very much. Cheers. Thank you, Gabriel. If you want to try out Rescript for yourself, head to rescript-lang.org or find the link in the show notes.
01:32:04
Speaker
I have been using it a bit since we recorded that conversation, and I will say this for sure. The compiler really does feel snappy. They've done some excellent work there. Before you go and try it for yourself, if you've enjoyed this episode, please take a moment to like it, rate it, maybe share it with a friend or a social network.
01:32:21
Speaker
If you enjoy Developer Voices episodes regularly, please look for us on Patreon. Again, link in the show notes. And if you haven't yet started to enjoy Developer Voices episodes regularly, make sure you're subscribed because we'll be back soon with another.
01:32:36
Speaker
But for now, I've been your host, Chris Jenkins. This has been Developer Voices with Gabriel Nordborn. Thanks for listening.