Marc-André Cournoyer is the founder and president and Code Monkey at Coded Inc. They explore the intricate details of Ruby and its integration with various technologies to create robust and secure solutions. They enlighten us with their expertise on event-driven frameworks and the importance of simplicity in software development. They also uncover the pioneering work of Shopify with the liquid templating language and the potential of leveraging Rust in combination with Ruby for enhanced safety and performance. Additionally, they delve into personal anecdotes and local business highlights, adding a human touch to the technical discussions. 

 

CHARLES MAX_WOOD:Hey, welcome back to another episode of the Ruby Rhodes podcast. I'm your host, Charles Max Wood, and I am here with Marc-Andre Cornoyer. It's been a minute since we've had you on the show or talked about any of the stuff you're working on. How are things going over there? Are you in Toronto? I know you work in Toronto. 

MARC ANDRE_COURNOYER: No, I'm in Montreal. I mean, you got it right, I'm in Canada, but I'm in Montreal. Right. Yeah. I do go to Toronto sometimes. But yeah, no, from Montreal. 

CHARLES MAX_WOOD:Yeah, my grandparents met in Montreal. 

MARC ANDRE_COURNOYER: Really? 

CHARLES MAX_WOOD:That's a very nice city. Yeah, yeah. Yeah, funny story. And they don't encourage this as much anymore, but my grandpa was a missionary for the LDS Church. 

MARC ANDRE_COURNOYER: What? Really? Wow. 

CHARLES MAX_WOOD:And my grandmother had joined the church in France and then immigrated to Argentina and then Uruguay and then to Montreal. And she was working in the French embassy there. 

MARC ANDRE_COURNOYER: Really? So did your grandparents like this, spoke French? 

CHARLES MAX_WOOD:Yeah, well my grandmother did. Okay. My grandfather spoke a little bit of French. Okay. 

MARC ANDRE_COURNOYER: Do you speak French a little bit of French? 

CHARLES MAX_WOOD:Ah, je parle un petit peu de français. Very, very little. Okay. Um, I studied French in high school. So I think a total, I did like six years of French and then I went and lived in Italy for two years. So, 

MARC ANDRE_COURNOYER: Oh damn. 

CHARLES MAX_WOOD:Okay. It's. It's a, it's French is a mix in my head. Yeah. 

MARC ANDRE_COURNOYER: Maybe I guess, I guess I don't know. Like if it's, I don't know if it helps with Italian. Did it? Yeah. It seems very clear. 

CHARLES MAX_WOOD:It did in the sense that a lot of the grammatical structures are similar. Ah, yes. Okay. And a lot of the ideas in learning the language were similar and some of the root words were similar, but not all of them. And so they didn't have to teach me, oh, you congregate verbs and things like that, because I mean, in English we. We just use the same word for all of the conjugations. 

MARC ANDRE_COURNOYER: Yeah. 

CHARLES MAX_WOOD:Anyway. 

MARC ANDRE_COURNOYER: Yeah, that's the hard part for sure. Well, I mean, it's hard for everybody. I remember when I started, like the fact that because I joined the startup community in Montreal, but everything happened. So I'm French-Canadian, right? I've been speaking French my whole life. I was raised in French, school in French too. And then when I wanted to start working in startups, because they were using Rails and Ruby and all the cool stuff. I had to, it was my first job speaking in English. And I was so stressed because of that. That would practice like the interview, just because it was in English, right? Sure was fucked it up. But it was not that hard, but the hardest part is the idioms, right? Or the expressions. Oh man, that took me like 10 or 15 years, even today, right? Sometimes I have no idea what people are saying just because of those like contraction or expression. 

CHARLES MAX_WOOD:Yeah. Yeah, there's something going the other way, but I didn't find as much of it. Yeah. But anyway, yeah. And, you know, you're, you're in your French Canadian. And I think my what fourth or fifth great grandparents were French settlers in what is now Quebec. So yeah, yeah. Okay. Yeah. Crazy stuff. Anyway, 

MARC ANDRE_COURNOYER: French history and your family. Cool. 

CHARLES MAX_WOOD:Yeah. Yeah. It's funny because and then we'll start talking about thin and technology. But So, I'm a Latter-day Saint and in the temple we do proxy ordinances like baptisms and stuff for people who have passed on. And so, it was funny because we had kind of exhausted all the stuff on my mom's side, which is where my grandmother, who's French, you know, all of her. And so, my uncle started giving us names of ancestors and relatives from my dad's side. 

 

And my kids had gotten pretty accustomed to, you know, having French names come up fairly regularly. And then for a while it was my wife's family that we were doing work for. And so it was mostly English and like Scandinavian names. And then we started having French names come up again. My kids are like, oh, we're back on grandma stuff. And I was like, well, actually, this is on my dad's side, not my mom's side, because they lived in Quebec. And then they immigrated at least like six or seven generations ago, they moved to Connecticut and Vermont, and then kind of work their way. Well, that's west. Okay, cool. Yeah. 

MARC ANDRE_COURNOYER: So where do you live now? Where is it? 

CHARLES MAX_WOOD:I live in Utah, Utah. Okay. Yeah. Anyway, but it's it's fun. I love this stuff. So it's fun to kind of connect over it. 

MARC ANDRE_COURNOYER: It is interesting for sure. I don't know that much the history of my family. I think we've been in the Montreal region for a while for sure. 

CHARLES MAX_WOOD:Right. Most of the stuff that I have now, granted this is also run by the church, but familysearch.org is where I get a lot of the information on my family. You can also find it on like Ancestry and things like that. But effectively, if you're interested in it, what you do is you sign up for one of those systems. FamilySearch is free. And if you can...If you know back two, three, four generations, usually you just have to connect to your grandparents. And once you find your grandparents records, then it opens everything else up. And family search has photos and stories and all kinds of stuff. So if anyone's interested, go to family search.org because that's where that's where I pick up, pick up all 

MARC ANDRE_COURNOYER: that's a great ad right there. Yeah. Ah, no. Okay. Yeah. 

CHARLES MAX_WOOD:Okay. But anyway, So yeah, I think we initially invited you to talk about Thin. And you were saying that there was somewhat of an interesting story, but I guess before we get there, what is Thin? 

MARC ANDRE_COURNOYER: Oh man, Thin, well, Thin still exists today. The repo is still there. It's still a gem that is, I think is decreasing in popularity for good reasons, but it's a web server. Exactly like in the same vein as Puma, Unicorn, Falcon, and all of it's a rack server. Right. So you can use it today, Gemyn Solothin. But I started the project 16 years ago, so it's quite old. I wouldn't say I don't actively maintain it. So, and I haven't had any major issues in a while. Some people have helped me maintain it. Samuel Williams was a great help, like a year ago or something, did lots of cleanup. I don't know if you know him, he created Falcon. 

CHARLES MAX_WOOD:I just met him. I interviewed him for the Ruby Dev Summit. 

MARC ANDRE_COURNOYER: Okay. He's really great. I mean, he's been, just the work that he's done with the fibers and fibers scheduler and Ruby tree is amazing. And that's just a fraction of the stuff he's been doing. So a big fan of his work. Um, but yeah, so thin is that it's actually one of, I think it was the first server that was a rack server at the time when I created it, rack was just starting up about 16 years ago. The creator of Rack, Christian, if I remember correctly, his name, created it, but he created some wrappers around the existing servers at a time. Like Mongrel was the big one. Yeah, Mongrel was huge. Yeah, I forgot what the other ones were. Like WebRick, of course. It was WebRick. We still have today, but it was the only options that you'd have. Or you would run on FastiGI. Yeah, or FastiGI. That was the way that you would run your Rails application at the time. And it would crash all the time. Oh, yeah. That's what people told me. Like part, I was very, I was young at the time, younger than I am today, but I was starting my career. So I was not running like a very high-traffic website or like a company at the time. 

CHARLES MAX_WOOD:So I still remember though running WebRick or fast CGI and setting up a watcher that would keep track of how much memory my Rails app was using so it could go and kill it before it ran out of memory. 

MARC ANDRE_COURNOYER: That's the story. Yeah. Everybody had those stories. Like it was like everybody, some people say, Oh, I was the trend. It's crashing in a trend. And a bunch of those stories get around. So I think that's how I got the idea initially, because I heard, right? I heard some people say, well, I'm using Mongrel, but it keeps crashing. Or FastCGI keeps crashing after it started. Like exactly, like you said, people had cron jobs to kill it and to restart it because it crashed all the time. And I heard that it was like Mongrel was crashing in the threading code, right? For some reason. And I look at the code of Mongrel. And if you look, if you go back like to 15, 16 years ago, rails was not tread safe at all. So you could not know it was not reentrant. So you needed a mutex around rails before you call into rails. That's how the web server did. There was a giant mutex that I don't know that right. So even if you had like mongrel was it was very equivalent mongrel to Puma that we have today. So I'm not Puma is I think is a lot better in a design and also related to performance. But like in the concurrency aspect, it was very, very equivalent. But the problem was that at the time, I think that maybe treads were not as stable in Ruby. So they would crash. And then the thing that blew my mind is the treads are crashing and we're not actually using treads for the moment phase because there's a giant block around Rails. So I thought, that is stupid. We got to get rid of this. So my own idea was very stupid at the time. We said, I'm just going to create a server, no treads at all. Just get rid of the treads. No concurrency. 

CHARLES MAX_WOOD:I'll just write my own web server. Yeah, no problem. 

MARC ANDRE_COURNOYER: Yes, that's what I said. Like my name was a pure Ruby server that has no thread, no concurrency at all. Just sequence, right? Get one connection, send it to the framework and then back and that's it, right? Just the simplest thing that could possibly work. And I said, well, that's going to be more stable, right? I didn't really care about performance. And then that's where I discovered about Rack. And that's the cool, that's where I realized like that. I think that I was onto something, not because of the performance, just the nice way of their API felt so great. Like if you rewind back to that time where playing with this FastCGI, the CGI API of Rails, that's how you would, if you were implementing a web server, there was no common interface. So Rails had to add some code in it to run a FastCGI, some code to run a WebRig. This was all like bundled inside Rails. There was no API in the middle. And if you wanted to create your own framework, you had to redo this whole thing like from scratch. And it was awful. Like this API was awful, purely awful. But if you introduce Rack, Rack was super simple, right? Anybody I think can go, you look at it, you look at the Rack API, you can understand it. Like it's like five lines of code described to all API. It's blue. 

CHARLES MAX_WOOD:Yeah, I remember when Rack came out. Yeah. So did Zed write Mongrel in something other than Ruby? Is it written in C or something? 

MARC ANDRE_COURNOYER: Yeah, so Zed Shah was the creator of Mongrel. It was very vocal and colorful. Little bit. Like a member of the Ruby community. Well, that was part of the fun too. Like I think at the time we had Wydellicky Stiff, Zed Shah, lots of people, very colorful. And that's what got me into the community. I really felt like I could. It felt more. Artful, I would say, I don't know if that's the right word, but like the scientific will to me, it's much closer to how I think about projects, or at least projects that I do, right? There are way more artful projects than like scientific projects. So yeah, Zezhe was a big member of that. 

CHARLES MAX_WOOD:Yeah. 

MARC ANDRE_COURNOYER: And so he created Mongrel, and Mongrel, a large part of Mongrel was in Ruby. The part that was in C was, I think that was the big innovation of of the mongrel was that the parser was in C was very strict. So it was kind of safe. It was the safest, one of the safest parser at the time. It was based on mongrel, raggle, sorry, raggle. I'm not sure if I'm pronouncing it right. But raggle is kind of a, it's a state machine generator. So you give it some rules and then it's going to compile to whatever language. I don't know if at the time you could compile to root, but you can today. But you would just like lay the rules. Like it's like a lexer, very similar to a...lex or... So it creates a state machine in C and then you can pass it a string and it will call the callbacks depending on what's inside. So that allowed him to have a parser that was super strict. So it was very hard for somebody to craft like a request that was malicious because it was so strict. So that was the reason why Muggle was widely more secure than the other parts. Right. So that was also, I think, Zed Shah's proudest part of the server for good reason combination of technology. I don't know that anybody before him had the idea to use Raggle for this type of work, but it was brilliant. So I said, I'm going to pick this up. I'm going to pick up the Raggle, the good part of Mogroll, which is the parser, makes it super secure. I'm going to pick up like Rag because Rag is the nice API. So combine the two and the only thing that was missing is how do you do I.O. really, right? The networking part that I did not know. And at some point I ended up on a a library that was not very popular at the time. It is not popular no more at the time. Now it's called Event Machine, but it used to be very, very popular in a Ruby world. It was kind of a precursor to Node.js. It's the same exact concurrency mechanism as Node.js. I think it was an inspiration to Node.js too. But now it's not actively maintained anymore. But back in the days, like lots of the... For example, at GitHub, they were using Event Machine for lots of the stuff that they ran in true. Because it was made, it was an asynchronous server. It was kind of a first sync non-blocking IO library to be used in Ruby. It was very stable. It was much more stable than Node.js at the time. So if you wanted to do a sync IO non-blocking IO at the time, and you could not really use Node.js at the time. It was leaking memory everywhere. And Event Machine was a much better choice. 

CHARLES MAX_WOOD:Yeah, Event Machine was...Yeah, you can see it in some really interesting places too. 

MARC ANDRE_COURNOYER: And he was crazy fast. And I mean, I took no credit for the like, I think the reason that Tim picked up is because people would rent the benchmark were crazy at the time compared to the other servers. They were, it was much, much faster. I take no credit for that. This is all a credit to the people who created even machine. I just plugged. I think that's mostly what I've done in my career lots of time. I don't think I'm good at inventing those things, but I think I'm good at merging existing technologies, integrating them, which I did there. It's even machine rack and the mongrel parser. I thought those were brilliant technologies, so why not merge them together? That's what I did with that project. 

CHARLES MAX_WOOD:Well, a lot of times people do things and everybody's like, they're so crazy innovative. And then if you really boil down what they did, yeah and this thing and I put them together and nobody had ever done that before. 

MARC ANDRE_COURNOYER: Yeah. It's, I mean, I don't think anybody has said that. It's something I see often, right? With the more junior engineers or people are starting out with like, ah, man, I don't want to, I don't want to, this already exists, but how usually I don't care. You should not care if it already exists. Usually if you just tweak or you focus on one specific feature or you combine it with another idea, do you have something else that's enough to make something that can become extremely popular or very useful to lots of people. And that's what I realized pre-order beyond. 

CHARLES MAX_WOOD:Yeah, in that particular case, a lot of times that's really what it boils down to is, there are people that have this one particular problem and they're using this thing that solves like most of this part of the problem. And yeah, you make this other really painful piece of the problem go away and wow, you innovated, you know, but that's really what it boils down to. Again, you just solved a problem that. 

MARC ANDRE_COURNOYER: Yeah, I think there are multiple reasons to that. But also, I mean, it's how software works, right? You start with something extremely simple that works really well. The API is extremely clear. It's beautiful, right? It's a piece of heart. And then somebody else comes in, oh, if only you could add this feature. And that would be useful to me. But yeah, that feature. And that's how I think we start off with very nice software that is simple and performant, and we end up with something that is not so good, right? So that's why I think we're...always have opportunities, not only like in business, but also like in open source, right? If you want to do open source, but you're kind of worried that, oh, this has been done already, it's kind of easy. Because if you're starting over with some minimalism or simplicity in mind, you can always like find this. Then it's up to you to keep it simple. But that's how projects are good initially is because they start with just a strict minimum. Right. That's the soul of the product, right? Or the project. And then you just focus on that and remove all the crap. And that's how you end up, I think, with a much better project. 

CHARLES MAX_WOOD:Yeah. Does this get us closer to, yeah, that focus, whether it's performance or, you know, uh, threading stability or right. 

MARC ANDRE_COURNOYER: I think all of those, the qualities that you mentioned are all usually all boiled down to simplicity, right? It's kind of hard. If you want something that is fast, simple and a nice API or beautiful, like when I say beautiful, I mean the API is nice. Use and look at. I think those are all because like it's simple. The software is simple. There's no other way around it for sure. 

CHARLES MAX_WOOD:Yep. Absolutely. So getting back to kind of the story behind Thin. So you take Event Machine. You take...I can't remember the other pieces you pulled in. The parser from Mongrel. 

MARC ANDRE_COURNOYER: The parser from Mongrel, which was built on Raggle. This was the only part that was coded in C. But of course, the internals of even the machine were all in C. It's C++, actually. So I did not know anything about that. And the other part was Rack. Just the API, the Rack API. But at the time, yeah, I think the main blocker with all this, with this architecture that I decided on, was that Rack was just started. Right? 

CHARLES MAX_WOOD:Right. 

MARC ANDRE_COURNOYER: The API is simple, but that's on a server side. Now you have to make all the frameworks and all your work with RAC. So I had to create the first ever RAC handler for Rails. And then once that worked, but it was not, you can imagine, it's an adapter on top of the old fast CGI. So it took some time until, I think it was kind of...It did not feel like a good API until Rack officially switched to Rack. And that's where I think you became clear that this is the future. That's the way to do it. And especially people I think realize this not only because of the Rack API, but the Rack middlewares, right? That's the other key thing. You just learned about the Rack API. You said, that's simple. But then you learned that it's the same exact paradigm that you use to introduce Rack middlewares. And this to me, like, is one of the really big innovation that is an idea that is so simple. And now you see this middleware concept everywhere, right? As it's a node, it's in Rust, there's a tower. They're all using the same exact concept of wrapping the previously app or endpoint, whatever, middleware into the previous one, exactly like Bragg created at the time. That was 16 years ago, and we're still using that idea today. So I think there was a brilliant API. That was the core, I think one of the major reasons that Bragg beat...All of this became successful because of Rack and the simplicity of it. 

CHARLES MAX_WOOD:Yep. So, did Rails adopt Rack when Merb was merged in, in Rails 3? 

MARC ANDRE_COURNOYER: No, I think it was before that. I don't know if... I'm pretty sure it was before, yeah. I think I'm pretty sure it was before. I don't remember who did it, but I remember, yeah, it was done as a push just because it was a nicer design, right, to say, well, we can refactor using middlewares afterwards and each of the parts are more modular. So just with that in mind, it's much, you end up with a much better design. You're right. Let's say that, I think that was the big push why they did it initially was because, well, some apps want to run some API, like Rails API stuff that we still have today. That was the main push behind it. That if you don't need cookies, like if you're just starting a base on API, well, that's pretty easy to skip. If you're implementing it as a rack middleware, you just don't use it. You don't insert it in your middleware stack and that's it. You don't need to do anything else. You don't need to have a bunch of ifs in your code. It's very simple. So I think that's why they refactor it. Initially, I'm pretty sure that was before Merb, but don't quote me on that. 

CHARLES MAX_WOOD:Yeah, I don't remember for sure. I remember when it came in, and I remember pulling in some middleware and writing my own, and yeah, it was very handy. 

MARC ANDRE_COURNOYER: And I would say, I'm pretty sure now, like, rethinking about it, that Merb came afterwards, and I'm pretty sure, too, that Merb became to life because it was so simple now to create a framework, right? 

CHARLES MAX_WOOD:Right. So because I'm on that. 

MARC ANDRE_COURNOYER: Yeah Yeah, would run on standard stuff. Yeah, exactly and mer initially was just rack plus erb That's why it was called was would run on mongrel erb or maybe was not rack. Anyway, so there was was Returned to a much simpler like framework in case like that 

CHARLES MAX_WOOD:Right. So you get rails to run on rack Then what? Now you're home free 

MARC ANDRE_COURNOYER: No. 

CHARLES MAX_WOOD:Not that simple. 

MARC ANDRE_COURNOYER: Oh yeah. Here's a funny story. It's going to make me sound very childish or whatever, but I don't care. So me and my friends, the funny story about then when it started, before it became popular or like in the first few versions, I would test it with some people who had like bigger rep times than me. And we thought it would...Initially, it was not called thin, it was called fart because we thought it would be so funny to run a fart cloud and run in cluster mode. And we would just chuckle all day about this. But then I came to realize, I don't think I want to be associated with a project that's called fart and the people keep... I think just before pushing the button and making it to a public repo, I changed the name right there. And then or something, I think it was a good decision in retrospect. But I still find it funny that it was the initial name, right? When we tested it internally, it's a very small website. 

CHARLES MAX_WOOD:Oh, I would have loved to fart some apps out there. 

MARC ANDRE_COURNOYER: Yeah. Running a fart cloud. That was the only reason why it was called this. But yeah, it was kind of, yeah, I think there's no way we're going to get into the enterprise if that's what it's called fart. So you change the name. Yeah. And the app... So initially, at that time, I think that's where I created... I had a semi-popular website, which was called refactormycode.com, where you would post refactorings and stuff. And I think that's where I started testing my server. And it did okay. It was much more stable and I would nail out the issues and stuff. But where it started picking up is when people from the Ruby community at the time...They noticed the project and they started using it in some much bigger stuff. There are a few people at Engine Yard, which used to be really big at the time. I think it still exists today, but... 

CHARLES MAX_WOOD:I think they're still out there. Yeah. 

MARC ANDRE_COURNOYER: There were some... The people there were awesome. They were really driving the Ruby open source community forward. And they just picked up and said, we're going to run our customers on it. And they helped figure out the issues. They would report bugs to me, help me figure it out tested, I was just blown away at the amount of work that it would do and that people would really believe in the project and that would drive me to work on it more and more and think about new and innovative features. That's what I would do. I would work on weekends and nights every night on this because it was so much fun. And so I think that's how it picked up. Initially, lots of people at Engine Yard, lots of people everywhere. And eventually...The people at Iroku, when they launched Iroku, I don't know how much of this is known today, but the initial version of Iroku, if you remember, it was just Ruby apps. And you had no choice what server to use. It was using Thin for absolutely all the apps. So if you ran your in like in the five or three first years of Iroku, if you ever used it for running your app, it would run on Thin. And that was a big driver, I think two people using it. And then...It became used, like I said, in the engine yard, VMware, all the big companies started using it. And that's how we picked up and it became a successful open source project. Kind of because of the people at engine yard. Mostly. 

CHARLES MAX_WOOD:Yeah, I remember when they had, I can't remember if it was RailsConf or RubyConf. I want to say it was RubyConf in San Francisco. They did kind of a startup tour. And so you'd get on the bus and you'd go to Dropbox, which was using Rails, and then you'd go to Engine Yard, New Relic. 

MARC ANDRE_COURNOYER: Oh, yeah. That's true. Yeah. Oh, what year was that? That's, I didn't know that. 

CHARLES MAX_WOOD:That was a long time ago. I think it was like 2008. 

MARC ANDRE_COURNOYER: Okay. It's around the same time. Cool. 

CHARLES MAX_WOOD:Yeah, but yeah, I mean, yeah, it was just an exciting time to be involved. I'm a little curious, so you go from, hey, I'm gonna try and bolt this stuff together to, hey, this stuff has to use rack in order to be able to use thin, to, okay, now we're getting adoption of both rack and thin. So how does that change the equation for you in maintaining thin? Like, you know, now you're not, it's not this mystery of how do I get this to work. Now it's a... 

MARC ANDRE_COURNOYER: Oh, okay. 

CHARLES MAX_WOOD:How do I maintain it from here? 

MARC ANDRE_COURNOYER: Well, I don't know. It has never been like a big burden. I don't know. I don't relate at all to the people saying like, to adding bad experience with community with open source community. And I would just see somebody like send the PR that it did not agree with that was just not merge it. And I don't know. Like it felt really fluid at the time when people would just use it. And it was clear to me like when there's a feature that was. You have to use it, right? You have to implement it. For example, like writing the body to a temp file because it was too large in memory and stuff like that. Of course, I have to do it. I would usually copy what other servers would do. That's what I would do. Like start the implementation there. But yeah, it was not really a burden, right? There was no people like it. That was the thing that surprised me too. Maybe because I made a big disclaimer to say, well, It still felt like beta software to me. And I said, all right, so if you want to use it in production, you can do it, but I'm not responsible and stuff. But I've never had any bad experience where people are complaining or faulting me for issues that would run on this. Sometimes there would be bugs and issues, I would fix them. But maybe that was why, because I was so into the project that if there was an issue that was reported, I was so driven that I would fix it the next day. So who's going to complain if it's fixed the next day? So I think maybe that's where sometimes frustration comes on with open source, right? People lose interest and it's natural. I've lost interest in things, so I'm not working on it anymore. Maybe that's where you start to see frustration, but there was none of this initially. It was just wonder and like, this is cool. Everybody was very joyous about the product. Yeah, it's your only good memories from that. 

CHARLES MAX_WOOD:So yeah, so I like that. I really like that. Because I know different people have had different experience with open source. I mean, I've talked to some people where the project got big and it kind of took over their life. I know people who they poured their heart and soul into it and then, you know, some bad actors in the community came in and complained about some things and just made it not worth it to them to continue. But it sounds like for you, it was just, you know, you worked on it until you were done working on it. 

MARC ANDRE_COURNOYER: Yeah, but But after some point, I realized I don't need that many people to use my software to be happy. So I stopped caring at some point that people would truly use it. I think I was very fortunate to get this success very early on, to get lots and lots of... to get it very, very popular. And then I said, it felt a bit like a checkbox to me. I said, okay, I did it. Now I don't care if you use them anymore. If it's not for you, you just don't use it. And I think the other advantage too is because of Rack. If you want to switch to Puma, it takes one line. You just switch. It's going to take you five minutes to switch. There's no lock. You're not locked into the server until you start using some of the built-in features. Maybe that played into it. I think that's the other key advantage of having nice APIs that you can swap to something else. People are not happy. Well, it takes five minutes literally to switch to something else. You can try it. Maybe that played into it too. 

CHARLES MAX_WOOD:Yeah, makes sense. 

MARC ANDRE_COURNOYER: But it was about, like for me, it was all about like, pushing the boundaries of the server, like implementing like cool new features that had not been done before. But at some point that breach, like I think I explored all that I could explore in a Ruby server and I eventually got bored of it, right? To say, I said, well, I think the project is done for me. And I fixed a little bit our merge and other people started contributing other features like along the lines of async programming and stuff like that. But for me, it was kind of done and I moved to other stuff afterwards. 

CHARLES MAX_WOOD:Right. So yeah, I was going to ask, so when you say that you're not maintaining thin anymore, was that like an active decision or did you just kind of run out of things you wanted to do with it? 

MARC ANDRE_COURNOYER: Yeah, exactly. I ran out of things and it was nothing major happened, no major issue. So yeah, I mean, it's been very stable. It's done software. It's done software. So it's not, you can still use it. It still works, but it's done. So not gonna add to it, not gonna remove it too. So unless, I mean, if there's an issue, I find something else happens, maybe that changes in Ruby that makes it unsafe or something like that. Of course, you're gonna like you're getting the gem and stuff like that, but that has not happened. 

CHARLES MAX_WOOD:That makes sense. So what are you working on now then? 

MARC ANDRE_COURNOYER: Right now, I work on Shopify, I work on Storefront, which is the website that we give to people. I worked a lot on the improvement. So when I finished, then the other thing that I really fell into that I drove a lot of my passion projects were programming languages, compilers, and stuff like that. So ever since that time, that may be like 12 years ago, I've always been like, say, wanted to...focus and explore various types of projects around compilers. And when I joined Shopify about three years ago, I had this idea, which is probably like a bad tactic if you're interviewing for a company, but I was pitching my idea when I was interviewing at Shopify. But I wanted to compile liquid. Do you know liquid? Is there a template language? It was very popular in Ruby because it was a... 

CHARLES MAX_WOOD:It came out of Jekyll? Is that where it was? No, that's the inverse. Yeah, Jekyll used liquid. Oh, Jekyll. Yeah, it was Shopify that pioneered it. 

MARC ANDRE_COURNOYER: Yeah, Shopify created liquid. 

CHARLES MAX_WOOD:Right. 

MARC ANDRE_COURNOYER: It's because at the time, like, there was no template. You could not use ERB, right? Because we have the people, the merchants, if you're a user of Shopify, you have to write you're writing yourself as a user of the platform, you're writing a template. So it has to be safe. So you cannot like ERB is based on... 

CHARLES MAX_WOOD:You can't let them insert Ruby because that's not safe. 

MARC ANDRE_COURNOYER: Exactly. You call it's based on eval. So if you allow anybody to execute Ruby code, they just make the biggest security error. 

CHARLES MAX_WOOD:Yeah. 

MARC ANDRE_COURNOYER: So that was mandatory that we did. They came up with like a safe template language. It was created by the founder, like Tobias Lutte, who created like a liquid at the time. But I looked at it, it's open source. You can look at it right now. But when I looked at it, I said, well, that's a walking tree interpreter. It's not the best way to do it, right? It's just, if you know about those, it's like it just parses. There's always like in a compiler, there's usually two or more phases where first you parse the program into an AST, that's like a tree representation, and then you can parse it to other formats, and then there usually, there's an interpreter or another compiler, and like Liquid works with, you just parse it to an AST, and then you walk the AST down to execute the program, right? That's the most, that's how actually Ruby 1.08 or 1.9 used to work. It was a walking tree interpreter. We just parsed the ASD and walked down to it. 

CHARLES MAX_WOOD:That sounds like a simple enough thing to write. 

MARC ANDRE_COURNOYER: It is the most simplest thing. It's a very good starting point. It's just that it's not the most efficient way to do it. If you think about any language that we have today, like anyone, like Java or PHP, some of them, I'm not going to say all, but some of them started this way, like Ruby exactly, but eventually they evolve out of it because it's not efficient. Having a tree structure, you can imagine you jump in memory from there. It's all consumed lots of memory, but it's not efficient to jump from one address to the other one. So the most efficient way or the next step afterwards is you compile to a custom bytecode where it's very linear in memory. So it's easy for the compiler to know where to go next. 

CHARLES MAX_WOOD:Okay. 

MARC ANDRE_COURNOYER: And it's much more compressed in memory. So less memory and faster. So it's kind of a no-brainer decision. But then that means that you have to build an interpreter that interprets the bytecode. You're kind of called a virtual machine because you're kind of mimicking what the what the the machine the CPU on your machine is doing. 

CHARLES MAX_WOOD:Right. 

MARC ANDRE_COURNOYER: So my idea was to do exactly that for liquid, which was not a very, not a very common thing, I think, to, I don't know of any other template language that do this, right? So normally it's all language do that programming language, but liquid is not a program, which is a template language. But I still believe like that's the way to do it is to compile like to an intermediate format bytecode. So I entered into Shopify with the goal of doing that or with the idea, pitching the idea. And eventually we turned that into a real project, which is now being shipped live. And we're going to talk more about this as we go. But now all the templates, if you're rendering a website, is being compiled to an intermediate format and being evaluated. 

CHARLES MAX_WOOD:Oh, nice. 

MARC ANDRE_COURNOYER: It's much more performant, but also that I think that leads to a better design too, because...Things are a bit like wrap. We're going back to middleware. This is now you have a pipeline of stuff that you compile. So it's easier to do other steps and do optimization, inspect the intermittent representation. Because you kind of have to say, well, I'm going to execute on this other format that is much more optimized. But before that, you can do other steps to optimize it further. And that's why all language do it. 

CHARLES MAX_WOOD:That's cool. 

MARC ANDRE_COURNOYER: So that's one of the things I'm working on also exploring ways around as possible and working on a new server for Ruby and also working with the with Rost around that. We're using Rost a lot at Shopify and Rost in combination with Ruby, if you've never done that, it's really cool. It's getting easier and easier. Yeah, you should like if people like you're listening to this, like you definitely give a look to Magnus, which is a Rost crate that makes it extremely easy to build like a not the extension, but native extension in Ruby. Like expose an API from Rust to Ruby. So it became very, now if I rewind back like 10 years or 15 years ago, if you wanted to build like a Ruby Jam with native extension, that was like, it was very hard. The API was unclear, the docs, there was no official doc. You were kind of on your own, or how I did it, is I looked at the code of Ruby itself to see how we did it and tried to sometimes backtrack to say, oh, could I do this outside of Ruby? It was so hard. But now like it seems like we're in a really good spot. If you look at Magnus's extremely so it's so it's beautiful when you write something like in, in Russ and it compiles to a native extension in Ruby. So I think it's kind of, you get a best of both worlds, like from Russ and Ruby, where you get the, the, the safety of Russ and the some, maybe the performance of it too, and then you get the nice API of Ruby on the other side. 

CHARLES MAX_WOOD:Nice. I'll have to look at that. Maybe we'll do an episode on it. 

MARC ANDRE_COURNOYER: Yeah, that's very, I think that's the, to me, if you ask me, what are the exciting stuff happening on Ruby these days? I think one key one, right, is the, the, the using Russ more, like on the side to build a native extensions, uh, is definitely one of them. And it may be in combination. I'm hoping that, uh, in combination with Ractors. And if you've looked at the time to look at Ractors a little bit, but there are 

CHARLES MAX_WOOD:a little bit, not a lot. 

MARC ANDRE_COURNOYER: And many threads too that came up. I think many threads was enabled in 3.3. The directories, I think they were introduced. I don't want to say anything wrong, but I think what are introduced in 3.0, I think. So if you never heard about those, like a Rector is kind of the first time in Ruby that you can create, you run something in a thread that is not bound that usually, right? That's the kind of the, the asterisk is usually is not bound by the JBL, the global VM block. It's not always true because things are there. There are some issues around that. There are some bugs, of course. But that's the idea that you could run some really two treads in Ruby that are not bound by this luck. That is a problem that we're facing today with concurrency and parallelism in Ruby. 

CHARLES MAX_WOOD:That's been an issue that we've been talking about for years and years and years. 

MARC ANDRE_COURNOYER: For years and years. And that's the thing, right? Because I think the issue that we have is because lots of the code, especially native extension, like in Ruby gems, we've built those in mind that, oh, doesn't need to be thread safe, right? Because Ruby has the JVM log. So lots of those gems with native extensions has been built with this idea that it does not need to be thread safe. So I don't see how we could make that work except if you built your native gems with Rust. Because Rust ensures that when you compile the code, that your code is thread safe. If you know a little bit about Rust, like the send and sync markers, that you get the compiler will tell you as soon as you compile it, it's thread safe. So then you can build native extensions in Ruby that are guaranteed that compile time to be thread safe. So technically, this should be easy to be used across Rectors and stuff like that. So I don't think we're there yet, but I can see a very bright future for concurrency, parallelism, concurrency, and all that stuff coming up in Ruby with Rectors and the many treads. Many treads is kind of this idea to go back to green treads. Because now, if you create a thread in Ruby, it's going to create a native thread, but it's still bounded by the GVL. But with this idea of many thread that you can enable now with Ruby 3.3 is you could flip the switch and all the threads that you create with thread new, it would be green threads. So they're not attached to a native thread. Right. And then the scheduler of Ruby takes care of doing the context switching. So it's much faster and it's also cheaper to create threads. So technically, they should, if we enable this technically, it should be as cheap to create a fiber as it is to create a tread. 

CHARLES MAX_WOOD:Makes sense. 

MARC ANDRE_COURNOYER: So, but this is just starting up, right? This is the stuff that's happening right now. So I don't know how ready it is for production stuff, but at this, that's the stuff that excites me and still that kind of re-spark my excitement and stuff happening in Ruby, I would say. 

CHARLES MAX_WOOD:Cool. So are you building the liquid VM, uh, project in Rust then, or are you doing it in Ruby or? 

MARC ANDRE_COURNOYER: Yes, this project is a big project that we have that is built in Rust. We have some other parts too, like in Shopify, like an all-around Shopify that are built. But I think that was one of the biggest projects that is built in Rust and also using WebAssembly. So we're compiling Liquid to WebAssembly itself. And we have other parts. So if you know a little bit about Shopify, the platform, we have some extension points, like we call it Shopify functions. You can just think of it like a callback. There was a refund or something, you trigger a callback. Well, this callback, any merchant can hook into it. And the way you hook into it is you compile to WebAssembly and upload the function to Shopify. So this other part also is coded in Rust at Shopify. So we got those two areas that are very similar, like conceptually, compiling liquid and compiling functions that are built in Rust and WebAssembly. So very, very cool stuff that's happening. I think so there are really, really cool technology. Can we use? 

CHARLES MAX_WOOD:Wow. Well, I'll have to dive into that. Cause yeah, I've got some stuff that I'm working on and, and yeah, some of it may, may be able to use some of that stuff to get some of those features, the thread safety and the speed and the efficiency memory, all that good stuff. 

MARC ANDRE_COURNOYER: So. Yeah, yeah, I think I would encourage everybody to try Ractors because I think Ractors now, there was a call to, I think it was a Ruby, KaiGee. I just saw it online. I was not there. But somebody at works sent me the link to the video. And then I think the problem they're running into is that nobody's using Ractors. Because nobody's using Ractors, they don't get better. And because they don't get, nobody's using them because they're getting better. So we're inside, we're in this cycle. 

CHARLES MAX_WOOD:And then people complain that we don't have better concurrency functionality. 

MARC ANDRE_COURNOYER: Exactly. So we're at the point where we can make this happen, but it's kind of a, I don't know, I don't know if I don't want to, I'm not going to be the one to drive the community forward to this, but that's kind of this, that's something I think that needs to be driven forward to people. Maybe like it would be just starting a new server or try to use it for something else. It's not clear to me, like if Rectors are just like for you. I think there are two approaches. Maybe you could run your full app into a Ractor. That could be your web app. Or you could just use it like some sort of background job system or something like that. Just some parts. So you say, oh, because the problem with Ractors, you cannot pass any objects you want. You can only pass frozen objects that are Ractor safe. So if you pass a string, for example, you need to freeze it first. You cannot modify it afterwards. You can still. You can freeze it, pass it to Rector, and then copy it and then modify it, but you cannot have the shared reference. You cannot do that because you have a shared pointer, shared memory reference, and then race conditions. So it's very hard, much harder. It's much closer to languages like Rust force you to think about it. It's just that in Ruby, it's kind of...It's the first time that we have to think of this way. But I think if you're coming from Rust, you know about those paradigms of send and sync and the compiler, you're like making your job really hard to make forcing you to think about making your code thread-safe. I think that's a really good step towards like taking in a world of where we could make Ractors work fully. 

CHARLES MAX_WOOD:Cool. Well, maybe I'll go play with them. 

MARC ANDRE_COURNOYER: Maybe yeah. It does. It does feel like me. I'm very excited about this because it does feel like again, like I said, It comes back to when I started thin like 16 years ago, right? Where there are key technologies around, right? Yeah, we have rack, we had like regular parser that we talked about, like, and we have even machine. And I do feel like we're seeing something again, like this happening where, right? We have like there's rust that allows to build thread safe native extension. We have recorders coming up. We have the many trends coming to give us green threads. It's just that nobody's doing like the connective work like the glue right between them and driving those stuff forward. I mentioned Samuel Lewis before. He did lots of work to push forward the usage of fibers. That's mainly because of him now that we have the fiber scheduler and lots of cool stuff. That is a cool thing, but I think something else needs to happen on the Ractor side. Because there's just one people working now in the Ruby Core team on those two things. I don't want to say it wrong, but Koichi working on both tractors and the mini-tress, right? It's just one person working on all this. So we do like at Shopify, I have a big team working on helping like driving a Ruby 4. But I mean, we also need like other people with use cases to use those technologies to drive for. 

CHARLES MAX_WOOD:Yeah, makes sense. 

MARC ANDRE_COURNOYER: Yeah. So I think we're in a very exciting time or I'm really hopeful for stuff to come. So yeah, and I'm hoping to drive forward with upcoming projects. But I'm hoping that people like watching this get excited about reactors. I can like native extension all of this. I think to be in my way, it's pretty clear It's all linked together, but if you don't see you should definitely try those technologies. I hope you get it and that sparks some interest into Cool projects. 

CHARLES MAX_WOOD:Yep. Awesome. Now. I know that you've written about some of this stuff on your blog like it here son article on rust and some of this other stuff. If people want to see what you're working on or connect with you, is there a good place for them to find you? 

MARC ANDRE_COURNOYER: Well, I feel very old now. I'm just going to say, write me an email. Yeah, I'm not very active online. You mentioned my blog. I don't think I've looked at it for 10 years or something like that. 

CHARLES MAX_WOOD:Oh, okay. 

MARC ANDRE_COURNOYER: Yeah. I'm very happy to help anybody or to just see if you have questions about this stuff, but just write me an email. Yeah. It's ma@gmail.com. 

CHARLES MAX_WOOD:Awesome. All right, well, I'm gonna kind of roll us into picks and start wrapping us up. So yeah, I'll go ahead and jump in with my picks first. So I tend to pick board games as a pick every time. Lately, a game that my wife and I have been playing a whole bunch now at my house, it's Disney and Harry Potter. That's what we're into, that kind of a fun thing and there's a game called Death Eaters Rising and effectively you it's a dice game you roll the dice and then you try and match them up with cards to earn the cards or you know fight the villains or whatever right and then eventually Voldemort comes out and you have to fight him too and anyway it's it's pretty fun. About half the time I'm playing with the family and the other half of the time is just my wife and I. So okay. And yeah, let me look up on board game geek so I can tell you all how hard it is to play. It's not terribly hard to play. Yeah, it's a board game weight of 2.37. And I tell people that kind of the casual game with a little bit of complexity is about a two. So anyway, this is something that people can definitely pick up. Usually takes us about an hour, maybe a little longer to beat it. You can play two to four players. Um, what I found is once you get to the fourth player, so you're starting, uh, wizards, um, that, so you pick a team. So it's Dumbledore's army or, uh, Hogwarts or what's the other order of the Phoenix and each of them have two starting cards, but the starting card abilities for, uh, one of each of those teams is if you have another, uh, wizard from that team, you get an extra die to roll and then, um, The other card is if you have a specific one of the other things, then you get an extra die to roll. But you get an extra die in the color or suit or whatever you want to call it, team that you're on. And so it's a lot easier to get wizards that are on the same team as your team, at least initially. And so once you get that fourth player in then that fourth person is a little bit disadvantaged because they're playing with a wizard who gets their bonus off of a another wizard that isn't as easy for them to acquire. Um, so three, three is a little bit better than four and then playing a little bit. No, you just roll the dice. You choose, you move. Um, you, you know, Voldemort, you know, attacks a specific area, right? does that thing there. Um, and then you roll the dice and you can either acquire wizards or recruit wizards or you can, um, attack death eaters. And you have to have five death eaters before you can completely do all five damage to Voldemort. And you lose if you lose, because the, the wizards all take damage, um, for different things. And so if, if you lose eight wizards, you lose, um, if you lose, um, One location entirely you lose or if you lose four location cards you also lose um so Yeah, anyway, it's it's fun. It's it's just hard enough to be Interesting, but it's not so hard that it's impossible to win. And I think we win more often than we lose. But Anyway, it's a lot of fun. It's cooperative game um so i'm going to pick that i'll put links, um in the YouTube and Facebook comments to the game. And then yeah, also get Amazon affiliate. If you click the Amazon link, it doesn't cost you anymore. But I do get a little bit of money for that. And then I'm going to just pick up a couple of other things. So earlier this year, my wife and I went and saw a movie called The Shift. And anyway, it was awesome. It's basically the devil trying to win over this particular guy. But it's like sci-fi and stuff. So anyway, it was a really interesting twist. I don't want to give away the story. But anyway, yeah. Awesome stuff. So definitely go see the shift if you get a chance. I'll put a link to that in the show notes as well. And then there was something else I was going to pick. Oh, I was going to shout out about the Ruby Dev Summit. So I've interviewed, I think by the time I'm done, I'm going to have interviewed 22 or 23 people and I've got core team members from Ruby. I've got people who do rails. I've got other podcasters. I've got people who work on my, uh, Ruby's infrastructure and ecosystem. So definitely go check it out. You can go find it at rubydevsummit.com. You can enter your email address for free and then it'll email you when the talks are coming out If you want early access you can sign up for a subscription on top end devs and that'll give you early access But you don't have to do that. So You know that that's up to you. Those talks will be coming out if you want to watch them during the window. They're available the second week in February, so Anyway, that's that's all the stuff. I've got mark. What picks do you have? 

MARC ANDRE_COURNOYER: Picks? Well, I can pick like three of my favorite Shopify merchants. There are three, like two that I consume a lot. Like there's one for my coffee shop. It's the little delivery coffee. It's maybe it's a bit too local, but it's a Cafe Barista. It's in Montreal. If you're CafeBarista.ca, if you're there, it's really good. They have lots of equipment and machine. It's really amazing. And my second store, which is where I spend a bit too much money, is called Moog Audio. If you're into music or musical instruments, this is amazing. There's an instrument that was released by a teenage engineer a few weeks ago, I think it's called K.O.2. It's like a sampler if you're into those things. It looks like a calculator. The design is beautiful. It's a sampler, it's very thin, and the design of it It's amazing. It's just nice to look at. I think it's the first time they release something that is not too expensive. Usually, they release projects that are thousands of dollars. This one I think is a lot cheaper. It's kind of their cheapest sampler. So if you want to sort of a gateway drug into that, look at it on movewithyou.com. And finally is where I drink lots of coffee, but I also drink lots of tea. And I order it online from Firebelly Tea, which was started by the...It was co-founded by the president of Shopify. Oh cool. Arleigh. And it's a really good tea. It's also founded by the other guy like David Stee in Canada. I don't know if he got to the US, but it was very popular in Canada and Quebec. And the tea is really good. So firebellyt.ca. Those are the three Shopify merchants. 

CHARLES MAX_WOOD:Nice. If you want to type those into the chat, then I will make sure that they end up in the...Yeah. And then, yeah, beyond that, I am getting videos out now for Rails clips and Ruby bits. And so the Ruby bits, I'm starting to write the V game in Dragon Ruby, which is something that I've always wanted to do. So I'm excited about that. And my kids all think that's cool too. Dad's writing the video game. I'm trying to keep it simple, but I'm also trying to keep it kind of fun and funny. Anyway, we'll see how far we get on that and what challenges I run into. On the Rails clips, I am building out Rails Composer, railscomposer.com. And effectively the idea is that I want Rails, which David has said he wants it to be a single-developer framework, right? So single developer can make considerable progress on an app. So the plan is, I want Rails to be a single developer experience like DHH has said, but I want it to be a single developer experience if you're building SaaS. And so Rails Composer is going to be the pieces that you would compose to build a SaaS. Right. So you build out, let's say you're building something for podcasters, you build the piece that's the for podcasters piece. And then you can pull in the rest of the pieces, which are user management, permissions management and payment and payment management and your sales dashboard and those kinds of things that you need to run your SaaS, but you shouldn't have to actually write. Right? I want you to be able to put each piece in, in less than an hour. So your first day is essentially, I've got everything together except for what I'm selling, if that makes sense. Right? And also marketing pieces. So I'm also looking at like SEO and blog, a blog engine and things like that, that just plug into your layout neatly. So anyway, but I'm building the...I'm actually building out railscomposer.com first as a Ruby clips series. So anyway, go check that out. And yeah, this was fun. It was good to catch up, Mark. 

MARC ANDRE_COURNOYER: Hey, likewise. Thanks a lot for any invite.