WEBVTT 1 00:00:05.559 --> 00:00:10.320 Hey, welcome back to another episode of the Ruby Rogues podcast. This week, 2 00:00:10.320 --> 00:00:15.000 on our panel we have Valentino Stole, you know, Charles Maxwells from 3 00:00:15.039 --> 00:00:19.280 top ed Dev's. We've got a special guest and that is Samuel Williams. 4 00:00:19.679 --> 00:00:22.160 Samuel, do you want to introduce yourself? Let people know who you are 5 00:00:22.239 --> 00:00:26.800 and why we all love you? Thank you? Yeah, my name is 6 00:00:26.839 --> 00:00:31.719 Samuel. I live in New Zealand and my kid's right here with me in 7 00:00:31.760 --> 00:00:37.439 the morning morning routine, and and I'm having a coffee, which is awesome. 8 00:00:37.960 --> 00:00:43.640 What time is it in New Zealand. Yes, am a little past 9 00:00:43.640 --> 00:00:48.679 eight am. Actually, anyway, I was imagining it was like four am 10 00:00:48.799 --> 00:00:53.079 or something. So I don't feel healthy anymore. I have had meetings at 11 00:00:53.359 --> 00:00:56.600 four am. I'm sure miss schedule a meeting and I'm like, okay, 12 00:00:58.679 --> 00:01:02.000 yeah, I'm on mountain time and it's it's just past noon here, so 13 00:01:02.079 --> 00:01:06.719 I was like, oh, okay, okay. Yeah. So my back 14 00:01:06.799 --> 00:01:11.519 in background is in software engineering. I did a bit of computer vision growing 15 00:01:11.599 --> 00:01:18.040 up in the university. I did an m C and outdoor augmented reality. 16 00:01:18.840 --> 00:01:25.560 And I've always been patient about solving problems. I've never really been satisfied with 17 00:01:25.799 --> 00:01:30.400 just the status quo or this is good enough, and maybe that's informed the 18 00:01:30.400 --> 00:01:34.879 way that I've looked looked at the software that we have today and thought about 19 00:01:34.920 --> 00:01:38.680 maybe but what we could do better? Right? Hey, folks, this 20 00:01:38.799 --> 00:01:42.680 is Charles Maxwell. I've been talking to a bunch of people that want to 21 00:01:42.200 --> 00:01:47.400 update their resume and find a better job, and I figure, well, 22 00:01:47.400 --> 00:01:49.319 why not just share my resume? So you if you go to top endevs 23 00:01:49.359 --> 00:01:55.200 dot com slash resume, enter your name and email address, then you'll get 24 00:01:55.239 --> 00:01:59.680 a copy of the resume that I use that I've used through freelancing, through 25 00:01:59.840 --> 00:02:02.319 my most of my career, as I've kind of refined it and tweaked it 26 00:02:02.359 --> 00:02:06.799 to get me the jobs that I want. Like I said, top endevs 27 00:02:06.799 --> 00:02:09.360 dot com slash resume, we'll get you that and you can just kind of 28 00:02:09.439 --> 00:02:14.360 use the formatting. It comes in word and pages formats and you can just 29 00:02:14.560 --> 00:02:19.000 fill it in from there. Cool. Yeah, And I interviewed you for 30 00:02:19.080 --> 00:02:22.840 the Ruby Dev Summit. People can go check that out Rubydevsummit dot com. 31 00:02:23.120 --> 00:02:25.240 But yeah, we talked about a SINC and Falcon and I thought, you 32 00:02:25.280 --> 00:02:29.680 know this, there's some great stuff here that we should just talk about on 33 00:02:29.759 --> 00:02:34.680 Ruby rogues and then you know, we kind of got into future Ruby and 34 00:02:34.759 --> 00:02:38.159 some of the things involved there as part of the summit. So so yeah, 35 00:02:38.199 --> 00:02:40.319 do you want to just kind of give us the ten thousand foot view 36 00:02:40.439 --> 00:02:45.879 on ACNC and then maybe we can get into what falcon does in a minute. 37 00:02:46.639 --> 00:02:53.159 So acink is an interface which gives a vent drivenking currency to Ruby, 38 00:02:53.240 --> 00:03:01.919 provides vendronking currency and as to ays being designed as to give give engineers like 39 00:03:01.960 --> 00:03:08.039 the best possible experience with concurrency, and so in that regard that that sort 40 00:03:08.080 --> 00:03:10.919 of mental model and form like a lot of the choices and the design choices. 41 00:03:10.960 --> 00:03:17.439 So acinc provides task based concurrency. It doesn't require any special keywords for 42 00:03:19.680 --> 00:03:23.360 asynchronous behavior, like saying jobs would be require a single weight, and it 43 00:03:23.439 --> 00:03:30.240 tries to be as efficient as possible, but it also sometimes chooses develop a 44 00:03:30.319 --> 00:03:37.319 happiness over efficiency to make it easier because asynchronous programming can be pretty tricky and 45 00:03:37.560 --> 00:03:44.080 giving people like good logging, good feedback when things go wrong is really important 46 00:03:44.120 --> 00:03:47.919 actually, and I don't think we've solved all of those problems, but we're 47 00:03:47.960 --> 00:03:51.800 definitely like that. That's the mental model of a sing So ACNC provides this 48 00:03:51.879 --> 00:03:54.360 as ventrin concurrency, and on top of that you can build other things. 49 00:03:55.400 --> 00:04:00.280 And when the first proof of concept that are you know, major for a 50 00:04:00.319 --> 00:04:04.080 concept that I was really fascinated and was building web server because because why not? 51 00:04:04.400 --> 00:04:10.159 And is this that's what this is where Falcon came from. Okay, 52 00:04:10.280 --> 00:04:14.199 Falcon basically evolved from let's try that, try it and see what we can 53 00:04:14.240 --> 00:04:16.120 do with a and what the performance is like, and then we can actually 54 00:04:16.160 --> 00:04:23.000 measure things and do some interesting real world comparisons. So I have a question 55 00:04:23.160 --> 00:04:27.839 here that I'm kind of thinking about. And I mean some of this you 56 00:04:28.120 --> 00:04:32.040 said event driven, and that just made my mind think about well one arguments 57 00:04:32.079 --> 00:04:40.279 that I've had with people over no js but also right because there are ruby 58 00:04:40.560 --> 00:04:45.199 anyway. But the other the other question I have is way back in the 59 00:04:45.279 --> 00:04:48.120 day, we had event machine, and a couple of weeks ago we interviewed 60 00:04:48.319 --> 00:04:54.560 or I interviewed Marc Andre Cornerier who built Thin and know a lot of that 61 00:04:54.639 --> 00:04:58.839 was kind of built on some of the stuff with event machine. So what 62 00:04:58.839 --> 00:05:02.519 what's different between say acinc and event machine and then maybe thin and Falcon. 63 00:05:03.160 --> 00:05:08.839 Yeah, that's actually a great question, as in the side actually maintained thin 64 00:05:09.279 --> 00:05:14.720 slightly. Thin was sort of languishing a bit, and I got involved in 65 00:05:14.759 --> 00:05:16.000 maintaining it, and I learned quite a lot about it as well. So 66 00:05:16.040 --> 00:05:19.480 I really like I like exploring the ecosystem and seeing the different, different, 67 00:05:19.639 --> 00:05:26.240 different, different kinds of implementation. So to your point, event machine versus 68 00:05:26.360 --> 00:05:30.279 a SYNC or the modern version of acing, actually is a gym behind it 69 00:05:30.279 --> 00:05:33.879 called io event and that's the actual event loop, the thing that provides the 70 00:05:33.920 --> 00:05:39.639 event loop. But surprisingly, or maybe surprisingly Ruby she is quite a rich 71 00:05:39.759 --> 00:05:44.959 history of event driven architectures. It's not just event machine, and like a 72 00:05:45.120 --> 00:05:51.879 SYNC, there's also celluloid em synchrony. Never block is one that many people 73 00:05:51.959 --> 00:05:56.519 haven't heard of. It was an interesting experiment kind of similarly so long. 74 00:05:57.199 --> 00:06:00.959 Yeah, and there's a handful of the ones. If I go digging in 75 00:06:00.000 --> 00:06:02.519 my notes, i'll be able to pull them out. But you know, 76 00:06:02.839 --> 00:06:10.079 I suppose my point is there have been like a lot of keen minds in 77 00:06:10.120 --> 00:06:15.160 the Ruby community experimenting with this, and it's interesting to compare the different approaches. 78 00:06:15.879 --> 00:06:18.519 But I wanted to call out that there is a year rich history there 79 00:06:18.560 --> 00:06:23.759 of people experimenting and trying to build things and looking at the different approaches, 80 00:06:24.480 --> 00:06:30.279 so specifically with like say event machine and ACIN. I think one of the 81 00:06:30.319 --> 00:06:40.240 challenges with the event machine is that you're event machine is written from the ground 82 00:06:40.319 --> 00:06:47.240 up without really thinking about compatibility with existing Ruby interfaces. I think that would 83 00:06:47.240 --> 00:06:50.519 be the biggest criticism I could make the event machine. So when you build 84 00:06:51.040 --> 00:06:57.120 an application that uses event machine, you can't use normal Ruby io. You 85 00:06:57.160 --> 00:07:00.879 have to use event machines custom rappers classes to deal with the vent driven IO. 86 00:07:00.959 --> 00:07:03.720 And i'd like I think for TCP you get a class instance which has 87 00:07:03.839 --> 00:07:09.040 methods that get called back when data is available, and I think for UDIPS 88 00:07:09.120 --> 00:07:16.000 that's similarly a little different. And for things like sleep or timers, all 89 00:07:16.000 --> 00:07:23.199 of these things that all event machines specific APIs. So I suppose to compare 90 00:07:23.240 --> 00:07:27.040 that with a sync well with acinc one point one point x, because we 91 00:07:27.040 --> 00:07:29.959 were kind of in the same boat. We made rappers for everything. So 92 00:07:29.959 --> 00:07:33.399 there's acnc io, which is rappers for Ruby's native io. Acinc itself provides 93 00:07:33.480 --> 00:07:39.319 rappers for things like sleeping, but there's other things which aren't rapped, like 94 00:07:39.480 --> 00:07:44.600 DNS resolution and ACINC one point x process waiting on processes. There's all these 95 00:07:44.639 --> 00:07:46.920 like different things that can cause an application to block and that we want to 96 00:07:47.000 --> 00:07:54.600 kind of lift into the event Look, so when I built ACNC one one 97 00:07:55.040 --> 00:07:57.800 one point x, I went to mats and that was the prototype. It's 98 00:07:57.800 --> 00:08:00.319 like, look, Matt's this, this works. People have done this before. 99 00:08:01.319 --> 00:08:05.279 To take it to the next level, what we need is actually hooks 100 00:08:05.439 --> 00:08:09.360 inside the Ruby virtual machine so that when Ruby itself tries to do a blocking 101 00:08:09.399 --> 00:08:13.800 operation, we can hoist that into the event loop. And it has to 102 00:08:13.800 --> 00:08:16.519 happen at the core of Ruby. It can't be a rapper that sits on 103 00:08:16.560 --> 00:08:18.680 the outside, because the problem with a rapper is it as soon as you 104 00:08:18.759 --> 00:08:26.879 start using an existing application or existing code that uses native Ruby io that doesn't 105 00:08:26.959 --> 00:08:28.120 use the rappers, and so it will block, and so you can't. 106 00:08:28.360 --> 00:08:33.080 It's sort of a compatibility thing. So event machine sort of suffers from that 107 00:08:33.200 --> 00:08:39.000 compatibility, I think. And so while event machine itself is generally quite okay 108 00:08:39.759 --> 00:08:46.480 and was I would like to make an assertion that I think most event loops 109 00:08:46.519 --> 00:08:50.159 are roughly the same performance as every other event loop. I don't unless you 110 00:08:54.080 --> 00:08:58.679 massively mess up the implementation. Event loops are largely on the same level of 111 00:08:58.720 --> 00:09:01.840 perform moments. There's very few things you can sort of do to bet something 112 00:09:01.840 --> 00:09:07.320 black ten dimes faster an event loop. It's all going through the same operating 113 00:09:07.360 --> 00:09:11.360 system interface is roughly speaking, and there's a few choices you get to make 114 00:09:11.399 --> 00:09:16.960 and how you organize the user facing parts. So but but there was one 115 00:09:16.960 --> 00:09:18.960 other issue that I had with event event Machine when I actually tried to use 116 00:09:18.960 --> 00:09:22.200 it, was that it would crash a lot, and it didn't support IPv 117 00:09:22.320 --> 00:09:26.120 SIS or IPv six would cause it to crash or like something in the pack. 118 00:09:26.559 --> 00:09:31.279 And I think one of the one of the problems with a lot of 119 00:09:31.279 --> 00:09:37.159 the existing like never Block and Celluloid and event Machine and whatnot was that maintainers 120 00:09:39.399 --> 00:09:41.960 tried to bite off too much of the like the problem in one go, 121 00:09:43.279 --> 00:09:50.919 and I think that made it hard to maintain or even really specify the nature 122 00:09:50.960 --> 00:09:52.720 of what these the problem these livers were trying to solve. And the problem 123 00:09:52.759 --> 00:09:56.600 that that got to burg and event Machine was trying to reinvent every units interface 124 00:09:56.679 --> 00:09:58.919 under the sun, because it was trying to make them all non blocking, 125 00:10:00.440 --> 00:10:01.840 right, and it's just really hard for one person to do that. So 126 00:10:03.200 --> 00:10:07.919 another point of comparison is with ASYNC, especially ACINC one point, I was 127 00:10:09.000 --> 00:10:13.440 really really specific on what I wanted to achieve and what I wanted the interface 128 00:10:13.480 --> 00:10:16.360 to look like. And I got from ACNC prototype to ACINK one release in 129 00:10:16.399 --> 00:10:20.399 like three months, and I was like, this is one of the most 130 00:10:20.399 --> 00:10:22.799 important things for users is they have a solid foundation that you say, hey, 131 00:10:22.799 --> 00:10:26.600 this is this is this is what it's going to look like for the 132 00:10:26.600 --> 00:10:28.120 rest of eternity. You can build on top of this without coming back in 133 00:10:28.159 --> 00:10:33.399 six months and having everything changed or you know, not working or so complicated 134 00:10:33.440 --> 00:10:35.240 that we don't know how it's supposed to work, or there's a lot of 135 00:10:35.240 --> 00:10:37.679 criticisms I could I could shout, I suppose, and that you know, 136 00:10:39.679 --> 00:10:43.279 it's it's not so much that that software engineers working on these problems were like 137 00:10:43.320 --> 00:10:46.559 better or anything. It's just more like the problem can be extremely complex if 138 00:10:46.600 --> 00:10:52.600 you don't compartmentalize, I suppose. So the second part of your question was 139 00:10:52.639 --> 00:10:56.120 how does Thin and Falcon differ? And so I think when you look at 140 00:10:56.159 --> 00:11:01.679 a server like thin that's event driven thin, I guess in some ways you 141 00:11:01.679 --> 00:11:11.080 could say Thin was pioneering because it it introduced in the roomy world when you 142 00:11:11.120 --> 00:11:16.320 have a web server. We had like an intermediate lyric called RACK. Yeah, 143 00:11:16.440 --> 00:11:18.679 it's a gem which provides the bridge between a web server and a web 144 00:11:18.720 --> 00:11:24.480 application, and it provides a common interface based on the CGI specification or yeah, 145 00:11:24.960 --> 00:11:28.360 some some sort of like hybridized vision of the CGI mashed up with a 146 00:11:28.399 --> 00:11:33.360 bunch of modern stuff. Yeah. Mark Andre and I talked a bunch about 147 00:11:33.399 --> 00:11:39.399 that in the interview we did with him. So fantastic and so thin kind 148 00:11:39.399 --> 00:11:46.759 of pioneered what concurrency for a web like, what the interface for a concurrency 149 00:11:46.840 --> 00:11:50.960 might look like to a web application. And I think this was something which 150 00:11:54.200 --> 00:11:58.240 it feeds into the It feeds into the whole RACK three upgrade that we did 151 00:11:58.279 --> 00:12:03.919 over the past like three or four years. So the CGI model that we 152 00:12:05.000 --> 00:12:07.120 use for a long time was just request response. Here's a request that comes 153 00:12:07.120 --> 00:12:11.440 in, has some here, there's a payload, whatever, and then we're 154 00:12:11.480 --> 00:12:13.720 going to make a response and send that bag out of the wire. And 155 00:12:13.759 --> 00:12:18.679 that doesn't really work for things like web socuits or if you have three hundred 156 00:12:18.679 --> 00:12:20.879 gigabytes of CSP you want to stream down the wire, because you can't really 157 00:12:22.039 --> 00:12:30.960 reasonably buffer three hundred gigabytes of CSP and so reg RECK two did not provide 158 00:12:30.960 --> 00:12:35.000 any mechanism really for the kind of concurrency that Thin was trying to implement. 159 00:12:35.120 --> 00:12:39.480 And I think Thin pioneered what some of those things should look like, and 160 00:12:39.559 --> 00:12:43.200 so we I don't want to say we took them whole say, but we 161 00:12:43.240 --> 00:12:48.399 took the general concepts plus my own feeling on streaming, and we pushed that 162 00:12:48.480 --> 00:12:52.840 into REP three. So RAC three has a proper model, a standardized model 163 00:12:52.879 --> 00:12:56.480 for streaming requests and responses. That means when the request comes in, you 164 00:12:56.519 --> 00:13:00.720 can incrementally read what the client is supplying, and when you write the request 165 00:13:00.840 --> 00:13:03.440 back, you can incrementally write the response back out to the client. And 166 00:13:03.480 --> 00:13:07.399 this works for things like web sockets like perma on. RECK three supports web 167 00:13:07.399 --> 00:13:13.799 sockets out of the box on a on a request thread. And so this 168 00:13:15.279 --> 00:13:20.879 happened at the same time that I built Falcon, and so Falcon informed what 169 00:13:20.960 --> 00:13:26.879 RECKS interfaces should look like. And I think so Thin and Thin pioneered those 170 00:13:26.919 --> 00:13:30.919 interfaces or the nature of some of those interfaces, and then we took that 171 00:13:31.039 --> 00:13:33.480 and we looked at When I was building Falcon, I was like, how 172 00:13:33.480 --> 00:13:35.879 do we actually do this in a way that can work across all web servers, 173 00:13:37.440 --> 00:13:41.600 and so we kind of extracted that knowledge standardized in RACK that too a 174 00:13:41.600 --> 00:13:45.000 couple of years actually, like I'm not even joking, it was literally a 175 00:13:45.039 --> 00:13:46.480 couple of years to figure out what they were supposed to look like and get 176 00:13:46.480 --> 00:13:56.080 a release. And so Falcon basically evolves some of the conceptual things that Thin 177 00:13:56.360 --> 00:14:00.200 as an event driven bob server does. And the one other point is that 178 00:14:00.279 --> 00:14:03.080 I'll draw back. I'll go back to comparability, which is when you run 179 00:14:03.120 --> 00:14:09.480 an application on THIN and it uses like say native io that will block THIN. 180 00:14:09.759 --> 00:14:11.960 So there's there's operations you can do in THIN that will be event driven, 181 00:14:13.519 --> 00:14:16.919 and there's operations you can do in THIN that won't be. And I 182 00:14:16.960 --> 00:14:24.480 think things like emsynchrony, which try and provide the transparent rappers, may help 183 00:14:24.559 --> 00:14:28.720 someone, but it's still not guarantee that you're going to have like the really 184 00:14:28.759 --> 00:14:33.559 good, good experience with Thin with a S two and Falcon, because you 185 00:14:33.639 --> 00:14:39.320 have that interface right at the heart of Ruby, intercepting all those blocking operations 186 00:14:39.360 --> 00:14:45.240 like waiting on a process, child process, DNS, resolution, reading and 187 00:14:45.279 --> 00:14:50.759 writing from sockets, sleeping and timers. That kind of stuff. When you 188 00:14:50.840 --> 00:14:56.799 run an application on Falcon it becomes transparent and concurrent. That makes some extent 189 00:14:56.840 --> 00:15:03.759 as possible on that on that particular implementation of Ruby. So it's it's kind 190 00:15:03.759 --> 00:15:07.480 of hard to say what is the difference, but but they fundamentally in a 191 00:15:07.559 --> 00:15:13.440 nutshell, would be like compatibility and just general approach to concurrency in the way 192 00:15:13.480 --> 00:15:22.399 it's exposed. Cool, very cool. I see Valentino thinking you have a 193 00:15:22.480 --> 00:15:28.039 question, I asked, Yeah, I did. Uh, So I'm curious, 194 00:15:28.080 --> 00:15:33.480 like, uh, the io event? Uh what ask First of all, 195 00:15:33.480 --> 00:15:39.879 I love the ACYNC logo. I think that's for those that don't know, 196 00:15:39.919 --> 00:15:43.600 it's a little sink with a Ruby coming out of the faucet. Yeah, 197 00:15:43.919 --> 00:15:48.960 that's great, hilarious. Uh, but I guess I'm trying to understand 198 00:15:50.200 --> 00:15:56.159 maybe uh, because I know the fiber schedule that you've made right, ultimately 199 00:15:56.279 --> 00:16:00.960 that's made it into I don't know why version of Ruby three Yeah, three 200 00:16:00.960 --> 00:16:04.840 to one was the first version of Ruby that had a full implementation of most 201 00:16:04.840 --> 00:16:11.840 of the critical hooks. And so which aspect of ACYNC of your acink framework, 202 00:16:12.000 --> 00:16:15.519 Like, is that piece of it? So the io? Yeah, 203 00:16:15.679 --> 00:16:25.480 that's a good question. So when I first built ACYNC. I was, 204 00:16:26.320 --> 00:16:30.240 but let me step back. As a software engineer, I prefer to build 205 00:16:30.279 --> 00:16:40.080 modular components. I find that there was an interesting observation I made when I 206 00:16:40.120 --> 00:16:44.840 was building. I used to work commercially on C plus plus projects, and 207 00:16:45.039 --> 00:16:48.600 there was observation I made, which was, the C plus plus build system 208 00:16:48.679 --> 00:16:56.759 is so complex in general that people would they'd build one package and then they'd 209 00:16:56.759 --> 00:16:59.399 be like, Oh, there's so much work to build a package of stuff. 210 00:16:59.399 --> 00:17:02.279 I'm just going to end water this package, and so one package grow 211 00:17:02.320 --> 00:17:06.839 bigger and bigger and bigger. Yeah, with like instead of having small libraries 212 00:17:06.839 --> 00:17:11.160 that could work together, you'd have things like qut or there's a whole bunch 213 00:17:11.200 --> 00:17:14.519 of like C plus plus frameworks that the just go from from you to I 214 00:17:14.720 --> 00:17:18.599 all the way through to like database and networking or something, and it's like 215 00:17:18.000 --> 00:17:22.480 and everything in between clude like their own implementation is smart point is and just 216 00:17:22.519 --> 00:17:29.160 like the whole the whole everything, And it was just as a commercial software 217 00:17:29.200 --> 00:17:36.440 engineer working on C plus plus projects, I just found this insanely frustrating because 218 00:17:36.960 --> 00:17:40.079 you're pulling one dependency for one little tiny piece and me to get the whole 219 00:17:40.200 --> 00:17:45.440 kitchen sing when I moved to Ruby and started working in a more commercial sense 220 00:17:45.480 --> 00:17:48.440 in and open source as well, It's like, wow, this is great. 221 00:17:48.480 --> 00:17:52.799 It's like so easy to make a package like a JAM. And so 222 00:17:52.960 --> 00:17:56.440 I've always had this mental model that like the overhead of electronic package upsource code 223 00:17:56.519 --> 00:17:59.880 is like kind of inversely proportional. It is there right to like the size 224 00:17:59.880 --> 00:18:03.119 of packages. Yeah, maybe I got that backwards, but anyway, like 225 00:18:03.279 --> 00:18:06.640 the harder it is to make packages, the worse the packages become in terms 226 00:18:06.680 --> 00:18:10.759 of scope and like compatibility and everything. So I was really inspired by Ruby 227 00:18:10.839 --> 00:18:15.640 gems and how simple Rubygens makes it to build things. So when I built 228 00:18:15.680 --> 00:18:18.240 Acing and the things that came before, I always felt like I want to 229 00:18:18.240 --> 00:18:22.160 build small packages that work together, the compatible, composable even years. And 230 00:18:22.160 --> 00:18:27.319 the reason why is to avoid that multiplicative complexity that comes out of like huge 231 00:18:27.440 --> 00:18:32.119 code bases. And it's even hard to understand. You go to a code 232 00:18:32.119 --> 00:18:33.400 basis one hundred thousand lines of code and you're like, where do I even 233 00:18:33.440 --> 00:18:37.000 start with us, like trying to understand what problem the person was trying to 234 00:18:37.039 --> 00:18:42.039 solve and what they were thinking when they were solving it. So ACING, 235 00:18:42.079 --> 00:18:45.480 you're talking about just just to back up for a second, you're talking about 236 00:18:45.960 --> 00:18:52.920 something like if I wanted to use active record, requiring me to pull in 237 00:18:52.200 --> 00:18:56.680 rails to use active record as opposed to just having active record as its own 238 00:18:56.799 --> 00:19:00.880 little Yeah. I think if you go to look at yeah, if you 239 00:19:00.920 --> 00:19:06.160 go and look at other like languages, you'll find that in order to use 240 00:19:06.200 --> 00:19:08.359 like active record and whatever language you look like, it was C plus plus. 241 00:19:08.440 --> 00:19:11.279 Let me just pull that example again. You wouldn't just be pulling in 242 00:19:11.359 --> 00:19:14.519 like a database, a debt. You'd be pulling in like a whole. 243 00:19:14.839 --> 00:19:18.079 It'd be pulling in like everything. Yeah, everything. Yeah, go and 244 00:19:18.119 --> 00:19:22.240 find like something which only does databases in an ergonomic way, right, yeah, 245 00:19:22.559 --> 00:19:26.680 and yeah, like like maybe Burst is another good example. I know 246 00:19:26.720 --> 00:19:29.559 that bursts can be used independently, but we pulled Burst into projects and it 247 00:19:29.559 --> 00:19:33.200 would add like thirty minutes to the compiled time and like thirty gigabytes of optimber 248 00:19:33.440 --> 00:19:38.559 storage just for the like intermediate files. This is like crazy anyway. So 249 00:19:40.480 --> 00:19:44.160 with ACYNC and gyms that came before, in gyms that have come since, 250 00:19:44.200 --> 00:19:47.839 I always felt strongly I've got to compartmentalize this so it's easy for people to 251 00:19:47.920 --> 00:19:51.039 understand. And actually it was interesting because I've had that feedback from people people 252 00:19:51.039 --> 00:19:52.279 look at the cone that this is easy to understand, like I get it, 253 00:19:52.319 --> 00:19:55.519 and I learned a lot from your current So I'm always hapy to get 254 00:19:55.559 --> 00:20:03.960 that feedback. ACINK one because it was really the proof of concept. It 255 00:20:03.039 --> 00:20:08.240 used an existing gym called n io FAR, which is an event loop that 256 00:20:08.519 --> 00:20:15.000 was especially used by rails now inside action cable. But the FAR is just 257 00:20:15.039 --> 00:20:18.519 an event loop interface. It uses lib ev under the hood, and it 258 00:20:18.559 --> 00:20:25.559 provides non blocking IO for Ruby. And it's the strongest thing about that gem 259 00:20:25.680 --> 00:20:27.680 is just how robust and long lasting it is. It's been around forever. 260 00:20:29.440 --> 00:20:33.240 We have very few bad reports. It's it's solid airs like it's just been 261 00:20:33.559 --> 00:20:36.400 It's a workhourse of I. But it doesn't do anything else apart from io 262 00:20:36.519 --> 00:20:40.599 non blocking IO. So it only does that part of the problem because it's 263 00:20:40.640 --> 00:20:41.759 the problem I was going to solve an ACNC one, you know, as 264 00:20:41.799 --> 00:20:45.119 a proof of concept. That's what we use. So ACYNC draws on n 265 00:20:45.200 --> 00:20:48.960 OO for is the back end, and it provides non blocking IO and you 266 00:20:48.960 --> 00:20:52.480 can build other primitives on top of non blocking IO, like if you want 267 00:20:52.480 --> 00:20:56.960 to do process weight and all you've got is non blocking IO. What you 268 00:20:56.960 --> 00:20:59.279 do is you make it through it. You start your process on there, 269 00:20:59.279 --> 00:21:02.240 and then when the process has done, you have a pipe like a notification 270 00:21:02.319 --> 00:21:04.400 pipe you write on and the main event look was just waiting on that there 271 00:21:04.440 --> 00:21:07.799 end of that pipe, and so that's when you know the process is finished 272 00:21:07.839 --> 00:21:11.200 running. So there are there are ways you can achieve. You can compose 273 00:21:11.240 --> 00:21:18.279 that together to achieve more complex behavior. And ACNC two because that wasn't there 274 00:21:18.359 --> 00:21:22.119 was more about we've showing the proof of concept. Now it's all about performance. 275 00:21:22.480 --> 00:21:26.599 So ACINC one ACINK two actually exactly the same or very very similar interface 276 00:21:26.759 --> 00:21:30.839 like from the user developing point of view, but the back end is completely 277 00:21:30.880 --> 00:21:41.279 different. And so the iow event Gym provides an event selector similar too for 278 00:21:41.440 --> 00:21:51.039 hour, but it's much more comprehensive and it's quite quite the challenge to implement 279 00:21:51.079 --> 00:21:56.559 that across all platforms efficiently and support the wide range of features that we wanted 280 00:21:56.599 --> 00:22:03.720 to support non block and like wedding on processes on BSD versus make owaves versus 281 00:22:03.720 --> 00:22:06.519 Linux. It's all a little different. And so the IOWA event Gym is 282 00:22:06.519 --> 00:22:11.880 where we multiplex out to the different operating system interfaces to do things as officially 283 00:22:11.920 --> 00:22:15.839 as possible. Does that answer your question someone, Yeah, I think so. 284 00:22:18.279 --> 00:22:23.440 I guess that makes I guess I'm trying to find the like upstream Ruby 285 00:22:23.480 --> 00:22:30.799 aspect of it and what what you're bringing to like where where does the fiber 286 00:22:30.839 --> 00:22:36.640 schedule itself like get involved in that stack? Yeah? Okay, So the 287 00:22:36.680 --> 00:22:44.359 IDOW event gym provides a class called selector, and the selector class provides a 288 00:22:44.400 --> 00:22:48.119 lot of the low level interfaces for waiting on IO, so waiting for something 289 00:22:48.400 --> 00:22:52.440 to be readable or reading from something, waiting for a process to become, 290 00:22:53.640 --> 00:22:59.799 to finish, and so provisably is like low level implementations. And then async 291 00:23:00.839 --> 00:23:07.720 acinc has a scheduler, and a scheduler has a selector. So the selector 292 00:23:07.839 --> 00:23:11.480 is something which I suppose you call it a sleep because it's selecting things that 293 00:23:11.559 --> 00:23:17.359 are ready to go, and the scheduler is basically saying what's ready and then 294 00:23:17.440 --> 00:23:26.240 doing that stuff and scheduling the fibers to resume execution. So where the fiber 295 00:23:26.279 --> 00:23:32.799 scheduler interface comes into play is when you start an acinc block. At the 296 00:23:32.799 --> 00:23:38.000 top of that block, the acink scheduler that's allocated as part of that block 297 00:23:40.319 --> 00:23:45.160 will register itself with Ruby as the fiber scheduler, and so then when you 298 00:23:45.200 --> 00:23:52.200 do operations inside that block, those operations will be redirected to that particular scheduler, 299 00:23:52.480 --> 00:23:55.200 which will then decide do I need to delegate this to the event of 300 00:23:55.599 --> 00:24:00.960 the selector and wait for something to happen or whatnot? Gotcha? So, 301 00:24:00.319 --> 00:24:07.440 I mean that's pretty cool. Have you found, like, uh that certain 302 00:24:07.480 --> 00:24:14.240 platforms like are are more efficient at doing like selecting, or or like the 303 00:24:14.279 --> 00:24:18.440 scheduler is like more efficient in certain platforms or do you not like even bother 304 00:24:18.720 --> 00:24:23.000 like measuring at that level? No, if you have a lot of time, 305 00:24:26.720 --> 00:24:33.440 it's a really fascinating problem area. Gosh. Uh. So there's a 306 00:24:33.480 --> 00:24:41.079 couple of main implementations. On Linux, you have EPOLE in irgurin on met 307 00:24:41.240 --> 00:24:44.920 n bs do you have cake here? And on Windows, which we don't 308 00:24:44.920 --> 00:24:49.400 really support very well, we have io c P. And then for other 309 00:24:49.440 --> 00:24:53.799 platforms we just used we defer to Ruby's internal select which is often implemented on 310 00:24:53.880 --> 00:25:00.319 top of Pole, but not always. So give you like a very tangible 311 00:25:00.319 --> 00:25:04.440 example of like where something is very different but this is more of interface thing 312 00:25:04.559 --> 00:25:10.119 than an operating system difference. And actually, I'm not sure, not sure 313 00:25:10.119 --> 00:25:11.880 if this is still true today, because it's not something I readily go and 314 00:25:11.960 --> 00:25:18.559 check. But the select interface on Unix can only handle up to file descripts 315 00:25:18.920 --> 00:25:23.599 one or two four. If you have more than one twenty four file descripts 316 00:25:23.640 --> 00:25:29.160 in your process, select will break. And the reason for this is because, 317 00:25:29.400 --> 00:25:33.640 at least my understanding at the time looked at this, Select users a 318 00:25:33.640 --> 00:25:36.519 bit set, so it literally uses like a piece of binary data and it 319 00:25:36.519 --> 00:25:40.440 flips the bits there one depending on whether you're waiting on that. And the 320 00:25:40.559 --> 00:25:45.599 challenge with there is every iteration on the event loop you're providing. You have 321 00:25:45.640 --> 00:25:48.400 to construct this bit set like hey, here's all the things I'm interested in 322 00:25:48.519 --> 00:25:52.440 up to like whatever, and poll is the same, it's syste list, 323 00:25:52.359 --> 00:25:56.240 and then you supply it to operating system, and the operating system is like 324 00:25:56.279 --> 00:25:59.599 going to go through that list one at a time and say, hey, 325 00:25:59.640 --> 00:26:00.839 this is ready, this is not, this is ready, this is not. 326 00:26:03.440 --> 00:26:07.359 And so if you have like say five connections, that's five things operating 327 00:26:07.359 --> 00:26:11.640 systems to do it. But if you have like five hundred thousand connections, 328 00:26:11.759 --> 00:26:15.480 there's five hundred thousand things that our process semes to do every time it goes 329 00:26:15.480 --> 00:26:21.640 through that like low iteration to process like events. And so the reason why 330 00:26:21.799 --> 00:26:25.200 I mentioned this is because this is wh sort of have a fundamental performance difference 331 00:26:25.279 --> 00:26:30.799 in like the APIs. The most primitive APIs are linearly proportional to the number 332 00:26:30.799 --> 00:26:34.519 of like connections you have in terms of like actual individual operation to find out 333 00:26:34.559 --> 00:26:41.720 what's ready and what's not. But its people. People. People found that 334 00:26:41.880 --> 00:26:45.960 was a problem, Like people were trying to build high performance web servers and 335 00:26:45.200 --> 00:26:52.920 and dns and and whatever else and quickly range like limitation of this interface for 336 00:26:53.079 --> 00:26:57.640 a ventrom and io, and so we ended up with things like poll or 337 00:26:57.640 --> 00:27:03.000 epole or cake where instead of giving that whole list to the operating system every 338 00:27:03.039 --> 00:27:08.480 single time you want to check for readiness, what you do instead is when 339 00:27:08.519 --> 00:27:12.920 you monitoring a file descript or like when you're monitoring something like a network connection 340 00:27:14.480 --> 00:27:18.200 or a web request or whatever, is their data available. What you do 341 00:27:18.279 --> 00:27:22.440 is you register that into the operator and say, hey, when this thing 342 00:27:22.480 --> 00:27:25.559 becomes readable, you let me know. And then when you go through the 343 00:27:25.599 --> 00:27:29.319 event loop, instead of like providing that huge list, you basically say like, 344 00:27:29.559 --> 00:27:30.680 yeah, I told you before, like if this thing comes readily, 345 00:27:30.759 --> 00:27:33.319 you know, and you basically say, is it ready? Now, tell 346 00:27:33.359 --> 00:27:38.200 me tell me if something became ready. And so we turn it into sort 347 00:27:38.240 --> 00:27:42.640 of like instead of every iteration of the event being proportional to the number of 348 00:27:42.680 --> 00:27:48.319 connections, is now just sort of a constant time operation basically proportioned or the 349 00:27:48.400 --> 00:27:49.880 number of ready connections, because you're going to get back a list that's the 350 00:27:49.880 --> 00:27:53.880 same size as a number of connections that have actions to occur. And honestly, 351 00:27:53.920 --> 00:28:00.279 that's pretty much what you hope for. And so KQ and Epole Earth 352 00:28:00.319 --> 00:28:04.960 work like that, and they're considered really the gold standards I suppose for high 353 00:28:04.960 --> 00:28:11.400 performance event driven networking. The biggest problem with those interfaces is that they are 354 00:28:11.480 --> 00:28:23.039 really good to readiness based notifications. Now, basically what that means is when 355 00:28:23.079 --> 00:28:26.880 you have a socket and data is coming across the network. When the data 356 00:28:26.920 --> 00:28:30.200 comes into that socket, the socket is now ready to be read and you're 357 00:28:30.240 --> 00:28:34.039 getting notifications hey there's data available. You can read the request or whatever. 358 00:28:37.039 --> 00:28:38.920 If you try and extend that to the file system, we have files on 359 00:28:40.000 --> 00:28:44.400 disk. A file on disc is always readable. You can always read the 360 00:28:44.480 --> 00:28:48.319 data. It's not reading the data. You're not waiting for the hard drive 361 00:28:48.400 --> 00:28:52.079 to like, you know, spin it around and get to that point. 362 00:28:52.000 --> 00:28:59.000 At the code level. What you're waiting for is the data to come off 363 00:28:59.000 --> 00:29:02.160 the disk and end up in the buffer somewhere that you can access. And 364 00:29:02.200 --> 00:29:04.920 that's I don't want to say it's the slow park, because it's pretty fast, 365 00:29:04.960 --> 00:29:08.319 but like you know, that's the part where you're waiting. And so 366 00:29:10.359 --> 00:29:15.400 the readiness based notification kind of breaks there because it's there's no easy way for 367 00:29:15.480 --> 00:29:18.799 you using e poll or kqu to basically say hey, I want you to 368 00:29:18.799 --> 00:29:22.680 go and read this data and then let me know when it's available to be 369 00:29:22.799 --> 00:29:26.960 read, like what's the like, there's no API for them, and so 370 00:29:27.599 --> 00:29:32.720 there was an original attempt to solve this called like aio or acinc io, 371 00:29:33.000 --> 00:29:36.720 like at the Linux, and I think there was just considered really bad. 372 00:29:36.799 --> 00:29:41.240 Like everything I've read about it's basically just don't use it, and I've not 373 00:29:41.319 --> 00:29:45.000 personally used it, so I don't really want to say like it's it's horrendous, 374 00:29:45.039 --> 00:29:48.480 but I think when I last read about it, what I read was 375 00:29:48.839 --> 00:29:52.079 that a lot of it was emulated and lives and was basically just mapping back 376 00:29:52.119 --> 00:29:57.640 to sequential reads and writes or something. So what what we The evolution of 377 00:29:59.000 --> 00:30:03.720 this API epole is one that supports not just readiness notifications, one that also 378 00:30:03.720 --> 00:30:08.240 supports completion based notifications. There's two kinds of notifications. Readiness is when something 379 00:30:08.960 --> 00:30:14.839 is ready to start, and completion is when something is done executing. And 380 00:30:14.920 --> 00:30:18.160 so when you read data from a disk, you're not interested in waiting for 381 00:30:18.200 --> 00:30:22.799 the readable discs always readable. You can always issue a read request on a 382 00:30:22.839 --> 00:30:26.440 disc and like a socket where if the data is not there, able to 383 00:30:26.640 --> 00:30:30.599 stop your wait forever until the data comes in. Completion base is when the 384 00:30:30.680 --> 00:30:37.759 data is ready to be used. And so Windows has IOCP and Linux recently 385 00:30:37.759 --> 00:30:41.519 experimented with some a good iou ring which is now gaining more traction. And 386 00:30:41.599 --> 00:30:42.960 in fact, I think io your Ring was so good. It was very 387 00:30:44.000 --> 00:30:45.839 funny when it's actually copied it and now when it has their own io your 388 00:30:45.920 --> 00:30:51.039 ring, which actually I tried to use it and it didn't. It was 389 00:30:51.119 --> 00:30:53.640 like horrendous. I couldn't figure it it out, how to get it to 390 00:30:53.680 --> 00:31:00.720 work at all. So so in a nutshell, there's a variety of interfaces. 391 00:31:00.839 --> 00:31:04.359 Fundamentally, what it comes down to is readiness, burst completion and having 392 00:31:04.880 --> 00:31:08.880 those different support for those different events. So when I event jam, we 393 00:31:10.000 --> 00:31:11.799 do support you RING. It's actually the default on LINEX now if you have 394 00:31:11.799 --> 00:31:17.440 an up to date colonel, and it will actually use where possible completion based 395 00:31:17.440 --> 00:31:23.319 notifications for file system and sometimes network I depending on the circumstance. And so 396 00:31:23.440 --> 00:31:30.960 that's actually funnily enough, it's not a huge performance one. As I mentioned 397 00:31:30.960 --> 00:31:36.119 before, event loops much of a muchness. You're beholden to so many figures 398 00:31:36.119 --> 00:31:41.160 outside of your control. And as you asked, do I measure this stuff? 399 00:31:41.240 --> 00:31:45.519 Yes, and I owe you RING actually there when you really get down 400 00:31:45.599 --> 00:31:49.160 to it, when you really start trying to like micro optimize some of these 401 00:31:49.160 --> 00:31:59.279 things, there are some incredibly different, like challenging insights that you derived from 402 00:31:59.359 --> 00:32:06.559 from benching in micro optimization that I suppose the kind of disappointing in a way 403 00:32:06.759 --> 00:32:08.200 as the engineers, you know, when you're trying to actually get to that 404 00:32:08.359 --> 00:32:12.440 level and then you finally realize, oh, even though I did all of 405 00:32:12.440 --> 00:32:15.640 this, I ran into this wall here that I kind of overcome. That 406 00:32:15.759 --> 00:32:19.119 can be a bit frustrating and I arguing, while it brings a lot to 407 00:32:19.119 --> 00:32:21.920 the table, still has a few things like that, and to me, 408 00:32:22.000 --> 00:32:29.400 like she is quite fascinating and what we do next so cool. Yeah, 409 00:32:29.440 --> 00:32:31.519 hey, there, this is Charles Maxwood. I'm excited because I wanted to 410 00:32:31.599 --> 00:32:36.519 let you know about this thing that I pulled together that I had just I've 411 00:32:36.519 --> 00:32:39.400 been dying to have this for years and I never felt like I could, 412 00:32:39.680 --> 00:32:43.599 and then I just realized that there's no reason why I can't. So I'm 413 00:32:43.640 --> 00:32:46.480 putting together a book club and we're going to read development focused books, career 414 00:32:46.599 --> 00:32:50.920 books, you know, technical books, whatever. The first book that we're 415 00:32:50.920 --> 00:32:54.440 going to do is going to be Clean Architecture by Uncle Bob Martin. If 416 00:32:54.440 --> 00:32:58.880 you're not familiar with clean code or some of the other stuff that Bob has 417 00:32:58.920 --> 00:33:00.240 done, check that out. And I've also talked to him on the Clean 418 00:33:00.279 --> 00:33:05.000 Coders podcast, which is on top end devs. But yeah, we're going 419 00:33:05.039 --> 00:33:07.440 to get on He's going to show up to some of our meetings, and 420 00:33:07.440 --> 00:33:10.200 what I'm thinking is we'll probably have like five or six people part of the 421 00:33:10.240 --> 00:33:15.839 conversation along with Bob and I at the same time, and we'll just so 422 00:33:15.880 --> 00:33:19.240 somebody can come on, they can ask their question, and then we'll just 423 00:33:19.680 --> 00:33:22.680 rotate people through, so we'll mute one person, unmute another person when it's 424 00:33:22.720 --> 00:33:27.480 their turn to come on and be part of the discussion. So we'll do 425 00:33:27.559 --> 00:33:29.960 that for like an hour hour and a half. And then the other part 426 00:33:29.960 --> 00:33:32.480 of it that I'm putting together is just kind of a meet and greet gather 427 00:33:32.680 --> 00:33:38.480 area on gather Town. And so after the meetup and the call, we 428 00:33:38.480 --> 00:33:42.640 we'll do as we'll all go over to gather Town and you can just log 429 00:33:42.680 --> 00:33:45.000 in, walk up to a group and have a conversation, and that way 430 00:33:45.000 --> 00:33:49.880 we can all kind of get to know each other and make friends and get 431 00:33:49.880 --> 00:33:52.759 to know people across the world. One thing that I'm finding is that, 432 00:33:52.839 --> 00:33:54.440 yeah, the meetups are starting to come back, but a lot of people 433 00:33:54.480 --> 00:33:58.440 don't have the opportunity to go to a meetup and I really want to meet 434 00:33:58.480 --> 00:34:00.319 you guys and talk to you. Gonna put all that together. It'll all 435 00:34:00.319 --> 00:34:04.039 be part of that book club. You can go to topendev dot com slash 436 00:34:04.039 --> 00:34:07.119 book Club to be part of it, and I'm looking forward to seeing you 437 00:34:07.119 --> 00:34:10.679 there. The first book club meeting will be in December, the beginning of 438 00:34:10.679 --> 00:34:15.079 December. We're starting the first week of December, and you'll also be part 439 00:34:15.079 --> 00:34:19.880 of the conversation about which book we do next. I have one in mind, 440 00:34:20.159 --> 00:34:22.679 but I want to see where everybody's at. So there you go. 441 00:34:23.599 --> 00:34:28.960 So I kind of want to change the topic a little bit, because I 442 00:34:28.960 --> 00:34:31.679 mean a lot of this stuff is fascinating to understand how things work under the 443 00:34:31.679 --> 00:34:36.679 hood, but these are not things that at least in my there's not things 444 00:34:36.719 --> 00:34:38.559 that I plan on touching, right. It's just like fair enough, Okay, 445 00:34:39.639 --> 00:34:43.639 I know that there are little gnomes in my computer that are banging on 446 00:34:43.679 --> 00:34:46.199 this stuff, right, and you're teaching the nomes how to bang on other 447 00:34:46.239 --> 00:34:51.199 stuff, right, And so I'm just gonna run my rails app or my 448 00:34:51.719 --> 00:34:54.800 Ruby you know, Ruby script or whatever on my machine and it's gonna it's 449 00:34:54.840 --> 00:34:59.599 gonna work its magic. So if we come up a few levels too, 450 00:35:00.119 --> 00:35:04.400 kind of the level where I'm usually programming, right, where I'm either writing 451 00:35:04.440 --> 00:35:07.639 a script that does a bunch of things right, and so then I have 452 00:35:07.719 --> 00:35:13.800 the the a sync non blocking io stuff that's interesting or you know things like 453 00:35:13.840 --> 00:35:20.000 that, where do you see people using a sync in Yeah, really good 454 00:35:20.039 --> 00:35:29.360 question. So it's interesting sometimes I hear about like big companies using acing, 455 00:35:29.519 --> 00:35:36.199 they never really divulge much information, so it's fascinating to learn about different use 456 00:35:36.239 --> 00:35:39.119 cases. I know, I want to play buzzword bingo with my projects too. 457 00:35:39.320 --> 00:35:45.880 I'm using aim blockchain and you know, throw in a little bit of 458 00:35:45.920 --> 00:35:46.960 this and a little bit of that. I mean, oh, I can't 459 00:35:47.000 --> 00:35:51.280 tell you what I'm working on. It's stealth mode. Yeah, absolutely, 460 00:35:52.119 --> 00:35:58.400 sir. Where I think Acinc really shines right now is in applications that are 461 00:35:58.440 --> 00:36:04.440 io bound. And it's especially true for things like API servers, proxy servers, 462 00:36:04.440 --> 00:36:09.880 anything like proxy gateways. So if you if you have we just had 463 00:36:09.920 --> 00:36:17.559 someone recently talked to this. They migrated an application from I guess Perma to 464 00:36:19.280 --> 00:36:25.559 Falcon and acing HP Faraday with a few minor changes because I think the acing 465 00:36:25.679 --> 00:36:30.719 HP fairy supports persistent connections by the faults of the book keeping in the application 466 00:36:30.840 --> 00:36:36.840 level. And I think they saw like half the latency, twice the throughput 467 00:36:37.079 --> 00:36:42.159 and have their running costs and so wow, okay, this is the kind 468 00:36:42.199 --> 00:36:45.599 of like and so there was an API gateway if I recall correctly, and 469 00:36:45.679 --> 00:36:49.000 so this is the kind of thing where request comes in and it's basically just 470 00:36:49.000 --> 00:36:52.199 getting proxy through like a different system. And I've seen like a variety of 471 00:36:52.239 --> 00:36:57.800 people with these types of systems in production having great success with the event driven 472 00:36:57.840 --> 00:37:04.280 model. And I think a lot of these people when I when I talk 473 00:37:04.320 --> 00:37:07.480 to them, they don't have to make many changes their application. Which was 474 00:37:07.519 --> 00:37:09.639 one of my original goals was to kind of transparently try and go in there 475 00:37:10.360 --> 00:37:17.360 and make all of those operations non blocking. But sometimes applications do explicitly want 476 00:37:17.360 --> 00:37:23.320 to opt into concurrency, Like sometimes concurrency is a performance thing, and sometimes 477 00:37:23.360 --> 00:37:28.119 concurrency is actually a functional requirement of an application, And I think it's important 478 00:37:28.159 --> 00:37:31.840 to be aware of those two distinctions. So where concurrency is about performance is 479 00:37:31.840 --> 00:37:36.920 if you have Falcon and it's just doing like net HTDP is an APR gateway 480 00:37:37.280 --> 00:37:39.159 you can run, like if you run that on Falcon versus Perma, you'll 481 00:37:39.159 --> 00:37:44.480 get better through put on Falcon without any changes, So you improve your performance, 482 00:37:44.519 --> 00:37:46.440 but there's no actual change to your application behavior or anything like that. 483 00:37:49.079 --> 00:37:52.760 There are also situations where you might be like, hey, I have a 484 00:37:52.800 --> 00:37:57.920 deadline. Let's say you have Let's say you have some data that comes in 485 00:37:58.039 --> 00:38:00.159 and you want to sell it to the highest better, as you need to 486 00:38:00.199 --> 00:38:01.800 know who's going to be the highest better and you're never limited maybe the data. 487 00:38:02.360 --> 00:38:06.199 The value of the data decreases over time, maybe by the second, 488 00:38:06.559 --> 00:38:12.719 and so in that scenario, what you want is you want concurrency because you 489 00:38:12.719 --> 00:38:14.920 want to talk to as many people who are going to pay for the data, 490 00:38:15.199 --> 00:38:16.599 find out who's going to pay the most, probably have a deadline on 491 00:38:16.639 --> 00:38:21.199 when they're going to reply by, so you need to have strong guarantees around 492 00:38:22.039 --> 00:38:28.159 the the operational timing of this of all these requests you're fanning out, and 493 00:38:28.239 --> 00:38:30.599 so Acon can do this too. This is where you probably use like a 494 00:38:30.639 --> 00:38:34.280 fan out mat projuice style approach where you basically, hey, I have like 495 00:38:34.320 --> 00:38:37.559 all these you know, providers I want to talk to, I have the 496 00:38:37.639 --> 00:38:39.480 data that comes in. I want to fan it all out as quickly as 497 00:38:39.519 --> 00:38:44.159 possible over a five second deadline or a ten scin deadline. If they didn't 498 00:38:44.159 --> 00:38:46.760 reply by, then see you later and then go through and figure who's going 499 00:38:46.760 --> 00:38:49.960 to pay the most, and then finally ship the data off to them or 500 00:38:50.000 --> 00:38:52.280 something like that. And so we see use cases like this as well, 501 00:38:52.280 --> 00:39:00.360 where people are using concurrency at the application level to achieve things that not be 502 00:39:00.559 --> 00:39:07.840 easily possible using other approaches. And when I say easy, like look if 503 00:39:07.840 --> 00:39:12.000 I if I'm completely frank, like, of course there are other ways to 504 00:39:12.039 --> 00:39:16.320 achieve some Ruby like threads and maybe even rectors. I feel lucky that works 505 00:39:16.320 --> 00:39:23.559 for you, But I just I wouldn't call them like easy. And I've 506 00:39:23.559 --> 00:39:29.920 certainly had experienced with like other Ruby gems which without a foundation, like asaying, 507 00:39:30.039 --> 00:39:32.440 without kind of like a generic foundation. You have like gems like uh 508 00:39:34.559 --> 00:39:39.000 typheus, which is an HP gem which can do multiple requests. But then 509 00:39:39.039 --> 00:39:42.880 you have like other gems which do the same thing, but they're not compatible 510 00:39:43.159 --> 00:39:45.079 because they all use different like event driven foundations, and so they don't work. 511 00:39:45.079 --> 00:39:49.199 They're not competible with the server. They're not comparedible with each other. 512 00:39:49.280 --> 00:39:52.480 So if you start from a mix of stuff together, which I've seen, 513 00:39:53.159 --> 00:39:59.119 it just ends up like a huge disaster. So I think that's the value 514 00:39:59.159 --> 00:40:05.159 proposition of ACE. There's it's a foundation on which if everyone or you know 515 00:40:05.199 --> 00:40:07.960 and she's it's the fibers schedule, which is the common in defense acin what 516 00:40:08.039 --> 00:40:12.920 is it saying like acink is dead, Long live ACYNC or long live the 517 00:40:12.920 --> 00:40:17.760 fiber schedule. Acink is a great user developer experience in my opinion, But 518 00:40:17.960 --> 00:40:22.440 if you're building a library, you should target the fiber scheduler, not ac 519 00:40:22.760 --> 00:40:24.079 unless you really want to like well, you can choose, of course. 520 00:40:24.119 --> 00:40:32.159 But and so when you run your WAB application on Falcon, not only should 521 00:40:32.199 --> 00:40:37.239 you see improved concurrence I concurrency, so database queries will run in theory like 522 00:40:37.280 --> 00:40:42.159 at the same time, if you have like a high latency query, like 523 00:40:42.280 --> 00:40:46.119 that's not uncommon, then you forgot to put an index. It won't solve 524 00:40:46.159 --> 00:40:50.760 their performance of an individual request, but it will improve the concurrency of the 525 00:40:50.800 --> 00:40:53.880 whole application to the extent possible. But where it gets really interesting is when 526 00:40:53.880 --> 00:40:58.599 you start adopting that model in your application. Yeah, I'm curious about that, 527 00:40:58.880 --> 00:41:01.920 Like, I mean, it's especially now that you know the Ruby world 528 00:41:02.000 --> 00:41:07.719 is still like very much dominant by Rael's ecosystem. Uh. And then so 529 00:41:07.760 --> 00:41:12.840 there have been some more I mean I'm curious because Reels was not always like 530 00:41:13.840 --> 00:41:17.679 you know, runn able on Falcon right, yeah, yeah, yeah, 531 00:41:17.719 --> 00:41:21.760 what was that story? Like what were the challenges there? And like is 532 00:41:21.800 --> 00:41:27.079 it okay? Now I don't normally tell the story in public because I don't 533 00:41:27.079 --> 00:41:30.000 know, I'm gonna like upset, but I think it's about time of talent. 534 00:41:30.119 --> 00:41:36.440 So when I originally went, hang on, let me get some popcorn. 535 00:41:36.800 --> 00:41:39.760 Yeah, look, this is no criticism of anybody. It's moreest a 536 00:41:39.760 --> 00:41:44.440 funny story. And it's probably fair enough that everyone had the opinions they did 537 00:41:44.480 --> 00:41:49.119 at the time and still and still do it to some extent. But it's 538 00:41:49.119 --> 00:41:52.400 also a challenge for me. I suppose. Uh when I first went to 539 00:41:52.239 --> 00:41:58.480 the Rails people and said, hey, you know, can we support as 540 00:41:59.199 --> 00:42:01.960 you know, Falcon or this concurrency stuff. And I didn't really get like 541 00:42:02.000 --> 00:42:08.039 a strong positive reaction. I didn't get like a hugely negative one. I 542 00:42:08.079 --> 00:42:10.840 mean, not everyone looks at it through the same lens that I do. 543 00:42:10.880 --> 00:42:15.400 And that's actually quite good. You know, diversity is often a good thing, 544 00:42:15.079 --> 00:42:20.519 especially in software engineering. Well actually I'm not sure about that, buts 545 00:42:20.599 --> 00:42:30.719 versus faces. Yeah, anyway, so I didn't want to push too hard 546 00:42:30.760 --> 00:42:36.400 on that, and you know, cause more contention, I suppose. And 547 00:42:36.519 --> 00:42:40.320 so it was around the time when I was building Falcon, I thought, 548 00:42:40.400 --> 00:42:44.199 okay, well, actually it's not Rails. It's not The problem is not 549 00:42:44.280 --> 00:42:50.079 Rails. The problem is actually Rack and it wasn't really a problem. RACK 550 00:42:50.239 --> 00:42:54.239 was not evolving at all, and it certainly wasn't evolving in a way that 551 00:42:54.239 --> 00:43:01.599 would support streaming requests and responses and whatnot. And so when I first started 552 00:43:01.599 --> 00:43:04.800 working on RACK, I don't know, I think there were like hundreds of 553 00:43:04.800 --> 00:43:07.840 open issues, like it was just a project. They had been stagnating unfortunately. 554 00:43:07.880 --> 00:43:10.360 So I went when I literally closed I don't know, like a couple 555 00:43:10.639 --> 00:43:14.280 maybe a couple of hundred issues, pull request stuff like that. Was it 556 00:43:14.360 --> 00:43:17.679 was a lot of work, and I wrote in Jeremy Evans, who's amazing, 557 00:43:19.079 --> 00:43:23.320 and gosh, I would like, let me let me say I think 558 00:43:23.360 --> 00:43:27.519 I think we're a great team. And I don't want to like take creator 559 00:43:27.519 --> 00:43:30.280 because I think we're equally like being instrumental with the whole thing. But I 560 00:43:30.280 --> 00:43:35.880 want to say he's a great partner, great great, a great, great 561 00:43:35.920 --> 00:43:43.639 teammate in this open source maintenance. And and so because I felt like it 562 00:43:43.760 --> 00:43:46.400 wasn't too much, it wasn't really worth trying to push you oard on rails. 563 00:43:46.480 --> 00:43:50.400 So I went to RAG and I sort of solved all the problems there, 564 00:43:51.280 --> 00:43:53.719 and then we finally released RACK three. And the great thing was I 565 00:43:53.719 --> 00:44:00.559 only needed to get consensus between me, Aaron, and Jeremy to Rails and 566 00:44:00.599 --> 00:44:02.760 said, hey, Rails, here's RECK three and here's how it works. 567 00:44:05.280 --> 00:44:07.559 And so then we made a bunch of poor requests of Rails to make it 568 00:44:07.559 --> 00:44:16.320 compatible. And that was basically objective truth at that point. So with Rails, 569 00:44:17.760 --> 00:44:21.679 Rails seven point one, with all I think there was like maybe ten 570 00:44:21.760 --> 00:44:27.199 or twenty poor requests that I made now supports RACK three, which means that 571 00:44:27.320 --> 00:44:31.440 Rails supports streaming requests and responses. It means you can drop a web socket 572 00:44:31.440 --> 00:44:35.800 in the middle of a Rails controller and have it work. And if you 573 00:44:35.840 --> 00:44:38.000 run on Falcon you get a ventriven currency with that as well, which is 574 00:44:38.000 --> 00:44:46.760 pretty neat. So the challenges with Rails have been extensive. Rails has I 575 00:44:46.840 --> 00:44:52.000 like to use the word ossified ossified around the request per three or request per 576 00:44:52.039 --> 00:44:55.039 process and going in there with like requests per five it was kind of like 577 00:44:59.119 --> 00:45:05.360 and so there were a lot of assumptions that we completely destroyed. And so 578 00:45:05.400 --> 00:45:12.079 now we hear something called that one of the most critical pieces was done by 579 00:45:12.559 --> 00:45:17.760 uh I think sorry mispronounces like Jean Bossier. Jean Bossier. He implemented the 580 00:45:19.719 --> 00:45:22.280 I think he implemented isolated execution state, or maybe it was someone else I 581 00:45:22.280 --> 00:45:25.920 can't remember. Actually I apologize to whoever wanted that, but it was a 582 00:45:25.920 --> 00:45:35.800 really fundamental feature two, basically configuring RAILS two instead of storing its request date 583 00:45:35.840 --> 00:45:38.840 per thread, which on Falcon every request runs on the same thread, so 584 00:45:38.880 --> 00:45:43.360 of course if you're sharing your request date per thread, you're sharing your request 585 00:45:43.480 --> 00:45:47.360 date with every other request at the same time. Instead, it isolates it 586 00:45:47.400 --> 00:45:52.000 to per fiber, and then that change has to percolate out across all the 587 00:45:52.000 --> 00:45:58.360 different systems and RAILS. The biggest one is age of Record, which is 588 00:45:58.360 --> 00:46:02.559 also the biggest source of database sorry IR latency and lots of applications, and 589 00:46:02.679 --> 00:46:09.119 so right now there's a pull request to address address some of the issues that 590 00:46:09.159 --> 00:46:13.800 we've identified with the performance of age of Record on a fiber based server. 591 00:46:13.960 --> 00:46:19.039 So I think RAILS seven point one is compatible like fully compatible with with with 592 00:46:19.199 --> 00:46:23.239 Falcon, and RAILS eight will make it even better, and I think we're 593 00:46:23.280 --> 00:46:32.679 on track to seeing uh much. Let me just say that I think RAILS 594 00:46:32.679 --> 00:46:37.440 eight will just work, and it will just work really well. Nice. 595 00:46:37.960 --> 00:46:45.880 So on a related note, where was they gonna go oh, I remember, 596 00:46:46.440 --> 00:46:50.320 I'll let Valentino ask this question and I'll ask my question. Sorry. 597 00:46:50.679 --> 00:46:52.239 Yeah, I was just gonna say, like, I'm not gonna lie. 598 00:46:52.280 --> 00:46:58.039 When I first saw like Rail's database, you know, do it later kind 599 00:46:58.039 --> 00:47:06.519 of you know a sync uh. I was very I mean having somebody just 600 00:47:06.519 --> 00:47:10.440 like sprinkle those around everywhere in his current in the state they released it at 601 00:47:12.360 --> 00:47:15.159 it seemed like it was like a little too much magic for what it was 602 00:47:15.199 --> 00:47:20.159 doing at the time. And I now I feel like a little better now 603 00:47:20.239 --> 00:47:23.920 now that you've gone through the state of things. I know we're still not 604 00:47:24.000 --> 00:47:28.800 quite there to just like, Okay, everything's concurrency in rails now, I 605 00:47:28.840 --> 00:47:32.199 know that's not true, but yeah, I want to just call it a 606 00:47:32.199 --> 00:47:38.039 little distinction. Dan, So you've mentioned a feature in Rails called load as 607 00:47:38.880 --> 00:47:47.400 called I think, Yeah, I'm a little disappointed they chose this name and 608 00:47:47.440 --> 00:47:53.760 convention because essentially load and threat it's not it's got nothing to do with acinc 609 00:47:53.880 --> 00:48:01.679 the like the gym that I created. And while it might solve some problems, 610 00:48:02.000 --> 00:48:07.159 I actually had feedback from some people who tried out on their applications and 611 00:48:07.239 --> 00:48:12.480 said performance was either the same or worse, and that it actually was hard 612 00:48:12.519 --> 00:48:22.440 to know when it should be used. So I think that the value of 613 00:48:22.519 --> 00:48:27.360 load ACYNC in rails as it stands today where it does it does a database 614 00:48:27.400 --> 00:48:30.039 career in a background through it is when you can stack up several database quers 615 00:48:30.039 --> 00:48:34.960 that are slow and have them running parallel. That's that's the key advantage. 616 00:48:35.039 --> 00:48:39.800 But the problem is there's only so far you can push that. I suppose 617 00:48:40.159 --> 00:48:44.760 even if Falcon, there's only so far you can push paralysm, concurrency and 618 00:48:45.000 --> 00:48:51.000 h when you parallelize operations instead of having the linear some of the total time 619 00:48:51.039 --> 00:48:55.840 you have you state them to get the time is the slowest operation. But 620 00:48:55.880 --> 00:49:00.000 not that I suppose in the real world use case, not that many people 621 00:49:00.079 --> 00:49:01.599 are stacking up whereas like that annoying. When to do it and where to 622 00:49:01.639 --> 00:49:07.880 do it is the challenge, And so with Falcon we still essentially either do 623 00:49:08.000 --> 00:49:13.280 linear or if you explicitly opt and you can do the same thing like multiple 624 00:49:13.360 --> 00:49:21.639 dard base careers in parallel. But it's not just the individual request that if 625 00:49:21.639 --> 00:49:24.840 you run that in PERMA, you're still tying up the entire request threat and 626 00:49:24.920 --> 00:49:30.280 Falcon that whole request will just get set in the background until the data and 627 00:49:30.320 --> 00:49:35.960 the dard base comes in and then it will get resumed. So maybe in 628 00:49:36.000 --> 00:49:39.719 summary, like the performance characteristics of load ACNC and RAILS as it stands today, 629 00:49:40.159 --> 00:49:45.559 it's not really easy to have an intuition about where it makes sense. 630 00:49:45.599 --> 00:49:49.039 And that that to me, like it comes back to what I've said really 631 00:49:49.079 --> 00:49:53.360 at the start, which was building the good developer experience or building the interface 632 00:49:53.360 --> 00:49:57.320 which is kind of intuitive and makes sense, is really like fundamental with this 633 00:49:57.360 --> 00:50:01.960 whole problem because concurrency is hard enough without trying to get used to think about 634 00:50:02.000 --> 00:50:05.960 these issues and trying to figure out where this makes sense to where it doesn't 635 00:50:06.000 --> 00:50:13.239 make sense. Yeah, that makes sense. I'm gonna push us to another 636 00:50:13.280 --> 00:50:15.679 topic here really quickly. It's it's kind of related to some of this stuff 637 00:50:15.679 --> 00:50:22.320 where you I think Valentino actually brought it up before the show and then you 638 00:50:22.320 --> 00:50:24.840 know, I asked you about it heading in, and that is he said 639 00:50:24.880 --> 00:50:30.480 something about you building Falcon into a platform that's more than just a web server. 640 00:50:31.679 --> 00:50:35.719 Where you started to discuss that, you know, before I stopped and 641 00:50:35.760 --> 00:50:38.679 said let's talk about this on the show. It sounded very interesting. So 642 00:50:38.719 --> 00:50:42.840 do you want to kind of plug into that and explain to people what you're 643 00:50:42.840 --> 00:50:49.840 looking to make Falcon into. Sorry, just replying to someone. It's the 644 00:50:49.840 --> 00:50:58.559 greatest keyboard, right Cherry Browns. Look. So when I first married Falcon 645 00:51:00.079 --> 00:51:02.119 as a proof of concept, I kind of squashed a lot of stuff into 646 00:51:02.159 --> 00:51:08.239 it, including uh so, there was a gem that there was a client 647 00:51:08.320 --> 00:51:14.360 HP and serve a gym called acinc HGP. That gem supports HP one HB 648 00:51:14.400 --> 00:51:17.760 two today and hopefully in the future supports HDV three. I've been working on 649 00:51:17.760 --> 00:51:22.199 it, but it's quite HD three is like probably the most insanely complicated standard 650 00:51:22.519 --> 00:51:31.000 ever tried to deal with. So Falcon was kind of an adapter. I 651 00:51:31.039 --> 00:51:36.920 think h GDP has has a has a. There's a gym called Protocol h 652 00:51:37.000 --> 00:51:42.519 GDP which provides a generic request and response smandic objects. So like the head 653 00:51:42.639 --> 00:51:45.320 is the body, status code, the version that kind of the stuff that's 654 00:51:45.360 --> 00:51:51.400 the same across all versions of h GDP, and then acinc hg B takes 655 00:51:51.440 --> 00:51:57.280 that and puts it into a makes the request and response running an asynchronous task, 656 00:51:57.440 --> 00:52:02.000 so each individual request or response is is is operating concurrently. And then 657 00:52:02.039 --> 00:52:15.880 what Falcon did originally was adapt rack applications into ACNC HTP server compatible interface and 658 00:52:15.920 --> 00:52:22.119 that that was actually non trivial because there's things like rack hijack and like all 659 00:52:22.159 --> 00:52:27.440 the head mapping stuff and dealing with response bodies that is quite there's like quite 660 00:52:27.440 --> 00:52:31.599 a few complexities in that to map a RAC application to a straightforward HTP interface, 661 00:52:35.360 --> 00:52:40.039 And after a while I just thought this is something that I actually want 662 00:52:40.039 --> 00:52:45.079 to use in a more generic sense, like mapping IRAQ application to an ACINC 663 00:52:45.239 --> 00:52:51.880 HP server is not something that's Falcon specific, and Falcon became more about So 664 00:52:52.280 --> 00:52:55.199 there's a gem that does is called Protocol dash Rack, and Protocol dash Rack 665 00:52:55.320 --> 00:53:01.039 provides all the mappings between acinc HVAL, protoco HTP, and RACK. So 666 00:53:01.079 --> 00:53:06.119 you can take an incoming request that that follows that very simple semantic format and 667 00:53:06.159 --> 00:53:07.760 map it into like a RAC object and then you can map it back again. 668 00:53:08.199 --> 00:53:12.719 And it does all the mappings for things like handling streaming request and responses. 669 00:53:12.760 --> 00:53:14.880 So if you throw a websuck at at it will work correctly, which 670 00:53:14.960 --> 00:53:23.000 is kind of kind of important. So Falcon got split up into pieces, 671 00:53:23.519 --> 00:53:28.239 and so what Falcon does today is Falcon is kind of an application container, 672 00:53:28.400 --> 00:53:32.159 and what that means is there's a gem called acinc Container, and acin container 673 00:53:32.199 --> 00:53:37.679 lets you do multi threaded, multi process or hybrid or various other ways of 674 00:53:37.719 --> 00:53:44.079 deploying and application and scaling that application. And what Falcon does is it dis 675 00:53:44.119 --> 00:53:50.440 coordinates basically that container for like rolling restarts, blue green deployments, these kinds 676 00:53:50.440 --> 00:53:53.639 of like things. And it has a configuration which basically just says, hey, 677 00:53:53.679 --> 00:53:59.239 I want you to host this RACK application on port whatever, and so 678 00:53:59.320 --> 00:54:01.480 you can run any application in there. It doesn't have to be a RANK 679 00:54:01.519 --> 00:54:09.280 application. You can actually run a native HP server compatible interface application and Falcon 680 00:54:09.320 --> 00:54:14.079 will host that you use you host multiple applications in one instance if you want. 681 00:54:14.119 --> 00:54:17.119 So it's just basically a container now for hosting applications and all individual pieces 682 00:54:17.159 --> 00:54:22.920 are just connected together. And so where I think this goes next is I 683 00:54:22.039 --> 00:54:29.800 quite like to see us simplify like rails deployment. This is we like put 684 00:54:29.840 --> 00:54:31.639 a goal to it. It would be simplifying rails deployment. And I think 685 00:54:31.880 --> 00:54:36.440 there's been a lot of work in this area, but it's still quite challenging. 686 00:54:36.440 --> 00:54:40.440 Like you need a database, probably need reddis you probably need background job 687 00:54:40.519 --> 00:54:47.079 runners, you probably need obviously a web server usually sometimes you get other things 688 00:54:47.159 --> 00:54:52.599 running in the background there, and we've had things like what's that, what's 689 00:54:52.599 --> 00:55:00.239 there a tool called that starts multiple processes. Gosh, I for get, 690 00:55:00.239 --> 00:55:02.440 there's there's there's a couple of gyms be full coordinate all these processes for you. 691 00:55:02.800 --> 00:55:06.639 But I wanted like that, yeah, foreman, that's the one. 692 00:55:06.719 --> 00:55:09.639 Yeah, And so I've used that in the past and it works okay. 693 00:55:09.679 --> 00:55:17.599 But I felt like it's still quite difficult to deploy a server, and so 694 00:55:20.920 --> 00:55:22.519 what I wanted to I would have to like have a self contained application, 695 00:55:23.239 --> 00:55:28.679 so Falcon application that includes like a job server, and you basically go, 696 00:55:28.760 --> 00:55:31.159 here's my hardware, go and run this, and you have to be so 697 00:55:31.280 --> 00:55:37.039 nice. I think even action cable can be quite tricky to deploy, you 698 00:55:37.079 --> 00:55:39.199 know, like with action cable often you have like any cable, or you 699 00:55:39.280 --> 00:55:44.000 have Perma that's the dedicated it's a PERMA running on a different port. It's 700 00:55:44.079 --> 00:55:46.440 just like all these like funny, tricky things that have fallen out of the 701 00:55:46.480 --> 00:55:50.519 assumptions we've made about how things are going to be deployed. And I feel 702 00:55:50.519 --> 00:55:53.039 like if we just step back and go, hey, but what problem we 703 00:55:53.119 --> 00:55:59.440 really going to solve here? Falcon can better address those by by exposed and 704 00:55:59.480 --> 00:56:04.000 kind of this can you know, application host base model. But you basically 705 00:56:04.039 --> 00:56:07.880 wanted a job sere and a web server and disserve de server, and I'm 706 00:56:07.880 --> 00:56:12.280 just gonna start it all up and my applications running. Yeah, in fact, 707 00:56:12.679 --> 00:56:19.320 for my development stuff, I started out with the tailwind cssgem for rails. 708 00:56:19.800 --> 00:56:22.079 I guess it's tailwind CSS tesh rails, right, And so when you 709 00:56:22.119 --> 00:56:28.719 install it, it installs the bin dev executable, which effectively calls out to 710 00:56:28.880 --> 00:56:34.440 foreman and says, hey, run the tailwind watcher alongside the web server, 711 00:56:34.840 --> 00:56:37.360 right. And so then as I've added in full tech search and things like 712 00:56:37.360 --> 00:56:42.559 that, right now, it's it spins up the full text search engine and 713 00:56:43.880 --> 00:56:45.960 right, all the things that have to go into all of that stuff. 714 00:56:46.000 --> 00:56:52.920 And so anyway, just kind of throwing that all together, it'd be really 715 00:56:53.000 --> 00:56:55.719 nice to be able to deploy that way, because yeah, when I deploy, 716 00:56:55.800 --> 00:57:00.840 it's okay, and I'm using camal and so it's I need an accessory 717 00:57:00.880 --> 00:57:04.920 for this and an accessory for this, and then I need two app servers. 718 00:57:04.960 --> 00:57:07.760 One of them is the app app server and the other one's the job 719 00:57:08.360 --> 00:57:14.880 server, right, And so it orchestra orchestrates like six or seven different Docker 720 00:57:14.920 --> 00:57:19.800 containers across three or four servers to do all the things that I need. 721 00:57:19.800 --> 00:57:22.320 And yeah, it would be beautiful to just be able to run all or 722 00:57:22.360 --> 00:57:27.599 most of that under a Hey I've got this application that runs like this, 723 00:57:27.760 --> 00:57:32.400 and then sure, maybe I have a caddy or traffic load balancer out there 724 00:57:32.400 --> 00:57:37.519 that I have to manage separately. But yeah, anyway, I think I 725 00:57:37.519 --> 00:57:45.079 think I've made things too complicated. Well, so David dh when he gave 726 00:57:45.159 --> 00:57:51.800 his Rails World his Rails World keynote, and he was talking about all the 727 00:57:51.800 --> 00:57:54.480 different things that are going into rails, and you know, he talked about, 728 00:57:54.519 --> 00:57:57.119 hey, we got this, and we got this, and we got 729 00:57:57.119 --> 00:58:01.559 this, and then specifically he got into the asset management for Rails and what 730 00:58:01.639 --> 00:58:08.039 he said was, we picked up webpack and webpacker because it was kind of 731 00:58:08.079 --> 00:58:13.159 the most comprehensive way to do it and it did everything that we wanted, 732 00:58:13.199 --> 00:58:16.880 but it was complicated and gross and hard to use, right, and so 733 00:58:17.000 --> 00:58:21.079 what then, what he pointed out was, but we had to take that 734 00:58:21.239 --> 00:58:25.960 step in order to get to where we got to with import maps and h 735 00:58:27.079 --> 00:58:30.400 prop shaft and so when I look at it, it's like, yeah, 736 00:58:30.480 --> 00:58:35.639 we've kind of done things in a way that is not exactly the most friendly 737 00:58:35.679 --> 00:58:38.000 way. But I think what it's done is it's kind of given us the 738 00:58:38.039 --> 00:58:43.480 tools for Okay, we know that we generally need all these things now and 739 00:58:43.519 --> 00:58:46.559 we know how to run them all. So yeah, unify the interface, 740 00:58:47.440 --> 00:58:52.039 I think, but it's an essential step to getting where we are. Yeah, 741 00:58:52.079 --> 00:58:53.199 to your point, I think to know the happi path, you have 742 00:58:53.239 --> 00:58:57.760 to know the unhappi path. Yeah. Well, sometimes you get lucky and 743 00:58:57.800 --> 00:59:00.400 you can just happy path your way through it. But yeah, but then 744 00:59:00.440 --> 00:59:01.599 you don't know. Then you don't really know how happy you're like yeah, 745 00:59:01.760 --> 00:59:07.400 because you didn't really experience the pain of like doing it. Yeah. I 746 00:59:07.440 --> 00:59:12.800 mean that's kind of that's kind of the like the negative of rails as a 747 00:59:12.800 --> 00:59:16.000 framework, right as it provides all this magic, and you know, if 748 00:59:16.039 --> 00:59:22.480 you specialize in knowing the feature, uh, then it you know, then 749 00:59:22.519 --> 00:59:25.039 you need to know, right, like otherwise forget about it. Like yeah, 750 00:59:25.039 --> 00:59:28.719 but like okay, well, if you run into like an edge case 751 00:59:28.880 --> 00:59:32.760 you know, well, and the person that is expert like is unavailable, 752 00:59:34.840 --> 00:59:37.639 then like you're spinning your wheels trying to figure out how it all works. 753 00:59:37.280 --> 00:59:42.400 I mean, I want to talk to the specific point. A long time 754 00:59:42.400 --> 00:59:45.679 ago, I did a jet of C development with airports like frameworks, and 755 00:59:45.719 --> 00:59:49.920 they were there was no source card. If you're like in his table view 756 00:59:50.000 --> 00:59:52.159 didn't work correctly, there was no way you'd be able to figure out like 757 00:59:52.159 --> 00:59:55.800 why the thing was rendering wrong or why the column was in the wrong place 758 00:59:55.840 --> 00:59:59.960 because you put a brake point and it would just there's nowhere else to go. 759 01:00:00.320 --> 01:00:02.800 And I really want to call out, like how amazing Ruby and Rails 760 01:00:02.840 --> 01:00:13.079 is. I mean, of course open source projects are all similar in this 761 01:00:13.119 --> 01:00:16.000 regard. I suppose it's part of the definition of having the source available, 762 01:00:16.760 --> 01:00:22.400 but it's just so refreshing if you've had that experience that pain to be able 763 01:00:22.400 --> 01:00:24.880 to go into the source code all the way down to like the interpreter. 764 01:00:25.280 --> 01:00:29.599 I mean occasionally I do find bugs and I'm digging in the interpreter, putting 765 01:00:29.639 --> 01:00:34.840 like estate it's going to figure out, like what's going on. We're so 766 01:00:35.000 --> 01:00:37.719 lucky to like to have that, and I just I want to call it 767 01:00:37.719 --> 01:00:40.199 out because like maybe people don't realize, like if you've all you've ever done 768 01:00:40.280 --> 01:00:44.880 is use RAILS and frames with all the source code is available. You may 769 01:00:44.880 --> 01:00:49.880 not have experienced the level of pain that comes from using closed sourced frameworks or 770 01:00:50.519 --> 01:00:54.679 lib resort or whatever systems, and it can be extremely painful when you're trying 771 01:00:54.679 --> 01:00:59.719 to debug an issue, Like I'm talking like multiple weeks with multiple engineers trying 772 01:00:59.760 --> 01:01:02.800 to like I get things out. So we're extremely lucky with Rails in Nate 773 01:01:02.840 --> 01:01:07.840 regard, Yep. Absolutely, Well, we're kind of getting towards the end 774 01:01:07.840 --> 01:01:12.840 of our scheduled time as far as usually picks take up a little bit of 775 01:01:12.880 --> 01:01:16.320 time, so really quickly if people want to, can we can we get 776 01:01:16.320 --> 01:01:22.079 to one quick thing because I just saw that Samuel released like a spike on 777 01:01:22.119 --> 01:01:25.679 a sync job, which is like one of the most requested like things I've 778 01:01:25.679 --> 01:01:30.559 been waiting for, is like this the surface. Do I just get a 779 01:01:30.639 --> 01:01:36.679 quick like THELDR of what that is and maybe how people could get involved. 780 01:01:36.719 --> 01:01:40.519 So I think Rails has done a pretty good job of shaping out interface for 781 01:01:40.639 --> 01:01:46.760 job execution, and I think Mike did a great job of creating Sidekick, 782 01:01:47.280 --> 01:01:54.199 and I think we've converged on what it looks like now is a user interface 783 01:01:54.599 --> 01:02:01.519 application developers, what's you know. Mike's work was really pioneering, I think 784 01:02:01.639 --> 01:02:08.320 in lots of ways, and acinc job well, sidekick uses multiple threads usually 785 01:02:08.679 --> 01:02:13.480 for executing multiple jobs, which which is perfectly acceptable, and I think headlights 786 01:02:13.480 --> 01:02:15.440 to also use reactors if possible. I think that's still a way out. 787 01:02:15.480 --> 01:02:23.000 But acinc job is basically runs on a similar principle users riddus. I'm hoping 788 01:02:23.000 --> 01:02:27.360 to also add like a database back end as well at some point, maybe 789 01:02:27.440 --> 01:02:34.239 squl light or just generic database layer, and then it basically it's your schedule 790 01:02:34.239 --> 01:02:37.400 and execute jobs. And so my goal is to have this provide so on 791 01:02:37.440 --> 01:02:42.440 the client side it will provide like an active job adapter, and they will 792 01:02:42.440 --> 01:02:45.559 probably be the main most common use case, I would say. And then 793 01:02:45.599 --> 01:02:51.039 on the back end it will just use a sync and probably I'll make it 794 01:02:51.119 --> 01:02:53.320 very easy to spin up as part of a Falcon application, so you might 795 01:02:53.360 --> 01:02:57.719 have basically seeing your Falcon configuration, a weir application and a bit of jobs 796 01:02:57.760 --> 01:03:05.000 ever and and have that just x Q and coordinate as efficiently as possible. 797 01:03:05.199 --> 01:03:07.119 So yeah, acinc job is something I've been meaning to work on for a 798 01:03:07.119 --> 01:03:10.400 long time. I just didn't really have the band with for it, but 799 01:03:10.440 --> 01:03:17.159 the current spike is looking quite good, like it's it's I think ACYNC maybe 800 01:03:17.239 --> 01:03:24.119 to give an interesting context, I often work on the library of ACYNC, 801 01:03:24.519 --> 01:03:30.320 so I'm not not that often like a consumer of ACYNC. But with acinc 802 01:03:30.360 --> 01:03:32.880 job, I was kind of a consumer of ACNCY. Like you know, 803 01:03:34.039 --> 01:03:38.159 there was a very fundamental part of a job and so I had like that 804 01:03:38.239 --> 01:03:40.840 good experience that I was trying to you know, from the other side. 805 01:03:42.679 --> 01:03:45.800 It was really straightforward to write the code. Radis just worked. It was 806 01:03:45.840 --> 01:03:51.199 easy to do like quite complex things with fratis, like have a heartbeat a 807 01:03:51.320 --> 01:03:53.559 job server with a heartbeat, which then recovers jobs if the server dies. 808 01:03:54.480 --> 01:03:58.119 So a bunch of this functionality it was all done instead of like you know, 809 01:03:58.199 --> 01:04:00.800 maybe what one hundred lines of code to code And if you compare that 810 01:04:00.880 --> 01:04:03.519 with I know that Psychic does a lot more, but Psychic has a lot 811 01:04:03.519 --> 01:04:08.559 more lines of code. And I'm a big fan of like list lines of 812 01:04:08.559 --> 01:04:15.360 code, list bugs. So it's really admirable. I think, yeah, 813 01:04:16.880 --> 01:04:21.480 well, I'm looking forward to seeing more progress on that because uh yeah, 814 01:04:20.840 --> 01:04:26.840 I feel like that's the one thing as rails app grows is you try and 815 01:04:26.920 --> 01:04:30.159 figure out how to execute all your jobs faster. Yeah yeah, yeah, 816 01:04:30.239 --> 01:04:34.559 yeah, you guys drop a link to that in the comments. It goes 817 01:04:34.599 --> 01:04:41.119 out to Facebook, YouTube, and Twitch, not Twitter LinkedIn if you're over 818 01:04:41.159 --> 01:04:45.199 there. Awesome, all right, I can do Yeah, it looks like 819 01:04:45.360 --> 01:04:48.320 Valentino dropped it. All right, Well, I'm gonna push this toward picks 820 01:04:48.360 --> 01:04:53.280 and wrapping up the show then. But before we do that, Samuel, 821 01:04:53.320 --> 01:04:56.840 if people want to connect with you, if they have questions or things they 822 01:04:56.880 --> 01:05:00.760 want to do with a SYNC, how do they find you. The best 823 01:05:00.760 --> 01:05:03.480 way to do that is for get hub discussions. I have a personal ge 824 01:05:03.599 --> 01:05:09.400 hub discussion under GitHub slash by aquatics. But if it's ask specific, then 825 01:05:09.440 --> 01:05:13.039 just go and find the projudie and can use the discussion. Okay, there's 826 01:05:13.079 --> 01:05:17.519 a whole bunch of earlier adopters and fantastic open source maintainers and contributors. Perry 827 01:05:17.599 --> 01:05:21.599 will if I'm not available jumping usually and I'd like to me that's amazing. 828 01:05:24.519 --> 01:05:27.719 So yeah, it's the best way to get in touch. And the great 829 01:05:27.760 --> 01:05:30.639 thing about that is me building a knowledge base. So you might want to 830 01:05:30.639 --> 01:05:33.039 do us if you've got a sort of a technical question been doing a search 831 01:05:33.079 --> 01:05:38.639 first might help out as well. Awesome, Well, we'll put a link 832 01:05:38.679 --> 01:05:43.199 to your GitHub in the comments and then yeah, my team can pull them 833 01:05:43.199 --> 01:05:45.320 out and put them in the show notes. Let's go ahead do some picture 834 01:05:45.320 --> 01:05:49.400 real quick. Have you ever wished that you had a group of people that 835 01:05:49.440 --> 01:05:53.920 were just as passionate about writing code as you are? I know I did. 836 01:05:54.039 --> 01:05:56.639 I did that for most of my career. I'd go to the meetups, 837 01:05:56.639 --> 01:05:59.599 I try and create other opportunities, and it was just really hard, 838 01:05:59.760 --> 01:06:01.400 right the meetups. I got some of that, but they were only like 839 01:06:01.480 --> 01:06:04.599 once or twice a month, and it was just really hard to find that 840 01:06:04.639 --> 01:06:10.480 group of people that I connected with and really wanted to talk about code a 841 01:06:10.519 --> 01:06:13.159 lot, right, I mean, I love writing code. I think it's 842 01:06:13.199 --> 01:06:19.000 the best. And so I've decided to create this community and create a worldwide 843 01:06:19.000 --> 01:06:21.159 community that we can all jump in and do it. So we're going to 844 01:06:21.239 --> 01:06:26.320 have two workshops every week. One of those or two of those every month 845 01:06:26.519 --> 01:06:28.840 are going to be Q and A calls right where you can get on you 846 01:06:28.840 --> 01:06:31.599 can ask me or me and another expert questions. The rest of them are 847 01:06:31.599 --> 01:06:36.440 going to be focused on different aspects of career or programming or things like that. 848 01:06:36.519 --> 01:06:41.679 Right, So it'll go anywhere from like deployments and containers all the way 849 01:06:41.760 --> 01:06:45.280 up to managing your four oh one K and negotiating your benefits package. Well, 850 01:06:45.320 --> 01:06:48.079 we'll cover all of it, okay. And then we're also going to 851 01:06:48.159 --> 01:06:53.559 have meetups every month for your particular technology area. So we have shows about 852 01:06:53.639 --> 01:06:57.599 JavaScript, react, angular view and so on. We're going to have meetups 853 01:06:57.599 --> 01:07:00.079 for all of those things. I'm going to revive the freelancer show, so 854 01:07:00.320 --> 01:07:02.360 we'll have one about that, right, so you can get started freelancing or 855 01:07:02.360 --> 01:07:06.960 continue freelancing if that's where you're at. And I'm working on finding authors who 856 01:07:08.000 --> 01:07:14.159 can actually do weekly video tutorials on some thing for ten minutes. This related 857 01:07:14.320 --> 01:07:17.079 again to those technology areas so that you can stay current keep growing. So 858 01:07:17.119 --> 01:07:21.920 if you're interested, go to topendevs dot com slash sign up and you can 859 01:07:21.920 --> 01:07:27.559 get in right now for thirty nine dollars. When we're done, that price 860 01:07:27.639 --> 01:07:30.440 is going to go up to seventy five dollars and the thirty nine dollars price 861 01:07:30.519 --> 01:07:38.159 gets you access to two calls per week. The full price at one hundred 862 01:07:38.159 --> 01:07:41.119 and fifty dollars, which is going to be seventy five dollars over the next 863 01:07:41.119 --> 01:07:44.679 few weeks. That price is going to get you access to all of the 864 01:07:44.719 --> 01:07:47.599 calls and all of the tutorials and everything else that we put out from top 865 01:07:47.639 --> 01:07:53.199 Endevs, along with member pricing for our remote conferences that are coming up next 866 01:07:53.280 --> 01:07:59.519 year. So go check it out topendevs dot com slash sign up Valentino. 867 01:07:59.559 --> 01:08:03.719 Do you have some sure? Uh? So, I love hacking on hardware 868 01:08:04.039 --> 01:08:09.480 in my free time, and I came across this, Uh, somebody made 869 01:08:09.519 --> 01:08:18.520 an open source wearable AI device that uses the Cora AI h embedded system. 870 01:08:18.880 --> 01:08:25.560 Uh. And I'm really Coral, sorry Coral di AI. So I'm really 871 01:08:25.560 --> 01:08:29.960 in. I got a whole set of things that I'm gonna try and use 872 01:08:29.960 --> 01:08:36.159 a Raspberry uh piser or pied Wu and the Coral and fuse them together and 873 01:08:36.239 --> 01:08:41.199 hope that I can like make my own like wearable AI device. Uh. 874 01:08:41.279 --> 01:08:44.960 And so he has a whole project down I forget the name of I'll put 875 01:08:44.960 --> 01:08:47.399 it in the show notes though, but I'm looking forward to building that next 876 01:08:47.439 --> 01:08:55.560 weekend. Very cool. Yeah, I'm gonna throw out a few picks here 877 01:08:55.640 --> 01:09:00.000 myself. The first one is I always do board game pick on the show. 878 01:09:00.319 --> 01:09:03.720 So last night I was hanging with my friends and one of my buddies 879 01:09:03.760 --> 01:09:06.479 bought a new game, and so of course we played it and it was 880 01:09:06.640 --> 01:09:12.359 awesome. It's called fire Tower. Came out in twenty nineteen, two to 881 01:09:12.399 --> 01:09:15.880 four players. We played it with four players, just to put that in 882 01:09:15.920 --> 01:09:19.239 there. We were kind of time limited, and I think it took us 883 01:09:19.399 --> 01:09:25.039 an hour maybe a little more in an hour play it hour and ten hour 884 01:09:25.079 --> 01:09:28.800 and fifteen And that was with us learning to play the game and playing the 885 01:09:28.840 --> 01:09:33.479 game and effectively. The idea is is each player has a tower in one 886 01:09:33.520 --> 01:09:38.119 of the corners of the board, and then there's a wildfire in the middle 887 01:09:38.119 --> 01:09:43.159 of the board, and you take turns. So the wind's blowing in a 888 01:09:43.159 --> 01:09:46.960 particular direction, so you add a flame token to the board in that direction 889 01:09:47.119 --> 01:09:53.119 from any other flame token right has to be next to it. But then 890 01:09:53.199 --> 01:09:57.119 you play a card and so the cards can put out fire, they can 891 01:09:57.479 --> 01:10:03.560 expand the fire, they can change the wind direction, and so the the 892 01:10:03.560 --> 01:10:08.680 the way you win is you take out everybody else's tower, so you move 893 01:10:08.760 --> 01:10:11.920 you you move the fire toward them and away from you. Is kind of 894 01:10:11.960 --> 01:10:15.840 the deal. I I really enjoyed the game. Will also point out that 895 01:10:15.920 --> 01:10:18.880 I won the game by taking out each of my friends one at a time. 896 01:10:19.640 --> 01:10:23.479 When you're eliminated, you are the spirit of the forest, and so 897 01:10:23.560 --> 01:10:30.800 you roll the die for the direction of the the wind, and then you 898 01:10:30.880 --> 01:10:33.439 have different actions you can take. So North, lets you, i think, 899 01:10:33.479 --> 01:10:36.520 put a fire token out, or one of them, lets you change 900 01:10:36.520 --> 01:10:40.159 the direction of the wind one of them. Anyway, so it's it's way 901 01:10:40.159 --> 01:10:45.199 fun. It was a lot of fun and so but it's relatively simple board 902 01:10:45.199 --> 01:10:49.479 game. Geek waits at one point seventy nine, which means very easy casual 903 01:10:49.520 --> 01:10:54.600 game. So I'm I'm digging that that that's it was. It was a 904 01:10:54.640 --> 01:10:58.039 ton of fun, So I'm gonna pick that. If you're in Utah, 905 01:10:58.119 --> 01:11:00.439 I think it might be sold out, but if it's not, I'm going 906 01:11:00.439 --> 01:11:04.680 to salt Con in a couple of weeks, three weeks, and salt Con 907 01:11:04.800 --> 01:11:11.399 is a board game convention in Davis County, so just north of Salt Lake. 908 01:11:12.920 --> 01:11:14.880 So if you want to come play games with me, let me know 909 01:11:14.920 --> 01:11:17.760 you're going, and that'll be fun. I'm heading up with one of these 910 01:11:18.119 --> 01:11:23.800 buddies of mine and anyway, fun, fun, fun. So excited about 911 01:11:23.840 --> 01:11:27.800 that. I also have the Ruby Dev Summit videos up. If you go 912 01:11:27.840 --> 01:11:30.000 to rubydevsummit dot com and you put your email address in, you can get 913 01:11:30.000 --> 01:11:35.600 access to the videos for twenty four hours. They incidentally have also been going 914 01:11:35.600 --> 01:11:40.720 out on the Ruby Rogues feed this week, but I plan on taking them 915 01:11:40.760 --> 01:11:43.760 back off of the feed, and so if you didn't get them, you 916 01:11:43.760 --> 01:11:47.239 didn't get them, and I'm sorry, but just go to the web page 917 01:11:47.279 --> 01:11:54.640 and we'll hook you up. Just trying to think what else. I mean, 918 01:11:54.800 --> 01:11:59.039 mostly just been heads down working on rails clips and Ruby bits and so 919 01:11:59.119 --> 01:12:01.079 if you're looking to learn more Ruby your rail stuff, go check out the 920 01:12:01.119 --> 01:12:05.640 videos there and I'll wrap it there. Samuel, what are your picks? 921 01:12:08.039 --> 01:12:12.279 Sorry, you're going to explain this concept to me. It's okay, So 922 01:12:12.520 --> 01:12:15.279 every show we just picked stuff that we like, so the stuff you're enjoying. 923 01:12:15.319 --> 01:12:18.640 So yeah, so it's a TV show, So another one I could 924 01:12:18.640 --> 01:12:26.159 pick. My wife and I watched once on Netflix, right, that was 925 01:12:26.159 --> 01:12:30.720 a fun series, board games, tech stuff whatever. I've been watching Futurama. 926 01:12:32.359 --> 01:12:38.079 I'm really happy they revived it show. It's slious, such a great 927 01:12:38.199 --> 01:12:44.119 job. Yeah, I suppose what's great about Futurama At least I don't know 928 01:12:44.119 --> 01:12:47.319 about the latest version, you know, the latest season it's not too bad. 929 01:12:48.199 --> 01:12:53.399 But the early ones there all apparently had more years of PhDs in the 930 01:12:53.479 --> 01:12:58.640 room than then you could be alive for one lifetime, you know, and 931 01:12:58.720 --> 01:13:01.680 the stories were always really know the characters and the stories were really hilarious. 932 01:13:03.000 --> 01:13:11.279 So yeah, future Ama, go watch it. They won't be disappointed. 933 01:13:13.079 --> 01:13:15.560 That's the one that's always been on my list, but I never quite get 934 01:13:15.600 --> 01:13:18.479 around you haven't watched it. Okay, I've watched it with my kids a 935 01:13:18.520 --> 01:13:24.000 couple of times, and it's a huge hit. Some of them you have 936 01:13:24.039 --> 01:13:28.000 to be like, maybe we should watch this anymore. Yeah, some of 937 01:13:28.039 --> 01:13:30.920 it looks like some of the humor might be a little bit off color. 938 01:13:31.520 --> 01:13:39.399 Yeah, it looks pretty There's one episode where they actually published a mathematics paper 939 01:13:39.920 --> 01:13:45.279 because they solved the mathematics problem. It was like a professor fans were invented 940 01:13:45.319 --> 01:13:49.399 like a brain switch, like a head switching machine, but the point was, 941 01:13:49.439 --> 01:13:55.239 once you'd switched with one person, you couldn't switch back, and they 942 01:13:55.239 --> 01:14:01.439 actually had to invent a new mathematical theory to show that it was possible to 943 01:14:01.439 --> 01:14:05.560 switch back, and they published it as part of the show. I think, 944 01:14:06.199 --> 01:14:12.159 yeah, it's really funny, very cool. All right, well thanks 945 01:14:12.159 --> 01:14:15.399 for coming Samuel. This was a ton of fun, such interesting stuff, 946 01:14:16.000 --> 01:14:19.199 fantas. It was a pleasure to be here and to ask me a questions. 947 01:14:20.000 --> 01:14:24.279 Yeah, all right, Well we'll wrap it up here until next time. Max out