This is a transcript. For the full video, see A deep dive into ReasonML: Building resilient apps with high stability - Tag1 TeamTalk #015.
Preston So: [00:00:00] Hello and welcome to Tag1 TeamTalks - the webinar and podcast series about emerging web technologies. I'm your host Preston So and welcome to our Tag Team Talk on ReasonML. I'm very excited for this talk. Today we're going to be talking about building resilient web applications with the need for mission critical stability.
I'm Preston So. I'm your editor in chief here at Tag1 Consulting and also senior director of product strategy at Oracle and author of Decoupled Drupal in Practice. I am the host and moderator of Tag1 TeamTalks. I'm joined today by some really amazing folks. First of all, Patrick Stapfer in Vienna, Austria.
He's the lead React developer at Tag1 and also a member of the Reason Association and a contributor to ReasonML. Also, we're joined by Michael Meyers, who's currently located in the Berkshires, and managing director of Tag1. And I'm located here in New York City. and today we're gonna be talking about ReasonML and some of the ways in which you can leverage ReasonML to really superpower your projects.
So let's go ahead and dig right in. Um, Patrick, what exactly is ReasonML and what are some of the use cases for what's this best suited for?
Patrick Stapfer: [00:01:06] So, Hello. First everyone. Thanks for having me today. So what is Reason about, it's the Reason is a function or programming language with built in ReactJS support and it's, it also has a very efficient tool chain and a very JavaScript like syntax.
So when you look at ReasonML and squint a little bit, it kind of looks like ECMAScript and has all the nice traits of a function programming language you would expect. So the language itself also offers seamless interoperability to existing JavaScript, which is very important. I mean, there have been a lot of functional programming languages out there, with the same promise.
Uh, none of them got this, you know. Like interoperability thing to existing JavaScript, right? Uh, there is like, dedicated syntax to, to interrupt with code. Uh, each Reason module compiles into a one spec compliant JavaScript module. So it's a, like, in combination with a very fast tool chain and a human readable JavaScript output.
It makes it a great fit to credibly put it in your existing JavaScript code base or even TypeScript codebase. There are, there are ways to even like make it interrupt with TypeScript code, to, to, to give you all the types in TypeScript as well. So it's not a lock in thing. And, about the compiler.
Of ReasonML. It's a, so it's a compiler which involves a type system, which ensures that every, every value, every function, every module you have in there and your program that each of these have a correct type applied. So you don't even need to write type annotations in most of the time. Uh, because the system will infer to the types for you, like.
And the very, very strongly typed way that means the quality of the type inference insures that each, whenever you're successfully compiling a pure Reason program, you can definitely be sure that there won't be any run time type arrows as long as you don't do any super crazy JavaScript, interoperability hacks.
And this whole thing, like the way to type inference work is made possible through the foundation on what the compilers build, which is a Hindley-Milner based type system which you probably know from other type systems like Haskell or OCaml or whatever. Mmm. Yeah. And so what you can say is that the Reason takes a different approach on putting types into JavaScript.
You usually know the gradual type approach like TypeScript does or flow type where they tried to be JavaScript or stay as close to JavaScript as possible and add types on the go. And the type system is still evolving in a process. So just makes it sometimes hard to later on like scale the project when you're trying to upgrade the type system.
Because TypeScript has a major breaking change. Suddenly everything or flow type especially has a breaking change in there and suddenly your whole code base needs to be adapted to the new type system. And in case of Reason its other way around, you have. You have a type system, which has been there for decades.
Uh, a compiler which is very stable and fast and the language reflects JavaScript, well enough to just compile to very, very readable JavaScript. So, yeah, it's just a different approach on how to do this. And the results are really stunning so far.
Preston So: [00:04:31] That's really interesting. And, and you know, I think a lot of our audience here at the Tag1 TeamTalks a kind of fan base is not really familiar with the ReasonML I understand.
It's, you know, was originally created by Facebook. It's open sourced under MIT. Um, you know, and I know that there's a really interesting kind of, uh. adoption right now happening of ReasonML because of its compelling tool chain. And I know that - you know, I understand, for example, that a ReasonML's tool chain actually outperforms TypeScript's. I'm curious, could you talk a little bit more about the tool chain and, and what's in there?
Why is it so great and why are people flocking to ReasonML well for the tool chain?
Patrick Stapfer: [00:05:09] So the tool chain is a very interesting aspect of this whole project. So the compiler is then like, is rendered by one single NPM package. So you do one install and you get a compiler, you get the language, you get like the only thing you need is a single configuration file like TypeScript has as well.
And define one single directory and the compiler would just pick up your Reason files and compiles it to the same JavaScript file name. Mmm. And, and it's so fast and this is just a way how the compiler is being designed. Like the first principle for the compiler is to be as performant as possible. So they like, I don't want to go into the nitty gritty of the compiler itself, but it's using like really aggressive strategies to isolate the modules into specific compilation artifacts. And it also don't it, it also doesn't try to run like a process and be in watch mode and then do incremental builds it has a different approach. It will just. Mmm. Do a clean build, like super, really fast, and later on when you change a file, it's, it is clever enough to understand the relations to each module, which a lot of compilers do.
Um, but it does it in a way that's more efficient. So usually when you're just changing one file after a code build the, the, the change is not even noticeable. Like the co, the compilation step is so fast. You don't even know if you're. You know, like watcher has been updating or if it's, if it recognized the run because it's so fast and like I always had problems.
Like when, when I was using TypeScript in code bases TypeScript is written in TypeScript to compile itself. So it's based on the JavaScript run time. And that means it comes with the bulk of theJavaScript runtime. So to boot up times and, and just the way data structures are like, are organized inside the compiler just makes it a little bit slower than if you take a compiler compile it to native code, which is running on bare metal, compiled to each platform.
This is also what the backup script or the Reason compiler is doing. It's compiled to, to native and yeah, that's probably the way why it's fast.
Preston So: [00:07:47] So let's take a little bit of a, of a real world perspective here. You know, because I think that this is really interesting to me. You know, I think that the fact that the compilation step is such a sort of a, a focus of optimization of real world, of real, real ReasonML, excuse me.
Um, I'm kinda curious, how does this apply to the real world? Is there something, is there an example, for example where you have seen ReasonML really speed up a project or helped with some obstacles in a project. Why would ReasonML them out be a better choice for projects?
Patrick Stapfer: [00:08:18] So, a few things, like, but I would like to say is that there are certain scenarios or certain applications especially why you want to use ReasonML.
Ao as I said, like the type system is, is strongly typed. So every, every value in your program has a, has a properly applied type. And, that makes it also, this forces you as a user to, to handle certain scenarios. So if you're having like, specific, like requests to an API, you can design it in a way that it returns you different branches of a result which means you are forced to handle cases such as, This request didn't report back the right date, like, it didn't report back because of a server error. It didn't report back because the promise or our to the request was just dying or we didn't even ask for data yet. This is also a scenario a lot of people don't account.
So what you often see is it's like inconsistent UI in React applications where the loading screen is like. Loading, although you didn't even type something or you typed something previously and then there was an error and suddenly chose the loading spinner. There is some, there are some very funky situations where you want to make sure that the UI is working.
So for instance, we had some interesting case like products, mission critical applications. Um. We were talking about it at ReasonConf 2019, in Indiana. Uh, for instance, there's an app called FAST-ED, which is an auto first responder app for paramedics to assess patients symptoms of brain strokes.
And this is also very important. Like if you're like tapping and you're in the app and you're having a patient there and you're not sure, what's happening right now? And you're tapping, tapping, tapping on the decision tree, what should you do? What are the symptoms? And it shows certain things, like certain recommendations, what you should do.
This is how I understood it. Uh, you don't want to have like an undefined is not a function error there. And do you want to definitely be sure that you handled all the cases in a decision tree. And Mmm. I realized that in Reason, this is through certain features of the language, way, way easier to express and way more economic, uh, ergonomic to handle.
And, like in contrary, like if you would do it as in TypeScript, you would probably do, like a certain type of construct of intersection, dissection types that like you have object shapes and each of them has a type attribute in there, for a specific case. And then you need to, if else through this, and just a way how types could work.
And because a switch statements are statements and if and else are statements and not expressions makes it really, really hard to design your program correctly, or , it's just very tedious that people are like taking shortcuts. And then sometimes you, yeah. You just want to compile it to just tell you what you are missing.
And, and for this scenario, it's like amazing. And other application of would be like the Sotheby's, online bidding app. So it's an online platform for high value products such as art or something, which is like. a magnitude more expensive than your average thing you would buy on eBay. there's also like a nice, a ReasonConf talk about it.
This is also super important. Like if you're doing live bidding, you, you want to make sure that the UI is not glitching out. While you're like putting in the numbers, because this would mean that you probably don't, be the highest bidder, and stuff like this. There was another application, which is made by CCA dot. IO. it's a railway safety app for the French and Swiss railway traffic companies or societies or, but whatever the organizations are called. And this is also super mission-critical. Like if you have a train and the train passes the red light, The train conductor needs to report back to the, to the mission control and, and tell them what happened and how it happened.
And there is a huge, very complex form for that. Uh, You don't want to mess it up either, because like if mission control is doing something wrong and scheduling the trains wrongly that might be a problem. So there's always, like, again, there's this idea of having a huge decision tree, a huge complex data structure.
And you need to make sure that your program is covering all of these cases and, another example, blockchain technology. There is a blockchain called CODA and they are building debt blockchain in OCaml. So the whole system is in OCaml for handling all the blocks and whatnot. the blockchain wallet is actually a React application.
Or even an Electron application. So they use it. with Reason to, have all the type of guarantees in there as well, and super mission critical, right? Like, you don't want your wallets to glitch out and destroy some data or whatever. Yeah. So these would be like the things, another example of what I think is really cool, like, in a rich text section, like when you're, expressing a system, which also just.
Structured data. It's a tree like data structure in a sense. And, you just want to traverse this tree and render out the correct UI elements and, the way how Reason handles recursion is also super nice. there is also like a dedicated and a notation for Taylor recursive functions. So you can have Taylor recursion and the compiler will optimize it for you if they do it correctly.
And this makes it very, very pleasant to traverse the trees. Also, when you're writing certain parsers or whatever language parse is, or a par strings or all this kind of chess, what would involve like complex logic. So hope I answered a question. It took a little bit longer. But
Preston So: [00:14:29] No, of course. I think this is a really good illustration of some of the, great applications or great situations where you want to use the ReasonML.
And, you know, one of the things that I wanted to return back to just briefly before we jump into a little bit more about some of the real world applications of ReasonML. one of the things that I found interesting, from looking at, you know, our discussion for this is that ReasonML prefers composition over inheritance.
Can you talk a little bit about that and how that makes you know this approach of using ReasonML better than others?
Patrick Stapfer: [00:15:03] Yeah. Um, so in Reason, there is a concept of modules the same way as there are modules in Javascript, but a little bit more sophisticated. Uh, every file in a Reason code piece is automatically a module.
And each module exposes the list of functions, types, a constant value, what not. And you can also have sub modules. And so it's, you can imagine it like namespaces you define a module, my module inside another file module, and you can access it with the dot operators. So my module or my module dots minus that module.
And then you can access all the values in there. And, so it doesn't really. Although it supports class, based hierarchy, object orientation is also theoretically possible, but it's not really well advertised. it goes with modules for everything. There are certain constructs which you can do, so you can create a module and put some elements in there, and then you can include the content of a module inside another module.
So if you want to design some complex, more complex inheritance, like. pattern. You can do it as with modules only. you want to have a certain set of functions? Just create a new module and includes the previous model and then a module, and then override the functionality of it or define the interface of a module as a module type signature.
And, annotate your models. You want a signature to comply to. So you, you have structural, structurally shaped module types. Which can comply to interfaces, but at the same time, you are kind of like nudged in the wave or you just design functions and to functions, receive values. And there is like this convention where you define a type T for each module.
So you create a module user and you define type T as this representative type. And from there on your grade functions, like, get user name or, create display name or make display name or whatever. And it passes in the type T, which is the user type. And this makes it way easier to compose functions together.
Because like, if you want~~ ~~if you want to handle different types, you would -~~ ~~Oh, what do I want to say is you don't really need to think about like making a subclass and then call the super function before. Otherwise it needs to initialize all the values in there and then you have to use this keyword to do this and that.
You don't really need to carry along this implicit knowledge because everything is like expressed this, this just one type. You pass it into a function and do whatever with it. ~~Mmm, ~~yeah. Does this like the thing, and then you have like the pipe operator, which~~ ~~makes it possible to chain function calls together in a very nice way.
So you would create a user for instance, and pipe it into the get display name function and to get display name function should be uppercase. So you pipe it into the JS string, uppercase function and everything would neatly line up as this, you have to value it and you have a pipe operator.
Next function, pipe operator. Next function. This~~ ~~allows to built the smallest functions possible. Of this specific module type. And then~~ ~~if they have more complex use cases, which are usually would encode in a method of whatever~~ ~~you just ~~ ~~create a new function~~ ~~chaining these things together.
And since first class functions are, are in JavaScript are a JavaScript feature. There also a feature in ReasonML of course it's very easy to just create the things you need at the place you need them. Instead of like thinking about an architecture and like, okay, I need this. They express a function for that.
And some people would then say, okay, yeah, let's make it a more specific subclass for that. And suddenly everything is getting more complex than really necessary.
Preston So: [00:19:19] And I think you see this quite often when it, when it comes to React code bases where you're having to, you know, invoke super all the time, having to pass all these props all over the place.
And, you know, there's, it's, it becomes really, Kind of confusing to understand how the components can react, inherit to one another and how they're handling each other. I'm very curious, does it, does the module handling and the approach that, that ReasonML takes with the, you know, with some of the syntax and with some of the module handling, how does that, improve, let's say, how people handle state and React components or, or how people handle React components and their complexity in general?
Patrick Stapfer: [00:19:55] the most important thing is that like for state, usually have some kind of structured data. for instance, you would have, like an object expressing a certain state. So if you're having Redux or whatever, you have to store and to store, express a certain set of values. And. most of the time what people want to do is they want to have this reducer pattern, but they want to dispatch an action and depending on the action, transformed the state, to a new state.
And most of the time, this goes hand in hand with immutability because they don't want to mutate that object. So what people do in JavaScript is they use the spread operator a lot. the object spread operator, which creates a new object of new object. So you make sure that everything is like, referentially not equal and a newer object.
And in ReasonML, we have records by default and records look like objects. So they have a closure and they have attributes. But they also compile to JavaScript objects on the JavaScript side. So these are very easy to interrupt. but they are immutable. So you have immutable records, you can use for your React components.
You can use the use reducer hook. You can use all the hooks there. Are there a bindings to, like there are official bindings from Facebook to Reason React, to ReactJS, they are called reasoned rec. And you can use your use state hook, do all the things in there. when you're setting a stage or if you're using a reducer, you can do the object spread operator as well in records, but, they are immutable by default, and they are also optimized on the JavaScript side there.
So if you look at the JavaScript output, when you're doing the spread, it looks different than when you do it in JavaScript where you need to spread it, which has a run time overhead. Also another thing, since we have just one, like everything revolves around free concepts. Like we have modules, we have, variant types and are maybe all the records and we have pattern matching.
And the thing, these are like, I mean, these are a topic on its own, but the ideas that you can express with a variant, you can express certain States which are just explained by, by words, for instance, as I said, the request, which is not asked, pending success or error. And it can also contain a payload.
And with that, you can. You can express your intent, yeah. And I'll check it off. Type something with this action name and this action name, and then it has certain junction parameters in there, which you can access when you do, if and else in pattern matching, you can use the switch statement, which looks like a switch in ReasonML.
And match on this specific patterns. You can look into the success pattern for our re hold up the payload and check if the payload has a specific string value in there and then excess that and like I go into this branch and do some logic in there. If you happen to end up in this case this makes it so nice to ---- your users.
There is like no comparison. Um, when you have more complex data structures like rich text tending or whatever yeah. This the way to go. So in that context, I feel like handling state is easier and expressing the status easier.
Preston So: [00:23:42] I couldn't agree more. Um, and I'm very excited to do this myself after this.
So, so let's take a big picture view now. You know, I think that we dug into a lot of the syntactic or some of the architectural features of a ReasonML, but let's dig into some of the kind of real world use cases that are mission critical that we wanted to talk about today. I'm curious. Um, we talked about how, you know, ReasonML improves the.
The debugging experience, the developer experience, state handling, all of these things that are very common needs in JavaScript.
How does it make websites more resilient in general or more stable in general? Are there certain features in ReasonML that are led themselves to, let's say, stability in the sense of how we think about it in the, in the business world?
Patrick Stapfer: [00:24:27] Yeah. So as I said before, like this, whole. Correctness, or the quality of two types, it's very important to ensure that the runtime is running correctly. Um, most of the time we are used to type systems, which just allow mixing. Um, unspecific values with correct values, which completely destroys the point of having types, in my opinion.
Um, when you're consuming a library, which introduces any types everywhere, suddenly your whole code is in question. Is it correct? Is it incorrect? And this impacts the whole development process. Like, just imagine you have a code base which guarantees you. That when it compiles, it will run the way the, the program has intended it to run in the type space, that makes a huge difference and gives you way more confidence when you're committing code and see the CI runs through and is like, okay, now I just need to see if the tests are green and we're fine.
And with what I've experienced with, with ---- type systems or with plain JavaScript, you have no confidence. Unless you have a very, very strong team discipline. No. Soon as they have a little bit more developers on the team you will find that people will use escape patches in many places which are hard to spot.
And in case of Reason, since you have older, necessary facilities in place to, to just write. You get into this pit of success, that's probably the thing. The compiler guides you to a working implementation of what you're trying to express and still gives you the flexibility to, to escape from that in an unsafe space still, which is well isolated and well, and way easier to spot.
Mmm. Then if you're just like assert and any type in this specific case, in this little, if branch, which looks like an as something, like, okay, does this super hard to spot in quarter years as well. So I think it's not only technically helping writing better, more stable websites but it's also socially helping.
Giving the engineering team the confidence in committing stuff and merging stuff. Like if you, if they see okay to compile, process goes through, I'm pretty certain this, this works the way it should be and it will not crash. That's the most important thing.
Preston So: [00:27:22] I think I'm a lot of developers around the world definitely identify with being able to just hit compile and know that when it's compiled and it works, it's just going to be a completely stable code base.
Um, yeah, that's, that's a very interesting, and um, I'm kinda curious though as well. Um, you know, we talked about some of the big names that are already using ReasonML people like Sotherby's Swiss Rail, I believe you said. Um, what are some of the other names who are using ReasonML? Are there any other well known companies or projects, even in the open source world, for example, that are depending on Reason ML or leveraging ReasonML in some way?
Patrick Stapfer: [00:28:00] Um, there are a lot of companies, but probably the bigger ones people know are McKinsey. For instance, also a big consultancy, SAP. Um, Jane street, which is doing a lot of financial computing Tezos partly because also the Tezos uh, blockchain technology is built on OCaml, which is the same heritage and Ahrefs, which are doing SEO related tasks and tools.
Um. So these are like the bigger ones, but there are also other probably more startup-esque companies are relying on it. For instance, Draftbit - Draftbit is building like a codeless. Mmm. A codeless editor experience for writing React Native applications built on Expo. So this one is really, really exciting because I feel like it's a very complex project.
And, and I can really see that they will benefit from the technology, just the way how complex it is. You need to keep all the context in your head and Mmm. You want to make sure that this context, the compiler gifts your back is actually correct. So, um. And out of that, that's a, there's also a Travel World in Austria, which is also a startup.
Uh, they also started adopting it and they kind of liked it. Like they were also evaluating a lot of options. What, what should what should be used? Like, should they use TypeScript or should it go further with plain JavaScript? Um, but these companies from every company I've been talking to, like all of them are really happy about the decision they made.
So hopefully they will still be satisfied in the future. Sure. Uh, I'm pretty certain. Mmm. Yeah. But it's, it's on a scale from very small to very big there is there is players everywhere are using it.
Preston So: [00:30:10] I think we're really seeing that level of penetration that is indicating that finally, I think ReasonML is, is, you know, well on the adoption curve maybe past the early adopters stage to the early kind of a pragmatist stage, which is really exciting because I think, you know, the fact that we're seeing McKinsey SAP adopting a ReasonML is, is it as a huge testament to its success.
Um, so, you know, I know ReasonML is open source. And you know, at Tag1, we love open source, obviously, and I love open source as well. Um, but you know, all three of us have been in the open source world for a long time. Um, I'd love to learn a little bit more about the ReasonML community, you know, I'm, I'm very used to the React community and the Drupal community and, you know, some of the other communities that are a little bit more focused on, you know doing really nifty things with the front end, but not necessarily doing really nifty things with functional programming.
And the underlying language and linguistic features. So as I'm really curious, you know, what is the wisdom, the ReasonML open source community, like what, how, how have you worked with the ReasonML community? Um, and how are you helping kind of the dance that community and ecosystem forward?
Patrick Stapfer: [00:31:16] That's a really great topic because of the things to the Reason communities. Even though it's a little bit smaller than the JavaScript community, obviously it's a very focused and very, very friendly community. So most of the people are aligned on certain values. Um, they have a certain paradigm in their head.
Uh, on a technological level, but at the same time, they are like super laid back and helping each other. Uh, the best way to engage with the community is via discord chat. There is a, there is a ReasonML server for that and there is like the cool thing about it since the community is so focused and enthusiastic.
Um, when you were starting out with ReasonML, you're dropping into the general channel, for instance, and you're just asking dumb questions about, you know, how do I define a specific kind of type? And you can be sure that there is like a response time of like three minutes and you will get like a straight forward answer even with examples because people are just like, they want to teach it and they want to help out other people.
It's, it's very, it's, it's lifting you up when you see that kind of like enthusiasm and there's also a lot of open source going on. ReasonML itself is pretty much like all open source across the whole stack, sort of compiler the language. Um, everything is, is basically a license with MIT or more liberal licenses and so what I'm currently working on, like in the Reason Association, we are like a foundation, a legal foundation around it to, to support development in the community. And what we are doing right now is we are revamping the documentation platform for ReasonML that you have all the necessary information on there.
Mmm. Like for as Reason, as the language for the compiler specifics for Reason React specifics and the APIs and whatnot. And this all. A community effort actually. So I mean, I tried to, to initiate it, but I also tried to encourage people to contribute. And it doesn't even matter if you're like a complete beginner or like advanced user.
Right? Or super expert or combining a first time contributors who are complete beginners to the language because their input value is a lot like they, they know exactly. Okay, I have a problem with,how do I do this specific pattern in Reason React and I know how to do this. And I learned it right now, so I better contribute it back and, and I have great hopes that this new platform, which is called ReasonML.org will. Like super super charge the community that people are like coming to the platform, didn't know straight away how to use everything. Um, yeah. So the community is great. That's probably the summarization.
Preston So: [00:34:29] Well, it's very exciting. I'm very interested in getting more involved with the ReasonML community. Um, and I understand also that you organize ReasonConf um, you organized ReasonConf of 2018 and 2019 in Vienna. Um, tell us more about ReasonConfand how this idea came to be. Um, what's the community like in Vienna?
Um you know, as an event organizer myself I'm, I'm very interested in this topic. Um, how did ReasonConf come about and what's it been like to help with this whole conference circuit?
Patrick Stapfer: [00:35:02] Um, so ReasonConf 2018 was the very first conference for ReasonML. And it all started out with like a small meetup group in Vienna, which is called React Vienna.
Mmm. It has grown so substantially the last few years. Um, but we had this like thing going on before ReactiveConf in Bratislava. Where we invited speakers from like who were traveling to Bratislava. And one day before they came to our meetup and talked about their talks and it was really great. And there was also people
Uh, talking about ReasonML, like Sean Grove, Jared Forsyth that really great influence on how I think about Reason right now. Um, and there were also people from the Facebook team. Mmm. Coming to this conference and also talking about ReasonML. And, and we were just like we just had found also like our own ReasonML meetup there.
So I was really interested in like, how can we push this forward, talk our, how can we make this a little bit more like big in a sense. And we had discussed it and we were like asking, okay, what if like this idea? What if we just organize the conference, which is just the goal of this conference is to just get people on board and get them started.
And this was the tagline of the first conference. Mmm. Getting started, like how, what, what is it for? I'm a complete beginner. After our premise was after three days, you go out and you can at least write a simple React application with Reason, that was the outline, and we had all the core team members there working on the syntax, working on the compiler and on the first day we had a workshop day , people were like hacking on some exercises.
And we had questions they could ask the maintainer compiler, or ask ----Facebook and they were super, super nice, helping out. Um, and the, on the second day we had our conference itself and had some really nice talks about where it could go. And on the last day we had a heck of fun and also a little Vienna tour.
So people get to know each other. And. It was a very, very low key conference. We didn't do much advertising or whatever, just put it on Discord. We advertise it on our Twitter and the community was picking it up. And everyone was coming like , you went to the conference and you found people and they are like, Oh, I'm this guy on Discord, and you're like, Oh, this is how you look like, okay, I didn't expect it that you're also here.
So it was a real, it was really like a family get together after people have been contributing so much to the ecosystem already in the first conference. Um, and then the second conference in, in 2019 it was a little bit more mature. I would say, because people are, you know, in the beginning it's like the hype phase.
People are really excited about it. We have enthusiasm working on tooling and, and building libraries. And the second conference, we wanted to focus this aspect, that ReasonML is not just a toy, but more like a real major platform you can build on now and you don't have to wait. So the 2019 motto was, On the road to production.
That's why we have a lot of, Mmm. references in there about ReasonML 2019 because people are talking about the applications and why do you use Reason? Why they like Reason? I think there is not enough coverage of how popular it is. So this, this was basically to goal .And we also did this three day thing where we had the first day of work shows again, but with the difference of you also offered more advanced stuff, which is, for instance, in OCaml workshop. Or people could also dip their toes into real, like hardcore functional programming. Mmm. But on the other hand also had our front end oriented Reason React specific workshops as well.
So we try to kind of bridge the gap between both communities. Um, and. We also had a U S installment, actually, there was in Chicago in October, 2019 we had a specific conference about the U S uh, community. And John Walk was also talking there like it was the first time after our long period of no talks.
Uh, his last talk was about ReactJS when he introduced it to the public. So that was kind of a big deal for us. And I think his keynote was also like super inspirational for the community. And people are really excited about this. Uh, for 2020, we didn't plan a conference, which we're lucky because of the current situation with the virus, of course.
Um, but our plan was to have another conference in 2021. Uh, also in Europe, probably. Uh, but we can also figure out a U S uh, location as well. But we wanted to go back to the 2018 vibe, for people are like coming together. We, we tried to, we really tried to advertise this whole Reason for JavaScript, Reasons, for Reason React.
Uh, kind of branch people with JavaScript experience should just come and just see what the Git or TypeScript users and, and get inspired. What is still possible. Like you can even squeeze out more type efficiency in your code just by using the right language and this would, probably be like in 2021.
Then I'm really excited about it. So it's a, it was a great journey so far like. I would do it again if it could. Mmm. So, and I always encourage people, like if you, if you are having an idea of having like a Meetup or whatever, because a lot of people asking, Oh, is it, is it hard to have a meetup about Reason?
Uh, I totally encourage just to do it. Like, just try to peak interest advertise a little bit, maybe reach out to some other organizers to give you advice, a lot of people helping out great times. Um. Just, yeah. I encourage you to do it as well.
Preston So: [00:41:53] Wonderful. And with that, we are running a little bit out of time here.
So I think that was a wonderful call to action for our audience to get involved in ReasonML check out ReasonConf talks from years past, and also plan to attend a ReasonConf 2021. In Vienna, is that going to be where it's going to be or most somewhere else?
Most likely. Okay. Well, I'm very excited because it's been years since I've been to Vienna, so maybe I'll make a trip out there to come and say hi.
Um, so the a, and now for our new segment that we've just introduced over the last couple of episodes, the Aside Tag here at Tag1 TeamTalks every one of us is going to give about a minute.
Of something that's interesting and going on in our lives that we can share with the audience and just meant to be something really fun for about 60 minutes.
Shameless plugs. Welcome. So I'll go ahead and start and then we'll go to Patrick and onto Michael Meyers. Um, I run a conference, by the way here in New York City called Decoupled Days. And you know, your discussion just now, Patrick, of, of some of the challenges around how ReasonConf 2020 would work theoretically and also some of the other conferences, of course, Vienna and Bratislava, that are.
That are suffering. Um, we are so Decoupled Days 2020 is the fourth year of the only conference right now, the only conference in the entire world dedicated to the future of
CMS and their architectures. Um, so Decoupled Days, 2020 is happening July 22nd through 23rd, 2020, but we've just decided to not have it in Manhattan, New York City, and instead to take it virtual, it's going to be online on Zoom. We're going to be posting this more information about it, or by the time you watch this information will be posted about our new conference being virtual. And I'm very happy to welcome everyone to our new virtual conference, including people who are not going to be in New York City.
So that's my little shameless plug. Uh, what's going on with you, Patrick?
Patrick Stapfer: [00:43:46] Um, I have very, very specific topics in my life.Which are troubling me. Like one of them is like history of Europe, and there's this one specific Royal family, which is called the house of Hapsburg. Um, and it's such, I have, I've got a book which is settling German, but it's about short insights into the timeline of this Royal house and, and I learned that once an Austrian Royal was promised by Napoleon to be the Kaiser of Mexico, and he actually arrived there, he went to, he went to Mexico.
He started his new position, but unfortunately not for long. And they got kind of. Are they, they were really fond of their democracy and they got back backup from the US so it was, he was done for. That was a very interesting insight. I didn't know that. Mmm. I don't know that. Uh, the, the, the crisis actually, like the Corona crisis caused one issue.
It's very hard to get yeast from , from the stores. So I had, I, I dunno, people suddenly turn into bakeries everywhere, so there's no yeast. So I was like complaining on Twitter about it and someone was pointing out that you can actually grow your own yeast. And I realized that's true. It's actually super easy.
You just take a bottle of water and put into like dates, or other fruits, dried fruit without sulfites and um, put in spoon of sugar. And then just let it stand. Maybe shake it a little bit and let it stand for a few days. And you will see that it develops a yeast in there and you can use it for baking.
So if you're out of yeast and your interested in baking, you should try that. It's super easy and super cool.
Preston So: [00:45:44] I can't count how many coworkers and friends I have who have their sourdough starters. Uh, baking up a storm. It's really a, I think at the end of this, we're all going to be owning our own bakeries from our work, from home situations.
Yeah. So what's going on with you, Michael?
Michael Meyers: [00:46:01] That's, that's amazing. Patrick. I've been doing a lot more cooking as well. I reserve Sundays through like really big, complex, interesting meals and experimentation and definitely find myself with a little bit more time to cook. Um. I wanted to talk today about another quarantine related thing.
Uh, we recently moved up to the Berkshires fortuitously at the beginning of this year. And I've been trying to solve my internet and wifi problems, which I've talked a lot about. It's my my, my sections here and I, we just don't have enough coverage. And so I was talking to our infrastructure team about it, and they recommended the Ubiquity networks, the Unify access points, and they have indoor and outdoor access points.
Um, and I'm blown away. They're the, it's, you know, fairly more complex than, you know, your typical Linksys router. Um, but you know, the access points outside get 600 feet of coverage in either direction and we only need one access point internally. And so, you know, with, with three pops, we're able to get coverage over the immediate area.
And it's been fantastic. I can get outside and get a little bit of sun and talk on the call via VoIP, you know, throw the ball around with the dog while I listened in on a meeting, which I'm not doing. And, uh. You know, it's, it's really helped, you know, get out of the cabin fever a little bit. Uh, but also, you know, give everybody a little bit of room to roam.
So check out the ui.com for their crazy, and it's like ridiculously affordable for, for the kind of technology it is.
Preston So: [00:47:45] Wow. Wonderful. Well, I'm excited to hear more about the continued saga of internet connectivity for the, you know, glad to hear that it's finally resolved and that you're able to take Leo out and still be on a call. Oh, that's the most important thing.
Michael Meyers: [00:48:00] It's, it's not even remotely resolved, but now you can get a really bad internet connection anywhere.
Preston So: [00:48:08] That's great. I love that. Um, Alrighty. Well this was ReasonML. Um, I'm very, very excited about this topic and um, I'm definitely going to be digging into some of the materials that Patrick just mentioned here today, and I think he did a really good job of covering not only why ReasonML was so compelling from the developer experience standpoint, but also from more of the business standpoint.
Um, once again, thank you so much to Patrick and to Michael Meyers. All the links that we mentioned today are going to be posted online with this talk video. And if you liked this talk and you want to hear more about ReasonML, or about other topics, please remember to upvote subscribe, share it with your parents or grandparents or neighbors that socially distance of course.
Check out our past Talks at tag1.com/tagteamtalks. And as always, we'd love your feedback on any topic suggestions. Please feel free to write to us to tag1teamtalks@tag1consulting.com I want to thank Patrick Stapfer who was very, very very gracious to join us from Vienna today. And also Michael Meyers, thank you so much for this episode for joining us on this episode.
And until next time.