Sessions is temporarily moving to YouTube, check out all our new videos here.

Reason Syntax and Toolchain For OCaml

Marcel Cutts speaking at ReasonLDN in June, 2017
385Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

A rocket fuelled tour on the origin, purpose and utility of ReasonML. We’ll touch on everything from how a keyboard company is guilty of putting OCaml in your browser, and answer the critical question of why surfing this hype wave is excellent for your hipster cred.


Transcript


Okay, so, Reason, exciting young thing. Actually I'm just gonna hold this. I have become more and more of a fan of it. But what is Reason, where did it come from, why was it created, and where is it going? So lots of you probably work on the web, and Reason was originally made by Facebook to help make web applications, and over time, your code has probably gone from looking like this to looking like this to looking like this. You know, that's a more functional, more maintainable, you're very proud of yourself, and you've made this menagerie of tools to help you write maintainable, extensible, readable, legible, secure code. You're very happy. You see in a corner there's all these people writing Elm and PureScript and LiveScript and you think, that's great and all, but I'm gonna stick to core JavaScript, maybe a little bit if I want in the future we're gonna use Babel, but we're safe. We don't have to diverge into some completely different field, you don't have to learn a whole new way of doing things. Then one day, this chap called Cheng Lou stands on some stage and goes, I want you to write in Reason now, you put your head in your hands and go, Goddammit, I wanted to keep writing normal JavaScript. I didn't want to learn a whole new way of making web applications, but then you look a bit closer and you see it says syntax and toolchain for OCaml. OCaml, that's right, that 20 year old systems language, OCaml is coming to you, to you and your browser, so you know, you check your watch, make sure it's not April first, but he's deadly serious, so how's this going to work Well, Reason is a meta-language for OCaml, it's a new syntax of writing, new way of writing OCaml, with a new, more friendly, more identifiable syntax for JavaScript people. It has also got a compiler workflow, and it's got docs, libs, and utils. More on that later. As a language Reason is functional but permissive, so it encourages a functional style, but you can still do the imperative stuff if you want to, you can still mutate if you want to, it's not like PureScript where it puts its fingers around your throat and says, you will do it in a functional way. Can an old language like OCaml be relevant to us now? It wasn't cool 20 years ago, or so some people say, contentious subject, why would it be cool now? Well, there's been a bit of a resurgence in old languages, for example Erlang and its sibling, Elixir. Oh do you, all the Elixir devotees in London are in the room today. Aren't you hiring, Louie, more Elixir developers? - [Louie] Yes. - There you go. So, Erlang's been around for dogs' years, and it's been running things like telephony stations for forever, is really good at doing this sort of, you know, high concurrency fault-tolerant systems stuff, and that's really, really cool, but not really applicable for most people. But as it moved into the cloud and made more distributed systems suddenly high-concurrency fault, and amazing fault tolerance has become something to be very enviable of, and people thought that was kinda neat. Then WhatsApp made this little messenger application, got quite popular, they didn't use very many engineers, they didn't use much hardware, and they thought yeah, I guess, Erlang can be cool sometimes, I mean, it's never really going to take off, but it's cool sometimes. Then WhatsApp was bought for $19 billion dollars, and everyone thinks Erlang's fucking fantastic now. If you learn Erlang, Facebook will buy you, guaranteed. But let's go back to Reason, and let's talk a little bit about how Reason works with the internet, because this is the new angle that Facebook's been pushing, and then we'll go to the other platforms later. So, Marcel, you absolute idiot, OCaml doesn't run in browsers, and you're right. But you've been saved, or doomed, depending on how you look at it, by a company that makes very fancy but very expensive keyboards. Bloomberg has made something called BuckleScript. BuckleScript will take your OCaml slash Reason, and turn it into JavaScript. The amazing thing at this point, I'm just purely taking the piss, because it seems like we're on one of those, what's it, obfuscated C contests where you try really really hard to get from A to B in the most difficult way possible. But no, bear with me here. Why should I write JavaScript in a meta language for a 20 year old systems language that is compiled to JavaScript by a fancy keyboard company? I'll tell you why. Remember all this tooling that we had before, things like Flow, Babel, ESLint and Prettier, we don't need it anymore. These are absorbed into the core language and into the toolchain, and just to prove this to ourselves, let's go through them quickly. So, Flow gives us types. OCaml is a typed language, and OCaml is written, oh, Flow is written in OCaml. What else have we got? Oh yeah, so this means we got all the stuff we expect, so they get all these nice little editor things with all the types and Windows arguments, and all the return values we require, everything's good. Babel, helps us write code that we enjoy writing, and turns into something that browsers can actually run. There's lots of ways of measuring the goodness of compilers, transpilers, whatever you want to call them, so let's do a few. Number one, BuckleScript is very, very, quick. It compiles 10 times faster than TypeScript, which is already, usually quite a lot quicker than Babel, or Babel, up to you. So usually, even really large projects will compile down in less than a second, whaaaa. It also makes human readable JavaScript output. Now this is, this has already been contended by someone in the audience to me before the talk, so they're with me. And to prove this I'm gonna have a test. Now I've used this in various versions of my talk, so if you already know the hook to this, like, shh. But, I'm gonna show you two pieces of code, one output by a human, one output by the BuckleScript compiler. I want you to stick your hand up if you can recognise the one that's written by a human. Number one, look at it, it's got variable names and everything. Number two. Hands up for human is number one. Hands up for human is number two. That's a pretty even split. And you know what, they were both done by the BuckleScript compiler, so, it proves that there is enough grey area for you to be convinced. I saw this guy, a delightful guy called Sean Grove, and he is absolutely amazing, and very, very handsome, look at that. He does really good talks on all kinds of OCaml and Reason projects, I really, really recommend checking him out, he's great guy. He's also got really good Twitter game. Prettier, Prettier lets us format a code, Prettier's actually based on Reason format, so it's a lot like Prettier, except it's faster, and it gives us secure options so we don't have to argue about trailing comments, which is really good. We have ESLint, so since we have types and since we have a formatter, there's not much left for ESLint or something like it to do, maybe unused variables and stuff, but fear not, because as a compiled language, we have compiled help libs. So with better errors, we're just going to hope it'll be something to Reason soon, we get these helpful message which can tell you where you fucked up, how you fucked up, and how you should unfuck yourself. And that's very important, and ideally, if this compiles, it should run, which Risa will talk about later to convince us, yeah. And it also tames the meta-language, so this is a little bit abstract, so, when we talk about the meta-language, we're talking about all the things around the language, and I'll give you an example to try and push our point across. So imagine you want to deprecate a function. What do you do? Well, if there's just two of you, you can turn around in your chair, talk to the other engineer, and tell her hey, don't use that anymore. Well, okay, fine. If you're a bit bigger, well, then it starts to get difficult. I mean, if you make a library, what're you going to do, put a comment in your code? No one's gonna read that. You can try and be obnoxious and put console outs into your code, so whenever people run your code they can see a big warning sign, but people will ignore it. Have you seen how many warnings the average project has? What else can you do? Well, you can tweet about it, you can write documentation, you can write blogs, I mean, here's an example. In React 16, you're not going to be able to use prop types from React anymore, you have to use independent React package, and I guarantee when React 16 lands, people will be furious in the forums asking, why on earth are my prop types broken, despite their putting it out to console, giving it like a year to adjust, blah-dee-blah, blah-dee-blah, blah-dee-blah. But OCaml has deprecation built in, and therefore, so does Reason, so you can tell them you know, say, why are you getting rid of it, how are you gonna get rid of them, what to use instead. And because it's part of a language you can start to use is as pile systems. So for example, you have your CI start to deprecate a code, because there's a standard method of saying, hey, this is going to be deprecated. There's loads of stuff like this that just makes it easier to write code but doesn't keep you up at night. It also has really amazing interop. So unlike things like Elm and PureScript which can be a bit dogmatic, because of BuckleScript and the way that Reason is written, you can actually pull in external libraries written in JavaScript, or output your code into JavaScript, just have webpack bundle it up, which is fantastic, because it means you can gradually move towards a Reason future. Sure, when you use external libraries, it means you're going to have to put up with the insecurities and the vulnerabilities and the instability that the JavaScript library will give you, but it's a pragmatic way of slowly getting to a better place. If you had to go all in on an entirely new language, an entirely new ecosystem, it would be very, very, very difficult to justify. And of course because Facebook has been pushing this, a lot of your favourite Facebook products already have bindings like you can get Reason react, you can get React Native written by these two lovely gentlemen and next month, hopefully there'll be a lovely young man from Bloomberg telling you exactly how you can make your React Native project with Reason and also put Reason in your existing React-Native projects. Watch this space. But what's really, really, really, really, really cool about Reason is the insane reach and the native compilation. So, with React 16, we're gonna have Fibre, which means we can write all kinds of renderers, which means we can go anywhere that JavaScript can touch, we can go and, you know, do robotics through Johnny 5, and all these other kind of things, but it's not the same as native compilation. OCaml's been around for so long, and you can compile to so many targets that you can just go crazy. You wanna write on computers, yeah, fine, OCaml's home turf like x32, x64 processors, compile the system, interact with UI libs, yeah, sure, great. You wanna write for mobile, compile to ARM, yeah, interop with Objective C libraries, sure, go, and because it's so performance-based, your app's going to fly. Do you want to do embedded, very similar, just without the objective C, I guess. But what's really, really amazing is the future of things like unikernels. So, let me give you a quick rundown of unikernels. When you write an application, you take the application, and you go, this is great, and then you plunk it on the operating system, and then it goes, and over time before, you're like, well, you know, plunking an app, like just one application operating system seems a bit weird, so let's put it in containers so you know, we can at least run several of the damn things. But really, when you put an application operating-system, what you're doing is taking your, like 10,000 lines of code or whatever, putting it on millions of lines of code that you're never going to read and you probably don't understand, then this becomes a bit, like a huge security, vulnerability surface, it also comes with bugs, performance issues, all these other things, so what can we do? Well, the OCaml communities have been slowly writing libraries which you can just attach to your application that do things like the TCP IP stack, that do things like the filesystem based on Git, so you can have an application that exists without an operating system, you put it straight in a hypervisor, and off you go. So that sounds crazy, and why would we want to it? This is what it looks like, by the way, I mis-slided. So unikernels are crazy quick, so usually sub-50 milliseconds, which means that you can make an entire unikernel vm appear, respond to a request and disappears, like serverlets on steroids, they're very small, usually 100 kilobyte to 10 megabyte in size, which means they can have, like, thousands of instances on one big box, and you can just check in each and every single unikernel you've ever deployed, into your git, because they're small enough, which means that when something goes wrong, you can pull out the exact one you deployed rather than checking out the code, rebuilding it, and hope that you've built it exactly the same way. So, unikernels, man, amazing. Now, Reason is not without its faults, 'cause it has very, very immature communities, it has a small ecosystem, which means that it's hard to find packages, it's hard to find guides, it's very easy to get frustrated, and it is a new community, so no one really knows what's happening, it moves very quickly. There's also this old, like OCaml god that, they're very nice, but they obviously like, don't have that much experience in helping you with your JavaScript problems. And you can get at times very, very frustrated to the point that you're in some basement clutching a bottle of whiskey, trying your best to read documentation. This is pretty much my favourite picture, I use it in nearly every talk But, but, I want to be hopeful. So, I've done about three variations of this talk over time, and people who've seen previous ones will notice I've basically gotten more and more hopeful every time, because I've become more and more optimistic. I've tried each of these things, like Elm, which I absolutely love, PureScript, TypeScript, LiveScript, this one nearly killed me. And having to dig myself a way out of TypeScript for a year or so was, you know, not something I'd wish on my worst enemy. And I think they all have their positives and they all have their flaws, but the pragmatism of Reason and the ability and reach that it gives you means I think it can actually have the potential to cross that gap into general use, and when we get there, we will have a full stack monster of a language. We were happy enough just to have something that can universally render on a node server and in your browser. We thought that was fucking amazing. Imagine code that you can run in desktop and your browser without changing any code, and that exists today, in Reason. So I hope you're all as excited as me, you can see where this is going, and thank you very much. - Yes. - People are, but it is definitely like the kind of people you expect, like for example, 25% of messenger.com is running on Reason, so it's getting there very, very slowly. It's definitely in a sense of like, ooh, let's put our toes in, but also there'll be places that you wouldn't expect, so if they're just using Reason to output JavaScript, which then bundled up with the rest of their JavaScript, there's no way that you could ever possibly tell that they're, like, a Reason-esque code base. - Yes. - Currently it exists like as a separate thing that you keep. It can use OPAM, so I think so things like Merlin and stuff you can grab from OPAM and that'll work with Reason to give you all highlighting and something, so they kind of work in tandem. I don't think Reason comes through OPAM, it's sort of like a separate entity at the moment. Who knows where it's going to end up in the future. - [Man] Okay.