Type systems with ReasonML London organizer Marcel Cutts and Shane Wilson
"Java has done an excellent job at ruining types for everyone for quite a while—explains Marcel after describing the tech pub scene in London—but it's important to know there's more than one kind of type system." Along with Shane, they outline what's exciting about ReasonML and their experience with new languages and tools around types.
- Marcel Cutts | @marcelcutts: Founder of Asgard Tech, ReasonML London Organizer
- Shane Wilson | @wilsonashane: Founder of Peyk Inc.
00:38 - Reason
03:25 - BuckleScript
06:01 - Reason + BuckleScript
16:07 - Reason: Interoperation & Adoption
30:00 - Operating at the Compiler Level vs the Run-Time Level
- ppx (pre-processor extension)
34:29 - Last thoughts on, and why use Reason?
44:43 - repkgs
CHARLES: Hello and welcome to The Frontside podcast, a place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles Lowell, a software developer at Frontside. And today, here to talk with me about many interesting topics. One of them being ReasonML, we have Shane Wilson, the Founder of Peyk Inc, and Marcel Cutts, Founder of Asgard Enterprises. Welcome, gentlemen.
MARCEL: Hello. Hello.
SHANE: Thanks for having us.
CHARLES: Yeah. So, I guess we should start out just talking about why ReasonML. I understand that both of you guys have some experience with it. New languages are all the rage. So, what drew you to it and have you found it?
MARCEL: That's a great question. I'm afraid my history is going to be spotted and will really demonstrate how much pubs are an integral part of the UK tech scene. I got into ReasonML maybe four years ago at this point when I found it on some hacker news post. And I asked on Twitter, "Hey, is anyone running a ReasonML meetup in London?" And I also, maybe around point one. And then by point for a point five, someone said, "Oh, no, wait. I think there is one." "Oh, does that mean you're starting one?" And then by point six, I thought this was a good idea. So, I began to run the ReasonML London Meetup, which end up being one of the bigger ones in the world. And along the way, it [inaudible] to learn some ReasonML and why it exists, which ended up being quite fascinating. And I did quite a few talks around it around the world. And it has stuck with me since. It's a very fascinating intersection of many kinds of approaches to programming as well as technological applications with a lot of history as well stemming from its origins, OCaml. So, it's a bit of a unique beast and it has kept me interested since.
MARCEL: Some say that I have in fact made several branches for many client projects which secretly have been produced from BuckleScript output and then slightly tied it and no one's ever found out.
CHARLES: So now, what is BuckleScript for the uninitiated?
MARCEL: We can go from the top down. ReasonML is a meta language as well as a toolchain and some documentation utilities for a language called OCaml. OCaml is a 20 plus-year old [inaudible] systems language, the kind of language you expect someone of a long gray beard to be writing.
CHARLES: It's one of the spiritual ancestors of Haskell, isn't it? Or no?
MARCEL: That's a great question. I'm sure what the familial tree between those two would be. I think it's an ML language, which means that a lot of that will bleed into the Haskell way of thinking.
TypeScipt has been around for nine years at this point. I think it came out in 2011. It's been around for much longer than people remember because it just took a long time, a lot of [inaudible] backing to get to the front spot. And it is continuing to slowly develop to this day. It hasn't quite got the same acceleration it did at the beginning, as Shane mentioned. But it still has a ton of interesting applications and it is used in the law of production applications throughout the world. For example, all of Facebook Messenger is written in ReasonML for performance and certainty reasons.
SHANE: For me, I've never used in ML language seriously before other than like some toy projects. So, for me, most of my experience with types has either been Java or TypeScript. And ReasonML, I'd much prefer that type system. I'm not going to get too technical because quite frankly, I don't really know the technical things to say here. But when I work even with TypeScript, I feel like I'm adding types because TypeScript wants me to and needs them. Whereas in ReasonML, first of all, you don't have to add a lot of types. You almost never have to actually type the code that you're writing, maybe type modules or create types. But the actual code that you're writing with all the flow and the logic is almost never a type in there. ReasonML and the OCaml figured that out for you, which I think is amazing and it doesn't get in my way anymore. And when I write ReasonML types, I feel like I'm doing that to help me, not to help the language. I want to better define the problem that I'm solving and help create barriers for how to solve that, put data in a place that it should be, help with my logic flow, and I want to make those changes and the language is helping me make those changes. Whereas most of my time and experience with types, I know what I want to do and the types aren't happy, and so I have to change my work to manage the types.
CHARLES: Right. You're having to kind of spoon feed the compiler and throw spaghetti at the wall and see which come kind of weird combination of types and generics fit the problem and make the compiler happy.
MARCEL: Yeah. Java really has done an absolutely excellent job at ruining types for everyone for quite a while. The worst PR campaign you can imagine. But it's important to know that there are more than one kind of type system. There are two big schools. One being nominal typing which is the kind of Java C# thing that has burned into people's memories and gives them sleepless nightmares, where you try to compare the names of things and the way the things I described and to figure out if they have equivalent to that sort of thing. But the thing that things like Haskell, Elm, and ReasonML, OCaml too, is called structural typing where it's based entirely on the structure of your data, which means you can do much more interesting things and it can get out of the way a lot more. And it has something called the Hindley-Milner type system, I want to say, to try and infer the types to the best of its ability with as much certainty as possible from your code. And it is mathematically provable that the Hindley-Milner type system is the best type inference engine that currently exists. So, you do end up typing precious little when you're actually writing ReasonML. But you still have complete type certainty, which is very helpful, especially if you compare doing this to something like TypeScript, where I think it's not unreasonable to say that folks like to type all the things that are easy to type, for example, dysfunction [inaudible] string. But often it is much more difficult to type things like the response from an API that could be in all kinds of structures or the state of the application, which could be in X many permutations, which is much more difficult to describe with the typing tools that you get in that language set.
CHARLES: Is there any particular example of something recently where we can compare, say, an implementation in TypeScript to something in Reason? I just want to make sure that we have like some way to focus. Because I believe you, but it's just -- and I definitely have this experience where I feel like I'm trying to satisfy TypeScript and the errors are cryptic and, yeah. And so, I'm trying to get a glimpse into what's a particular use case that I would find frustrating with TypeScript that Reason would swoop in and solve all the things.
SHANE: I don't know if I can think off-hand of something that obvious, although there might be. But I know one big feature that ReasonML has is like the switches. You can switch on a type and I guess you can have dynamic typing. So, instead of having to create a whole interface, you can just say -- basically it's it's like here's a string, but it's not a string. It's like I just have a label and it's now a type. And you can do type checking on these dynamic types. So, I've used that recently to manage errors in a product I was running where any random error I want to come up with, I could give it a label. Oh, and so types can also get past data. So, my dynamic error label like file read error can actually take in values like a file pointer, like a link to a file. And then when I'm accessing that error later, I can pull out all this data. So, you don't have to create these complicated structures and try and pass them around. You can just create a type and then it will have all the data in with it. And then you can do a switch check on that type and destructure all the things that you need.
It's kind of hard to explain, especially when I don't know the details of what I'm saying. But the best I can say is it's just the feeling you get when you're programing, you don't get the frustration. When I work with the types, I'm always glad that the types have helped me. I'm very rarely frustrated that the types are getting in my way.
CHARLES: It sounds like the types are just so deeply integrated into the way that everything is done. It's not so much annotating stuff to make sure that the ends of your apparati line up with each other so much as deeply integrated with how you actually express the flow of the program. Is that a fair way to say it?
SHANE: Yeah, it sounds good.
So, it's kind of easy to add it as a sidestep. I think the BuckleScript people have said they don't really try and integrate it into the other tools as like a first class because they want control over so much, because they do so much. And by having all that control, they can build it that quickly. But if you wanted to, you could just add a little folder and then put all your ML code there and just have it compile. And then your other watchers just see the compiled files and it works.
That's actually what I've done where I wanted my interface to be TypeScript, but I wanted my actual code to be ReasonML. And so, I have one TypeScript file, which is like the index entry point of the program. And then that TypeScript file reads my generated TypeScript files that don't really exist before I run anything. And then I would just have the BuckleScript compiler watching, it builds on my TypeScript files and then I will run like Yarn or whatever, and that goes into my TypeScript entry point, which then finds all those that build TypeScript files and it just runs. It doesn't even know the difference. So, it's not the worst setup, if you want it to.
CHARLES: Okay. Meaning, for example?
SHANE: I guess you wouldn't need things like Lodash as much.
CHARLES: Okay. So just all your things like transforming data structures and stuff like that?
SHANE: Yeah, a lot of the data structure manipulation functions are already built in.
CHARLES: But it's still all the stuff like file systems and network you have to receive from the environment. For example, I assume you can run Reason in both node and the browser, right?
MARCEL: It can also compile to Native, if you really want it to run in the machine.
CHARLES: Oh, it is.
SHANE: Yeah. You don't need Java anymore.
CHARLES: Okay. That's good.
CHARLES: Okay. Well, that's handy. So, there's a totally separate Reason compiler. But is this syntax exactly equivalent to OCaml? I'm still a little bit confused on that point. Or is it just a dialect?
CHARLES: I see. Okay. So, BuckleScript is and of its own a unique language.
MARCEL: Yeah. One could program in it but very few people do. It's a very powerful middle module.
MARCEL: It is true. There were initially quite a lot of good momentum on this and a good uptake. And the growth of ReasonML, while it's still perfectly usable, very reasonable choice for all your projects. One of the reasons I feel it hasn't done as well is because of these continuing small confusions and decisions and perhaps a lack of more central leadership. Ostensibly, it's run by Facebook, but that's not really the case, in pragmatic terms, which means that it can be harder to get people started. And perhaps one of the reasons why something more focused like TypeScript, which is very clear, singular documentation site is doing better out there in the wide world of the software [inaudible].
CHARLES: But you do think that it is possible to adopt incrementally too, should you want to? Even though it's distributed in terms of documentation and authority and maybe who's writing the roadmap?
CHARLES: Right. I wanted to ask another question about the types system. One of the things that I actually find frustrating about TypeScript and that I also loved about ClojureScript, and I know we're comparing a little bit of apples and oranges here because one is not strongly typed and the other is, but the complete absence of any type information at runtime inside TypeScript, and also the kind of arm's length at which you have to deal with the types system if you're trying to do meta level stuff. So, if you actually want to analyze a TypeScript file and use the type information at a meta level, it's actually very difficult. The API is extremely cumbersome, the programmatic API to the TypeScript compiler. Same thing really applies with Babel. One of the things that I love, absolutely love about Clojure and really any dialect of Lisp is how close you are to be able to make meta level transforms on any syntax because you can treat any program as just data. So, every Clojure program is a Clojure AST. The data structure and the evaluation of that data structure are one and the same, or they're always close at hand. Is there something similar like this for this toolchain where, let's say I've got a set of types representing a state and I want a set of functions that transition from one state to the other. And I want to say, look at this declaration of a state machine and I want to render a SVG graph showing the state transitions where I have one state for each member of the type union and then a function showing an arrow. I want to draw an arrow that shows the input and the output for each function transition. So, if I've got the type of the input and the type of the output, I can then draw an arrow. It's very easy for me to imagine doing that in a functional language that's a dialect of Lisp. Very difficult for me to imagine doing it in TypeScript. Are there tools for operating with the type system at the compiler level rather than the runtime level?
MARCEL: Yes, there are, absolutely. That is a whole meta-programming sector of this, which is very important for things like Jane Street's huge reliance on OCaml. But that is a kind of language extension which tries to make interfacing with the types and the compiler much more friendly, called PPX, which lets you build extensions on the language in a very predictable way, and then ship them and share them with anyone who needs them. For example, one PPX that's very popular in the ReasonML web world is this GraphQL PPX. It actually converts it into the correct typings that will have to be for ReasonML and checks them as you go, rather than having a separate compiler step, as you might have to do with something like a relay compiler where it checks your thing, asks the TypeScript compiler, "Hey, does this match you what you're expecting of me?" Then come back to the user and say, "No, that's wrong." Here, we're putting an understanding of the GraphQL schema definition language directly into its own compilation chain.
CHARLES: Okay, yeah. And what is that called again?
MARCEL: This is called PPX, and I can't remember what it stands for.
MARCEL: It was something unusual. I think it's something like something, something extension. But everyone just calls them PPX. I did once know and I remember thinking, "That's ridiculous." And then I promptly forgot.
CHARLES: So, it's kind of like a macro system, or it allows you to work with the syntax directly.
MARCEL: Yeah. And therefore, you end up having to do -- some of the more complex PPXs do some very, very interesting meta-programming based on types in the compilation toolchain.
CHARLES: Okay. That is really, really exciting.
SHANE: Pre-processor extensions.
CHARLES: Pre-processor extensions.
CHARLES: I mean, that's good to know. Although pre-processor is an unfortunate term. I'm scarred by the C++ pre-processor or the M4 pre-processor, I guess, which is used in C and C++. But I get it. Before we move in to talking about repkgs, is there anything else that we definitely need to call out as being super killer about Reason or that anyone should know, things you're just dying to let folks know something you always lead with when you give a talk on Reason?
MARCEL: I think we've covered most of the score points, which is things like speed, things like reducing your reliance on other parts of the toolchain. One of the nice things is that, which I've mentioned is that you don't need all these things like Prettier, which was also built off Reason's refmt, ESLint or something, because they're all just one mega compiler, one binary to work around. Often, you'll have loads of CI/CD issues or issues on your personal computer because some part [inaudible] out of whack because our toolchain is a loosely coherent set of packages that we marshal along. But here, it all comes in one package. We have the interop, which is nice. We have the syntactic positiveness. The fact we don't really have to do much actual typing, which is great and just kind of falls out of the way you write code, which is nice. And I think that's mostly it. I mean, it means you can do really cool things, like you have type safe CSS because of the syntax extension I mentioned earlier. So, you don't have to have any variance if you don't want that to be.
CHARLES: Okay. Man, I'm sold. I actually am. I'm seriously excited.
MARCEL: [Inaudible]. It does have [crosstalk].
CHARLES: Okay, yeah. That's actually a good point. Because it sounds really awesome, and yet not many code bases use Reason. Why is that? Why are we not using Reason today?
MARCEL: That's a great question. Why aren't we using? Because people are cowards.
MARCEL: I do think to some degree, I have worked a lot of languages that are incrementally adopted from or a lot of languages that have taken adoption slowly. And one thing I have found that is really amazingly important is for it to be something similar to what people currently use. We like to think of ourselves as technologists who are forward thinking and want to learn new ways to doing things real time. But personal experience says that's untrue. We are like everyone else. We like what's familiar and things we already know. We don't like the idea of feeling junior again when we already feel confident in our way of doing things. One of the best examples of this is a language I used to write a lot in is Elixir. Elixir is based on Erlang, which has been powering telephony systems for older than I am. And I'm getting pretty old at this point. So this is a highly full-tolerant language made for distributed systems. And that become more and more relevant nowadays because as we've come from personal computing backup to the cloud where we need full tolerance and distributed systems, it's an almost perfect candidate. But it didn't really have any adoption until someone wrote a new way of doing Erlang called Elixir. Elixir was made to look a lot like Ruby. And that alongside with the WhatsApp acquisition because no one cared about Erlang until WhatsApp was bought for $19 billion. Then I thought like, "Wow, maybe this is the way of getting bought out by a large company." But that aspect aside, it made it much more approachable. And of course, there's a really huge amount of people out there who write in Ruby, and they wanted something just like a little bit better. So, Elixir had been a much easier adoption process in at least the London startup scene compared to Erlang itself, which, of course, is equally capable but just looks more alien.
MARCEL: So, I think we are only slowly getting to the point of having Reason be approachable enough. I think there are still definitely work to be done on a few key points. The story of async/await, you can do it. There's a ton of PPXs for it, but there's not one blast path. There needs to be a very streamlined documentation, like a streamlined, centralized place [inaudible] get started with projects easily where they can be effective quickly and where they can dunk on their friends on Twitter without needing that much experience.
TypeScript, on the other hand, has been very popular because you can adopt it very slowly and you can essentially be using a "TypeScript" of almost none of their features or safety because you could [inaudible] enough and any is the [inaudible] of a code base.
MARCEL: But once they have it in there, it taints the tree of type understanding because everything has a relation inside, AST. I think Reason still is a little bit too unapproachable for use and it needs to have some of these things like the async story ironed out. While the errors are generally much better than TypeScript because they're going on a sort of Elm approach. If you ever use Elm, it is a wonderful copilot for getting you to where you need to go as long as where you need to go is a web app, because it's not a generic language. And these things combined and the lack of visible momentum, because a lot of this work is done, perhaps not in the open as much as it should be, means that I think it just hasn't got the speed because people do want to use what's popular. And that's not necessarily a bad thing. But community matters and community leads to Stack Overflow posts, which leads to documentation, which leads to help and reassurance that people are doing the right thing. People are often declaring, I think people, it can be seen on Twitter. People often declare technologies is dead. For example, when some Facebook libraries move from Flow to TypeScript, they both declared that, I guess, flow is over. The reality is flow is still the majority use type system within Facebook. It's just for some very external projects, that I would love as a contributor, therefore it wouldn't be nice of them when you use TypeScript. But it continues to be developed, continues to be what they write React in, as well as nearly all of the internal things that they ship.
And in many ways, Flow is a much better type system. It's not quite type sound, but it's much better. It'll force you to be correct, but the tool is not quite as good. And because it forces you to change a lot of things at once, it just was much harder to pick up as compared to TypeScript, which basically lets you get away with anything. And one might argue, what's the point then? And the point is that one can say [inaudible] TypeScript.
CHARLES: The point is to be viral.
MARCEL: And it's important to also note that the TypeScript integration in [VS Code] is great. I think it's really wonderful. One of the things I've always struggled with was having really resource intensive work as I work in the background, always checking files, and that led to a lot of frustration. The tooling story and documentation story and the on-boarding story of TypeScript is wonderful, even if and it may have slightly biased position of having used a large number of type systems, I think TypeScript is not quite as useful as some of the options out there. They really nailed the things that drive adoption. And ReasonML, much like PureScript or whatever else your favorite language happens to be, which probably is very good, the hard part is doing the people part, not the software part. Much like the Haskell approach, and this might be minimizing the Haskell community, so I apologize. But I have often gotten the impression that there is this idea that if a language is just good enough, people will flock to it naturally. If you build it, they will come. Which I think is not actually said on the movie, but it is the common misinterpretation, much with, "Luke, I am your father." And I think that simply isn't true. You really need to do a lot of community outreach and it can take a long time.
CHARLES: Yeah, but I do think it builds well for the future of Reason. I think it does seem to be put together a little bit better, I mean, certainly than PureScript or some of the other ML-based languages that I played around with, just in terms of the marketing. I'm not saying anything about the technical capability of the language. And it is, I think honestly, the biggest problem with flow right now is that I think it might actually be dead because it doesn't differentiate itself enough from TypeScript. So, while it might be used internally in Facebook and stay alive in that way, and I don't want to spend too much time trying to conjecture about the future of these things, but at least externally, it doesn't seem like it's much of a differentiation, whereas something like Reason really is. It's something different. And that's important in terms of adoption in five years, 10 years, things like that. Maybe not. Anyway.
MARCEL: Yeah. I think that's a very fair observation. You're not going to get anywhere unless it's efficiently better. I remember, back in the Angular dominant days, the only reason people has picked out React because it's significantly better. Things that are only marginally better, people won't bother spending the switching energy for. So, often with projects like [Preact], for example, just say it'll be a slightly smaller bundle size. But people aren't going to switch all their tooling or all their knowledge and all of their risk profile for something that's only slightly bit better. You have to really excel for people to take notice. You have to do something different for that technology to be adopted. And in React's case, what it could do is, unlike all the things it can knockout in Angular. It could be easily understood on a simple level to get basic things going because you have to understand the whole framework. And it was relatively performant, which was a really big problem back in the Angular 1X era, and that really differentiated it.
There's so many little changes that happen between a moment of my tests say this is going to work and then it actually going into npm. So, this is false in that space where it tries to tell you right before you hit publish, run these checks and then confirm that what you're about to do is what you think you're going to do. And this came about because previously, like five years ago when yarn had just come out, I had made another monorepo tool called knit, which was very magical. And it basically ran through all of your code to find all your dependencies for you. I think it's still a pretty cool project, but it competed directly with lerna. And with lerna, it was such a behemoth, had so much backing. I didn't want to try and do that again, even though I think there's some ideas in it that were really powerful.
One of those ideas was walking through source code to determine the shape of the project and what dependencies are needed. And so, I took that idea. I think that was the interesting idea that knit had, and I just kind of focused on that. And that's how repkgs came about. It crawls through your code, it crawls through your package manifest, and it will try and find all the things that are about to break on you. That's just an overview of repkgs.
And my reason I picked ReasonML is that was just a thing that I wanted to do.
CHARLES: That's a perfectly valid reason.
CHARLES: Some might say the only reason.
CHARLES: Wait. You were writing in Reason and then compiling to what?
CHARLES: Oh, so wait. I feel like one of the things that Reason needs to do is have like a big diagram on the home page that shows the toolchain because I'm having difficulty getting my head around all the different moving parts.
MARCEL: I have made this diagram several times.
MARCEL: Maybe I should just open up PR on the home page again to put out for me.
SHANE: So, the difference is it's not actually not all BuckleScript-supported ReasonML will compile down to Native OCaml. It's not ReasonML, and then you just flip out the output. Sometimes, you have to make changes. So, it is kind of complicated and a little confusing. Basically, the first month I was using, it was going to run on Node. My output was running on Node. And in the next month, I had it running as Native compiled. And then the third month, I went back to Node.
CHARLES: Okay. That's awesome, by the way.
SHANE: Yeah. Well, I can explain why. The first month I was just learning BuckleScript and ReasonML, and that's when I was getting stuck but stuck in a way of I kind of felt like it was my fault that I just didn't know the language well enough. And I could usually see where I was trying to go. I just knew I had to figure out how this syntax worked or how do these modules work. So, I felt like I was slowly but surely making progress, except when I would run into a problem that was very Node-specific. Because if you Google BuckleScript, ReasonML, it will immediately take you to React. That is by far the biggest focus of BuckleScript is React.
SHANE: So, finding answers to my questions that were Node-related, like interacting with filesystem and how do I do this, and all the Node binding, it isn't fully complete. It has only a couple of the methods on all of them. So, anything Node-related, I found pretty frustrating to deal with. And there was a lot of me just kind of like 'I guess I'll figure this out on my own' sort of feeling. And I got to the point where I was thinking, "I'm running this locally. It's never going to run on a browser." And Reason has this cool option where I can compile to Native code. So, I rewrote everything. I didn't try and convert it because it didn't really convert the way I wanted it to because I was using a lot of Node bindings in my original code. So, I just rewrote everything.
CHARLES: Okay. So, when you were outputting a Native binary from your Reason, are you literally using the operating system native libraries like, what is it like? The stdlib on Unix to get access to stderr and stdout and all that stuff?
SHANE: I think that is what's being used. You do have to compile to the platform so you don't just make one binary. It's like you have to build one for Windows, for OSX. I didn't go that deep into it because when I made the transition, I was very Node heavy. And then when I transitioned over to Native, I rebuilt everything. And that process actually was not fun at all. That month was a pretty terrible month of me working on this. There are a few libraries that have been around for a while, if you want to do a commit, [inaudible] arguments or reading file system or work with the operating system.
There's one guy, I can't remember his name, but he seems to do everything. [Inaudible] forever and they work pretty well. But there's not a ton of examples. For a language that's so old, I found it extremely hard to find working examples to help me. So when I got stuck, oftentimes I was just stuck. Just like dead in the water for days and days, just trying to work through these issues myself which I found very frustrating. One thing I do a lot of in this application is I read the file system and I use like globstars to read through directories. And all of the Node packages have this supported, like the one globstar with two globstars means it's recursive. In OCaml, I couldn't find that anywhere. So just the basic here is a path with globstars in it, and it means go through all directories. That wasn't a thing that I could do. It just wasn't there. There's an OCaml-re which is regular expressions and it had some path stuff but it didn't support that. And that was like the main one that people use. It didn't support it.
There's another tool called Dune, which is their package builder. And I had to use their library for a while, but I don't think that's supported in the same way. I basically had to build my own, and that was not the best. I don't want to have to build my own regular expression parser. And basically, it's very frustrating.
MARCEL: This is actually an endemic problem inside all the OCaml communities because OCaml has a bunch of factions. Not that they're at war or competitive, it's just they have their own kingdoms in which they find OCaml resource. Some of them are very academic, like this team in France or very financial like Jane Street, who has their own library for basically everything.
One of my friends, [Rizo] is a huge OCaml fan. He is the more competent technical part of the Reason London experience, while I am the razzle dazzle. He has continuously talked about the things that there are four to eight standard libraries and there isn't a community centralized documentation system and it's all a bunch of IRC servers where people in the know talk to each other and decide what's going to happen with the language. And this is definitely something that hopefully Reason can help with, because it will highlight the fact that if you want mass adoption or adoption by more people, these community items are required because very few people will power through frustration in the same way that Shane did.
SHANE: Yeah. I made a decision that I was going to figure it out. And I, multiple times, just said I am done with programming forever, and I just closed my computer and walked away for a day. I couldn't imagine anyone doing that for work though.
CHARLES: But you went back then to Node.
CHARLES: But at the same time, this is kind of how like the reason we have that in Node like the [inaudible] is because back in 2009, that's what the Node ecosystem was. If you wanted something to actually recurse through a directory, you had to build all that yourself.
SHANE: Yeah. That's the happy ending to the story is when I went back to Node, I actually understood the language a lot better. And I was able to pretty much solve all the issues I had that first month. Instead of learning the language or learning how to check the file system or getting frustrated, I could just use the types and really build out what I was trying to express using modules, using types. And the rebuild when I went back to BuckleScript was a really pleasant experience. That really sold me on BuckleScript and ReasonML.
MARCEL: [Inaudible], we have all the knowledge you need to tackle the enemy you had a problem with it the first quartet of the hero's journey.
CHARLES: It's a validating story because if you are able to spend the work to learn how to make the hard thing easy, then you can do the easy thing because that was hard previously. Doing the hard thing is now easy.
MARCEL: I think also, to Charles's point, there is now a library called reason-nodejs which came out fairly recently that attempts to, I think, tackle many of these Node problems. It even has a file system example on the Read Me. You may be correct that a lot of these frustrations will eventually get solved by people writing packages that we then just consume and don't think twice about.
CHARLES: Yep. All right. Well, I think we're almost there. Gentlemen, it has been a journey. I actually am pretty excited. There's a couple of things that I want to try now. As you guys know, I've been fooling around a lot with structure concurrency and knowing that the async/await story isn't quite pinned down in Reason makes me want to try and implement a more general structured concurrency story there. Just give it a stab. And in knowing that there are these PPXs that you can extend the syntax is really exciting because one of the frustrations of trying to do that in TypeScript has been you're very limited in the syntax that you can do. You've kind of got to work with what you've got. And the typing around generators and co-routines is just not great. And it's not going to get better unless you can convince the people at Microsoft to do something about it. But it sounds like there's actually a way forward, which is ultimately the power of having these syntax transforms, which is exciting. So, if I ever can find some spare time, I am not even lying, I want to dedicate some cycles to this.
CHARLES: Unfortunately, I am. Oh, and they've got letPlus and letStar. All right. Anyhow, thank you all for stopping by. Everybody, go out there and Reason away. And we will see everybody next time.
MARCEL: All right. Bye for now.
CHARLES: Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @thefrontside or over just plain old email at firstname.lastname@example.org. Thanks, and see you next time.
Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at email@example.com. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer.
This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.