Podcast appearances and mentions of Ryan Dahl

Bryan Cantrill is the co-founder and CTO of Oxide Computer Company. We discuss why the biggest cloud providers don't use off the shelf hardware, how scaling data centers at samsung's scale exposed problems with hard drive firmware, how the values of NodeJS are in conflict with robust systems, choosing Rust, and the benefits of Oxide Computer's rack scale approach. This is an extended version of an interview posted on Software Engineering Radio. Related links Oxide Computer Oxide and Friends Illumos Platform as a Reflection of Values RFD 26 bhyve CockroachDB Heterogeneous Computing with Raja Koduri Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today I am talking to Bryan Cantrill. He's the co-founder and CTO of Oxide computer company, and he was previously the CTO of Joyent and he also co-authored the DTrace Tracing framework while he was at Sun Microsystems. [00:00:14] Jeremy: Bryan, welcome to Software Engineering radio. [00:00:17] Bryan: Uh, awesome. Thanks for having me. It's great to be here. [00:00:20] Jeremy: You're the CTO of a company that makes computers. But I think before we get into that, a lot of people who built software, now that the actual computer is abstracted away, they're using AWS or they're using some kind of cloud service. So I thought we could start by talking about, data centers. [00:00:41] Jeremy: 'cause you were. Previously working at Joyent, and I believe you got bought by Samsung and you've previously talked about how you had to figure out, how do I run things at Samsung's scale. So how, how, how was your experience with that? What, what were the challenges there? Samsung scale and migrating off the cloud [00:01:01] Bryan: Yeah, I mean, so at Joyent, and so Joyent was a cloud computing pioneer. Uh, we competed with the likes of AWS and then later GCP and Azure. Uh, and we, I mean, we were operating at a scale, right? We had a bunch of machines, a bunch of dcs, but ultimately we know we were a VC backed company and, you know, a small company by the standards of, certainly by Samsung standards. [00:01:25] Bryan: And so when, when Samsung bought the company, I mean, the reason by the way that Samsung bought Joyent is Samsung's. Cloud Bill was, uh, let's just say it was extremely large. They were spending an enormous amount of money every year on, on the public cloud. And they realized that in order to secure their fate economically, they had to be running on their own infrastructure. [00:01:51] Bryan: It did not make sense. And there's not, was not really a product that Samsung could go buy that would give them that on-prem cloud. Uh, I mean in that, in that regard, like the state of the market was really no different. And so they went looking for a company, uh, and bought, bought Joyent. And when we were on the inside of Samsung. [00:02:11] Bryan: That we learned about Samsung scale. And Samsung loves to talk about Samsung scale. And I gotta tell you, it is more than just chest thumping. Like Samsung Scale really is, I mean, just the, the sheer, the number of devices, the number of customers, just this absolute size. they really wanted to take us out to, to levels of scale, certainly that we had not seen. [00:02:31] Bryan: The reason for buying Joyent was to be able to stand up on their own infrastructure so that we were gonna go buy, we did go buy a bunch of hardware. Problems with server hardware at scale [00:02:40] Bryan: And I remember just thinking, God, I hope Dell is somehow magically better. I hope the problems that we have seen in the small, we just. You know, I just remember hoping and hope is hope. It was of course, a terrible strategy and it was a terrible strategy here too. Uh, and the we that the problems that we saw at the large were, and when you scale out the problems that you see kind of once or twice, you now see all the time and they become absolutely debilitating. [00:03:12] Bryan: And we saw a whole series of really debilitating problems. I mean, many ways, like comically debilitating, uh, in terms of, of showing just how bad the state-of-the-art. Yes. And we had, I mean, it should be said, we had great software and great software expertise, um, and we were controlling our own system software. [00:03:35] Bryan: But even controlling your own system software, your own host OS, your own control plane, which is what we had at Joyent, ultimately, you're pretty limited. You go, I mean, you got the problems that you can obviously solve, the ones that are in your own software, but the problems that are beneath you, the, the problems that are in the hardware platform, the problems that are in the componentry beneath you become the problems that are in the firmware. IO latency due to hard drive firmware [00:04:00] Bryan: Those problems become unresolvable and they are deeply, deeply frustrating. Um, and we just saw a bunch of 'em again, they were. Comical in retrospect, and I'll give you like a, a couple of concrete examples just to give, give you an idea of what kinda what you're looking at. one of the, our data centers had really pathological IO latency. [00:04:23] Bryan: we had a very, uh, database heavy workload. And this was kind of right at the period where you were still deploying on rotating media on hard drives. So this is like, so. An all flash buy did not make economic sense when we did this in, in 2016. This probably, it'd be interesting to know like when was the, the kind of the last time that that actual hard drives made sense? [00:04:50] Bryan: 'cause I feel this was close to it. So we had a, a bunch of, of a pathological IO problems, but we had one data center in which the outliers were actually quite a bit worse and there was so much going on in that system. It took us a long time to figure out like why. And because when, when you, when you're io when you're seeing worse io I mean you're naturally, you wanna understand like what's the workload doing? [00:05:14] Bryan: You're trying to take a first principles approach. What's the workload doing? So this is a very intensive database workload to support the, the object storage system that we had built called Manta. And that the, the metadata tier was stored and uh, was we were using Postgres for that. And that was just getting absolutely slaughtered. [00:05:34] Bryan: Um, and ultimately very IO bound with these kind of pathological IO latencies. Uh, and as we, you know, trying to like peel away the layers to figure out what was going on. And I finally had this thing. So it's like, okay, we are seeing at the, at the device layer, at the at, at the disc layer, we are seeing pathological outliers in this data center that we're not seeing anywhere else. [00:06:00] Bryan: And that does not make any sense. And the thought occurred to me. I'm like, well, maybe we are. Do we have like different. Different rev of firmware on our HGST drives, HGST. Now part of WD Western Digital were the drives that we had everywhere. And, um, so maybe we had a different, maybe I had a firmware bug. [00:06:20] Bryan: I, this would not be the first time in my life at all that I would have a drive firmware issue. Uh, and I went to go pull the firmware, rev, and I'm like, Toshiba makes hard drives? So we had, I mean. I had no idea that Toshiba even made hard drives, let alone that they were our, they were in our data center. [00:06:38] Bryan: I'm like, what is this? And as it turns out, and this is, you know, part of the, the challenge when you don't have an integrated system, which not to pick on them, but Dell doesn't, and what Dell would routinely put just sub make substitutes, and they make substitutes that they, you know, it's kind of like you're going to like, I don't know, Instacart or whatever, and they're out of the thing that you want. [00:07:03] Bryan: So, you know, you're, someone makes a substitute and like sometimes that's okay, but it's really not okay in a data center. And you really want to develop and validate a, an end-to-end integrated system. And in this case, like Toshiba doesn't, I mean, Toshiba does make hard drives, but they are a, or the data they did, uh, they basically were, uh, not competitive and they were not competitive in part for the reasons that we were discovering. [00:07:29] Bryan: They had really serious firmware issues. So the, these were drives that would just simply stop a, a stop acknowledging any reads from the order of 2,700 milliseconds. Long time, 2.7 seconds. Um. And that was a, it was a drive firmware issue, but it was highlighted like a much deeper issue, which was the simple lack of control that we had over our own destiny. [00:07:53] Bryan: Um, and it's an, it's, it's an example among many where Dell is making a decision. That lowers the cost of what they are providing you marginally, but it is then giving you a system that they shouldn't have any confidence in because it's not one that they've actually designed and they leave it to the customer, the end user, to make these discoveries. [00:08:18] Bryan: And these things happen up and down the stack. And for every, for whether it's, and, and not just to pick on Dell because it's, it's true for HPE, it's true for super micro, uh, it's true for your switch vendors. It's, it's true for storage vendors where the, the, the, the one that is left actually integrating these things and trying to make the the whole thing work is the end user sitting in their data center. AWS / Google are not buying off the shelf hardware but you can't use it [00:08:42] Bryan: There's not a product that they can buy that gives them elastic infrastructure, a cloud in their own DC The, the product that you buy is the public cloud. Like when you go in the public cloud, you don't worry about the stuff because that it's, it's AWS's issue or it's GCP's issue. And they are the ones that get this to ground. [00:09:02] Bryan: And they, and this was kind of, you know, the eye-opening moment. Not a surprise. Uh, they are not Dell customers. They're not HPE customers. They're not super micro customers. They have designed their own machines. And to varying degrees, depending on which one you're looking at. But they've taken the clean sheet of paper and the frustration that we had kind of at Joyent and beginning to wonder and then Samsung and kind of wondering what was next, uh, is that, that what they built was not available for purchase in the data center. [00:09:35] Bryan: You could only rent it in the public cloud. And our big belief is that public cloud computing is a really important revolution in infrastructure. Doesn't feel like a different, a deep thought, but cloud computing is a really important revolution. It shouldn't only be available to rent. You should be able to actually buy it. [00:09:53] Bryan: And there are a bunch of reasons for doing that. Uh, one in the one we we saw at Samsung is economics, which I think is still the dominant reason where it just does not make sense to rent all of your compute in perpetuity. But there are other reasons too. There's security, there's risk management, there's latency. [00:10:07] Bryan: There are a bunch of reasons why one might wanna to own one's own infrastructure. But, uh, that was very much the, the, so the, the genesis for oxide was coming out of this very painful experience and a painful experience that, because, I mean, a long answer to your question about like what was it like to be at Samsung scale? [00:10:27] Bryan: Those are the kinds of things that we, I mean, in our other data centers, we didn't have Toshiba drives. We only had the HDSC drives, but it's only when you get to this larger scale that you begin to see some of these pathologies. But these pathologies then are really debilitating in terms of those who are trying to develop a service on top of them. [00:10:45] Bryan: So it was, it was very educational in, in that regard. And you're very grateful for the experience at Samsung in terms of opening our eyes to the challenge of running at that kind of scale. [00:10:57] Jeremy: Yeah, because I, I think as software engineers, a lot of times we, we treat the hardware as a, as a given where, [00:11:08] Bryan: Yeah. [00:11:08] Bryan: Yeah. There's software in chard drives [00:11:09] Jeremy: It sounds like in, in this case, I mean, maybe the issue is not so much that. Dell or HP as a company doesn't own every single piece that they're providing you, but rather the fact that they're swapping pieces in and out without advertising them, and then when it becomes a problem, they're not necessarily willing to, to deal with the, the consequences of that. [00:11:34] Bryan: They just don't know. I mean, I think they just genuinely don't know. I mean, I think that they, it's not like they're making a deliberate decision to kind of ship garbage. It's just that they are making, I mean, I think it's exactly what you said about like, not thinking about the hardware. It's like, what's a hard drive? [00:11:47] Bryan: Like what's it, I mean, it's a hard drive. It's got the same specs as this other hard drive and Intel. You know, it's a little bit cheaper, so why not? It's like, well, like there's some reasons why not, and one of the reasons why not is like, uh, even a hard drive, whether it's rotating media or, or flash, like that's not just hardware. [00:12:05] Bryan: There's software in there. And that the software's like not the same. I mean, there are components where it's like, there's actually, whether, you know, if, if you're looking at like a resistor or a capacitor or something like this Yeah. If you've got two, two parts that are within the same tolerance. Yeah. [00:12:19] Bryan: Like sure. Maybe, although even the EEs I think would be, would be, uh, objecting that a little bit. But the, the, the more complicated you get, and certainly once you get to the, the, the, the kind of the hardware that we think of like a, a, a microprocessor, a a network interface card, a a, a hard driver, an NVME drive. [00:12:38] Bryan: Those things are super complicated and there's a whole bunch of software inside of those things, the firmware, and that's the stuff that, that you can't, I mean, you say that software engineers don't think about that. It's like you, no one can really think about that because it's proprietary that's kinda welded shut and you've got this abstraction into it. [00:12:55] Bryan: But the, the way that thing operates is very core to how the thing in aggregate will behave. And I think that you, the, the kind of, the, the fundamental difference between Oxide's approach and the approach that you get at a Dell HP Supermicro, wherever, is really thinking holistically in terms of hardware and software together in a system that, that ultimately delivers cloud computing to a user. [00:13:22] Bryan: And there's a lot of software at many, many, many, many different layers. And it's very important to think about, about that software and that hardware holistically as a single system. [00:13:34] Jeremy: And during that time at Joyent, when you experienced some of these issues, was it more of a case of you didn't have enough servers experiencing this? So if it would happen, you might say like, well, this one's not working, so maybe we'll just replace the hardware. What, what was the thought process when you were working at that smaller scale and, and how did these issues affect you? UEFI / Baseboard Management Controller [00:13:58] Bryan: Yeah, at the smaller scale, you, uh, you see fewer of them, right? You just see it's like, okay, we, you know, what you might see is like, that's weird. We kinda saw this in one machine versus seeing it in a hundred or a thousand or 10,000. Um, so you just, you just see them, uh, less frequently as a result, they are less debilitating. [00:14:16] Bryan: Um, I, I think that it's, when you go to that larger scale, those things that become, that were unusual now become routine and they become debilitating. Um, so it, it really is in many regards a function of scale. Uh, and then I think it was also, you know, it was a little bit dispiriting that kind of the substrate we were building on really had not improved. [00:14:39] Bryan: Um, and if you look at, you know, the, if you buy a computer server, buy an x86 server. There is a very low layer of firmware, the BIOS, the basic input output system, the UEFI BIOS, and this is like an abstraction layer that has, has existed since the eighties and hasn't really meaningfully improved. Um, the, the kind of the transition to UEFI happened with, I mean, I, I ironically with Itanium, um, you know, two decades ago. [00:15:08] Bryan: but beyond that, like this low layer, this lowest layer of platform enablement software is really only impeding the operability of the system. Um, you look at the baseboard management controller, which is the kind of the computer within the computer, there is a, uh, there is an element in the machine that needs to handle environmentals, that needs to handle, uh, operate the fans and so on. [00:15:31] Bryan: Uh, and that traditionally has this, the space board management controller, and that architecturally just hasn't improved in the last two decades. And, you know, that's, it's a proprietary piece of silicon. Generally from a company that no one's ever heard of called a Speed, uh, which has to be, is written all on caps, so I guess it needs to be screamed. [00:15:50] Bryan: Um, a speed has a proprietary part that has a, there is a root password infamously there, is there, the root password is encoded effectively in silicon. So, uh, which is just, and for, um, anyone who kind of goes deep into these things, like, oh my God, are you kidding me? Um, when we first started oxide, the wifi password was a fraction of the a speed root password for the bmc. [00:16:16] Bryan: It's kinda like a little, little BMC humor. Um, but those things, it was just dispiriting that, that the, the state-of-the-art was still basically personal computers running in the data center. Um, and that's part of what, what was the motivation for doing something new? [00:16:32] Jeremy: And for the people using these systems, whether it's the baseboard management controller or it's the The BIOS or UF UEFI component, what are the actual problems that people are seeing seen? Security vulnerabilities and poor practices in the BMC [00:16:51] Bryan: Oh man, I, the, you are going to have like some fraction of your listeners, maybe a big fraction where like, yeah, like what are the problems? That's a good question. And then you're gonna have the people that actually deal with these things who are, did like their heads already hit the desk being like, what are the problems? [00:17:06] Bryan: Like what are the non problems? Like what, what works? Actually, that's like a shorter answer. Um, I mean, there are so many problems and a lot of it is just like, I mean, there are problems just architecturally these things are just so, I mean, and you could, they're the problems spread to the horizon, so you can kind of start wherever you want. [00:17:24] Bryan: But I mean, as like, as a really concrete example. Okay, so the, the BMCs that, that the computer within the computer that needs to be on its own network. So you now have like not one network, you got two networks that, and that network, by the way, it, that's the network that you're gonna log into to like reset the machine when it's otherwise unresponsive. [00:17:44] Bryan: So that going into the BMC, you can are, you're able to control the entire machine. Well it's like, alright, so now I've got a second net network that I need to manage. What is running on the BMC? Well, it's running some. Ancient, ancient version of Linux it that you got. It's like, well how do I, how do I patch that? [00:18:02] Bryan: How do I like manage the vulnerabilities with that? Because if someone is able to root your BMC, they control the system. So it's like, this is not you've, and now you've gotta go deal with all of the operational hair around that. How do you upgrade that system updating the BMC? I mean, it's like you've got this like second shadow bad infrastructure that you have to go manage. [00:18:23] Bryan: Generally not open source. There's something called open BMC, um, which, um, you people use to varying degrees, but you're generally stuck with the proprietary BMC, so you're generally stuck with, with iLO from HPE or iDRAC from Dell or, or, uh, the, uh, su super micros, BMC, that H-P-B-M-C, and you are, uh, it is just excruciating pain. [00:18:49] Bryan: Um, and that this is assuming that by the way, that everything is behaving correctly. The, the problem is that these things often don't behave correctly, and then the consequence of them not behaving correctly. It's really dire because it's at that lowest layer of the system. So, I mean, I'll give you a concrete example. [00:19:07] Bryan: a customer of theirs reported to me, so I won't disclose the vendor, but let's just say that a well-known vendor had an issue with their, their temperature sensors were broken. Um, and the thing would always read basically the wrong value. So it was the BMC that had to like, invent its own ki a different kind of thermal control loop. [00:19:28] Bryan: And it would index on the, on the, the, the, the actual inrush current. It would, they would look at that at the current that's going into the CPU to adjust the fan speed. That's a great example of something like that's a, that's an interesting idea. That doesn't work. 'cause that's actually not the temperature. [00:19:45] Bryan: So like that software would crank the fans whenever you had an inrush of current and this customer had a workload that would spike the current and by it, when it would spike the current, the, the, the fans would kick up and then they would slowly degrade over time. Well, this workload was spiking the current faster than the fans would degrade, but not fast enough to actually heat up the part. [00:20:08] Bryan: And ultimately over a very long time, in a very painful investigation, it's customer determined that like my fans are cranked in my data center for no reason. We're blowing cold air. And it's like that, this is on the order of like a hundred watts, a server of, of energy that you shouldn't be spending and like that ultimately what that go comes down to this kind of broken software hardware interface at the lowest layer that has real meaningful consequence, uh, in terms of hundreds of kilowatts, um, across a data center. So this stuff has, has very, very, very real consequence and it's such a shadowy world. Part of the reason that, that your listeners that have dealt with this, that our heads will hit the desk is because it is really aggravating to deal with problems with this layer. [00:21:01] Bryan: You, you feel powerless. You don't control or really see the software that's on them. It's generally proprietary. You are relying on your vendor. Your vendor is telling you that like, boy, I don't know. You're the only customer seeing this. I mean, the number of times I have heard that for, and I, I have pledged that we're, we're not gonna say that at oxide because it's such an unaskable thing to say like, you're the only customer saying this. [00:21:25] Bryan: It's like, it feels like, are you blaming me for my problem? Feels like you're blaming me for my problem? Um, and what you begin to realize is that to a degree, these folks are speaking their own truth because the, the folks that are running at real scale at Hyperscale, those folks aren't Dell, HP super micro customers. [00:21:46] Bryan: They're actually, they've done their own thing. So it's like, yeah, Dell's not seeing that problem, um, because they're not running at the same scale. Um, but when you do run, you only have to run at modest scale before these things just become. Overwhelming in terms of the, the headwind that they present to people that wanna deploy infrastructure. The problem is felt with just a few racks [00:22:05] Jeremy: Yeah, so maybe to help people get some perspective at, at what point do you think that people start noticing or start feeling these problems? Because I imagine that if you're just have a few racks or [00:22:22] Bryan: do you have a couple racks or the, or do you wonder or just wondering because No, no, no. I would think, I think anyone who deploys any number of servers, especially now, especially if your experience is only in the cloud, you're gonna be like, what the hell is this? I mean, just again, just to get this thing working at all. [00:22:39] Bryan: It is so it, it's so hairy and so congealed, right? It's not designed. Um, and it, it, it, it's accreted it and it's so obviously accreted that you are, I mean, nobody who is setting up a rack of servers is gonna think to themselves like, yes, this is the right way to go do it. This all makes sense because it's, it's just not, it, I, it feels like the kit, I mean, kit car's almost too generous because it implies that there's like a set of plans to work to in the end. [00:23:08] Bryan: Uh, I mean, it, it, it's a bag of bolts. It's a bunch of parts that you're putting together. And so even at the smallest scales, that stuff is painful. Just architecturally, it's painful at the small scale then, but at least you can get it working. I think the stuff that then becomes debilitating at larger scale are the things that are, are worse than just like, I can't, like this thing is a mess to get working. [00:23:31] Bryan: It's like the, the, the fan issue that, um, where you are now seeing this over, you know, hundreds of machines or thousands of machines. Um, so I, it is painful at more or less all levels of scale. There's, there is no level at which the, the, the pc, which is really what this is, this is a, the, the personal computer architecture from the 1980s and there is really no level of scale where that's the right unit. Running elastic infrastructure is the hardware but also, hypervisor, distributed database, api, etc [00:23:57] Bryan: I mean, where that's the right thing to go deploy, especially if what you are trying to run. Is elastic infrastructure, a cloud. Because the other thing is like we, we've kinda been talking a lot about that hardware layer. Like hardware is, is just the start. Like you actually gotta go put software on that and actually run that as elastic infrastructure. [00:24:16] Bryan: So you need a hypervisor. Yes. But you need a lot more than that. You, you need to actually, you, you need a distributed database, you need web endpoints. You need, you need a CLI, you need all the stuff that you need to actually go run an actual service of compute or networking or storage. I mean, and for, for compute, even for compute, there's a ton of work to be done. [00:24:39] Bryan: And compute is by far, I would say the simplest of the, of the three. When you look at like networks, network services, storage services, there's a whole bunch of stuff that you need to go build in terms of distributed systems to actually offer that as a cloud. So it, I mean, it is painful at more or less every LE level if you are trying to deploy cloud computing on. What's a control plane? [00:25:00] Jeremy: And for someone who doesn't have experience building or working with this type of infrastructure, when you talk about a control plane, what, what does that do in the context of this system? [00:25:16] Bryan: So control plane is the thing that is, that is everything between your API request and that infrastructure actually being acted upon. So you go say, Hey, I, I want a provision, a vm. Okay, great. We've got a whole bunch of things we're gonna provision with that. We're gonna provision a vm, we're gonna get some storage that's gonna go along with that, that's got a network storage service that's gonna come out of, uh, we've got a virtual network that we're gonna either create or attach to. [00:25:39] Bryan: We've got a, a whole bunch of things we need to go do for that. For all of these things, there are metadata components that need, we need to keep track of this thing that, beyond the actual infrastructure that we create. And then we need to go actually, like act on the actual compute elements, the hostos, what have you, the switches, what have you, and actually go. [00:25:56] Bryan: Create these underlying things and then connect them. And there's of course, the challenge of just getting that working is a big challenge. Um, but getting that working robustly, getting that working is, you know, when you go to provision of vm, um, the, all the, the, the steps that need to happen and what happens if one of those steps fails along the way? [00:26:17] Bryan: What happens if, you know, one thing we're very mindful of is these kind of, you get these long tails of like, why, you know, generally our VM provisioning happened within this time, but we get these long tails where it takes much longer. What's going on? What, where in this process are we, are we actually spending time? [00:26:33] Bryan: Uh, and there's a whole lot of complexity that you need to go deal with that. There's a lot of complexity that you need to go deal with this effectively, this workflow that's gonna go create these things and manage them. Um, we use a, a pattern that we call, that are called sagas, actually is a, is a database pattern from the eighties. [00:26:51] Bryan: Uh, Katie McCaffrey is a, is a database reCrcher who, who, uh, I, I think, uh, reintroduce the idea of, of sagas, um, in the last kind of decade. Um, and this is something that we picked up, um, and I've done a lot of really interesting things with, um, to allow for, to this kind of, these workflows to be, to be managed and done so robustly in a way that you can restart them and so on. [00:27:16] Bryan: Uh, and then you guys, you get this whole distributed system that can do all this. That whole distributed system, that itself needs to be reliable and available. So if you, you know, you need to be able to, what happens if you, if you pull a sled or if a sled fails, how does the system deal with that? [00:27:33] Bryan: How does the system deal with getting an another sled added to the system? Like how do you actually grow this distributed system? And then how do you update it? How do you actually go from one version to the next? And all of that has to happen across an air gap where this is gonna run as part of the computer. [00:27:49] Bryan: So there are, it, it is fractally complicated. There, there is a lot of complexity here in, in software, in the software system and all of that. We kind of, we call the control plane. Um, and it, this is the what exists at AWS at GCP, at Azure. When you are hitting an endpoint that's provisioning an EC2 instance for you. [00:28:10] Bryan: There is an AWS control plane that is, is doing all of this and has, uh, some of these similar aspects and certainly some of these similar challenges. Are vSphere / Proxmox / Hyper-V in the same category? [00:28:20] Jeremy: And for people who have run their own servers with something like say VMware or Hyper V or Proxmox, are those in the same category? [00:28:32] Bryan: Yeah, I mean a little bit. I mean, it kind of like vSphere Yes. Via VMware. No. So it's like you, uh, VMware ESX is, is kind of a key building block upon which you can build something that is a more meaningful distributed system. When it's just like a machine that you're provisioning VMs on, it's like, okay, well that's actually, you as the human might be the control plane. [00:28:52] Bryan: Like, that's, that, that's, that's a much easier problem. Um, but when you've got, you know, tens, hundreds, thousands of machines, you need to do it robustly. You need something to coordinate that activity and you know, you need to pick which sled you land on. You need to be able to move these things. You need to be able to update that whole system. [00:29:06] Bryan: That's when you're getting into a control plane. So, you know, some of these things have kind of edged into a control plane, certainly VMware. Um, now Broadcom, um, has delivered something that's kind of cloudish. Um, I think that for folks that are truly born on the cloud, it, it still feels somewhat, uh, like you're going backwards in time when you, when you look at these kind of on-prem offerings. [00:29:29] Bryan: Um, but, but it, it, it's got these aspects to it for sure. Um, and I think that we're, um, some of these other things when you're just looking at KVM or just looks looking at Proxmox you kind of need to, to connect it to other broader things to turn it into something that really looks like manageable infrastructure. [00:29:47] Bryan: And then many of those projects are really, they're either proprietary projects, uh, proprietary products like vSphere, um, or you are really dealing with open source projects that are. Not necessarily aimed at the same level of scale. Um, you know, you look at a, again, Proxmox or, uh, um, you'll get an OpenStack. [00:30:05] Bryan: Um, and you know, OpenStack is just a lot of things, right? I mean, OpenStack has got so many, the OpenStack was kind of a, a free for all, for every infrastructure vendor. Um, and I, you know, there was a time people were like, don't you, aren't you worried about all these companies together that, you know, are coming together for OpenStack? [00:30:24] Bryan: I'm like, haven't you ever worked for like a company? Like, companies don't get along. By the way, it's like having multiple companies work together on a thing that's bad news, not good news. And I think, you know, one of the things that OpenStack has definitely struggled with, kind of with what, actually the, the, there's so many different kind of vendor elements in there that it's, it's very much not a product, it's a project that you're trying to run. [00:30:47] Bryan: But that's, but that very much is in, I mean, that's, that's similar certainly in spirit. [00:30:53] Jeremy: And so I think this is kind of like you're alluding to earlier, the piece that allows you to allocate, compute, storage, manage networking, gives you that experience of I can go to a web console or I can use an API and I can spin up machines, get them all connected. At the end of the day, the control plane. Is allowing you to do that in hopefully a user-friendly way. [00:31:21] Bryan: That's right. Yep. And in the, I mean, in order to do that in a modern way, it's not just like a user-friendly way. You really need to have a CLI and a web UI and an API. Those all need to be drawn from the same kind of single ground truth. Like you don't wanna have any of those be an afterthought for the other. [00:31:39] Bryan: You wanna have the same way of generating all of those different endpoints and, and entries into the system. Building a control plane now has better tools (Rust, CockroachDB) [00:31:46] Jeremy: And if you take your time at Joyent as an example. What kind of tools existed for that versus how much did you have to build in-house for as far as the hypervisor and managing the compute and all that? [00:32:02] Bryan: Yeah, so we built more or less everything in house. I mean, what you have is, um, and I think, you know, over time we've gotten slightly better tools. Um, I think, and, and maybe it's a little bit easier to talk about the, kind of the tools we started at Oxide because we kind of started with a, with a clean sheet of paper at oxide. [00:32:16] Bryan: We wanted to, knew we wanted to go build a control plane, but we were able to kind of go revisit some of the components. So actually, and maybe I'll, I'll talk about some of those changes. So when we, at, For example, at Joyent, when we were building a cloud at Joyent, there wasn't really a good distributed database. [00:32:34] Bryan: Um, so we were using Postgres as our database for metadata and there were a lot of challenges. And Postgres is not a distributed database. It's running. With a primary secondary architecture, and there's a bunch of issues there, many of which we discovered the hard way. Um, when we were coming to oxide, you have much better options to pick from in terms of distributed databases. [00:32:57] Bryan: You know, we, there was a period that now seems maybe potentially brief in hindsight, but of a really high quality open source distributed databases. So there were really some good ones to, to pick from. Um, we, we built on CockroachDB on CRDB. Um, so that was a really important component. That we had at oxide that we didn't have at Joyent. [00:33:19] Bryan: Um, so we were, I wouldn't say we were rolling our own distributed database, we were just using Postgres and uh, and, and dealing with an enormous amount of pain there in terms of the surround. Um, on top of that, and, and, you know, a, a control plane is much more than a database, obviously. Uh, and you've gotta deal with, uh, there's a whole bunch of software that you need to go, right. [00:33:40] Bryan: Um, to be able to, to transform these kind of API requests into something that is reliable infrastructure, right? And there, there's a lot to that. Uh, especially when networking gets in the mix, when storage gets in the mix, uh, there are a whole bunch of like complicated steps that need to be done, um, at Joyent. [00:33:59] Bryan: Um, we, in part because of the history of the company and like, look. This, this just is not gonna sound good, but it just is what it is and I'm just gonna own it. We did it all in Node, um, at Joyent, which I, I, I know it sounds really right now, just sounds like, well, you, you built it with Tinker Toys. You Okay. [00:34:18] Bryan: Uh, did, did you think it was, you built the skyscraper with Tinker Toys? Uh, it's like, well, okay. We actually, we had greater aspirations for the Tinker Toys once upon a time, and it was better than, you know, than Twisted Python and Event Machine from Ruby, and we weren't gonna do it in Java. All right. [00:34:32] Bryan: So, but let's just say that that experiment, uh, that experiment did ultimately end in a predictable fashion. Um, and, uh, we, we decided that maybe Node was not gonna be the best decision long term. Um, Joyent was the company behind node js. Uh, back in the day, Ryan Dahl worked for Joyent. Uh, and then, uh, then we, we, we. [00:34:53] Bryan: Uh, landed that in a foundation in about, uh, what, 2015, something like that. Um, and began to consider our world beyond, uh, beyond Node. Rust at Oxide [00:35:04] Bryan: A big tool that we had in the arsenal when we started Oxide is Rust. Um, and so indeed the name of the company is, is a tip of the hat to the language that we were pretty sure we were gonna be building a lot of stuff in. [00:35:16] Bryan: Namely Rust. And, uh, rust is, uh, has been huge for us, a very important revolution in programming languages. you know, there, there, there have been different people kind of coming in at different times and I kinda came to Rust in what I, I think is like this big kind of second expansion of rust in 2018 when a lot of technologists were think, uh, sick of Node and also sick of Go. [00:35:43] Bryan: And, uh, also sick of C++. And wondering is there gonna be something that gives me the, the, the performance, of that I get outta C. The, the robustness that I can get out of a C program but is is often difficult to achieve. but can I get that with kind of some, some of the velocity of development, although I hate that term, some of the speed of development that you get out of a more interpreted language. [00:36:08] Bryan: Um, and then by the way, can I actually have types, I think types would be a good idea? Uh, and rust obviously hits the sweet spot of all of that. Um, it has been absolutely huge for us. I mean, we knew when we started the company again, oxide, uh, we were gonna be using rust in, in quite a, quite a. Few places, but we weren't doing it by fiat. [00:36:27] Bryan: Um, we wanted to actually make sure we're making the right decision, um, at, at every different, at every layer. Uh, I think what has been surprising is the sheer number of layers at which we use rust in terms of, we've done our own embedded firmware in rust. We've done, um, in, in the host operating system, which is still largely in C, but very big components are in rust. [00:36:47] Bryan: The hypervisor Propolis is all in rust. Uh, and then of course the control plane, that distributed system on that is all in rust. So that was a very important thing that we very much did not need to build ourselves. We were able to really leverage, uh, a terrific community. Um. We were able to use, uh, and we've done this at Joyent as well, but at Oxide, we've used Illumos as a hostos component, which, uh, our variant is called Helios. [00:37:11] Bryan: Um, we've used, uh, bhyve um, as a, as as that kind of internal hypervisor component. we've made use of a bunch of different open source components to build this thing, um, which has been really, really important for us. Uh, and open source components that didn't exist even like five years prior. [00:37:28] Bryan: That's part of why we felt that 2019 was the right time to start the company. And so we started Oxide. The problems building a control plane in Node [00:37:34] Jeremy: You had mentioned that at Joyent, you had tried to build this in, in Node. What were the, what were the, the issues or the, the challenges that you had doing that? [00:37:46] Bryan: Oh boy. Yeah. again, we, I kind of had higher hopes in 2010, I would say. When we, we set on this, um, the, the, the problem that we had just writ large, um. JavaScript is really designed to allow as many people on earth to write a program as possible, which is good. I mean, I, I, that's a, that's a laudable goal. [00:38:09] Bryan: That is the goal ultimately of such as it is of JavaScript. It's actually hard to know what the goal of JavaScript is, unfortunately, because Brendan Ike never actually wrote a book. so that there is not a canonical, you've got kind of Doug Crockford and other people who've written things on JavaScript, but it's hard to know kind of what the original intent of JavaScript is. [00:38:27] Bryan: The name doesn't even express original intent, right? It was called Live Script, and it was kind of renamed to JavaScript during the Java Frenzy of the late nineties. A name that makes no sense. There is no Java in JavaScript. that is kind of, I think, revealing to kind of the, uh, the unprincipled mess that is JavaScript. [00:38:47] Bryan: It, it, it's very pragmatic at some level, um, and allows anyone to, it makes it very easy to write software. The problem is it's much more difficult to write really rigorous software. So, uh, and this is what I should differentiate JavaScript from TypeScript. This is really what TypeScript is trying to solve. [00:39:07] Bryan: TypeScript is like. How can, I think TypeScript is a, is a great step forward because TypeScript is like, how can we bring some rigor to this? Like, yes, it's great that it's easy to write JavaScript, but that's not, we, we don't wanna do that for Absolutely. I mean that, that's not the only problem we solve. [00:39:23] Bryan: We actually wanna be able to write rigorous software and it's actually okay if it's a little harder to write rigorous software that's actually okay if it gets leads to, to more rigorous artifacts. Um, but in JavaScript, I mean, just a concrete example. You know, there's nothing to prevent you from referencing a property that doesn't actually exist in JavaScript. [00:39:43] Bryan: So if you fat finger a property name, you are relying on something to tell you. By the way, I think you've misspelled this because there is no type definition for this thing. And I don't know that you've got one that's spelled correctly, one that's spelled incorrectly, that's often undefined. And then the, when you actually go, you say you've got this typo that is lurking in your what you want to be rigorous software. [00:40:07] Bryan: And if you don't execute that code, like you won't know that's there. And then you do execute that code. And now you've got a, you've got an undefined object. And now that's either gonna be an exception or it can, again, depends on how that's handled. It can be really difficult to determine the origin of that, of, of that error, of that programming. [00:40:26] Bryan: And that is a programmer error. And one of the big challenges that we had with Node is that programmer errors and operational errors, like, you know, I'm out of disk space as an operational error. Those get conflated and it becomes really hard. And in fact, I think the, the language wanted to make it easier to just kind of, uh, drive on in the event of all errors. [00:40:53] Bryan: And it's like, actually not what you wanna do if you're trying to build a reliable, robust system. So we had. No end of issues. [00:41:01] Bryan: We've got a lot of experience developing rigorous systems, um, again coming out of operating systems development and so on. And we want, we brought some of that rigor, if strangely, to JavaScript. So one of the things that we did is we brought a lot of postmortem, diagnos ability and observability to node. [00:41:18] Bryan: And so if, if one of our node processes. Died in production, we would actually get a core dump from that process, a core dump that we could actually meaningfully process. So we did a bunch of kind of wild stuff. I mean, actually wild stuff where we could actually make sense of the JavaScript objects in a binary core dump. JavaScript values ease of getting started over robustness [00:41:41] Bryan: Um, and things that we thought were really important, and this is the, the rest of the world just looks at this being like, what the hell is this? I mean, it's so out of step with it. The problem is that we were trying to bridge two disconnected cultures of one developing really. Rigorous software and really designing it for production, diagnosability and the other, really designing it to software to run in the browser and for anyone to be able to like, you know, kind of liven up a webpage, right? [00:42:10] Bryan: Is kinda the origin of, of live script and then JavaScript. And we were kind of the only ones sitting at the intersection of that. And you begin when you are the only ones sitting at that kind of intersection. You just are, you're, you're kind of fighting a community all the time. And we just realized that we are, there were so many things that the community wanted to do that we felt are like, no, no, this is gonna make software less diagnosable. It's gonna make it less robust. The NodeJS split and why people left [00:42:36] Bryan: And then you realize like, I'm, we're the only voice in the room because we have got, we have got desires for this language that it doesn't have for itself. And this is when you realize you're in a bad relationship with software. It's time to actually move on. And in fact, actually several years after, we'd already kind of broken up with node. [00:42:55] Bryan: Um, and it was like, it was a bit of an acrimonious breakup. there was a, uh, famous slash infamous fork of node called IoJS Um, and this was viewed because people, the community, thought that Joyent was being what was not being an appropriate steward of node js and was, uh, not allowing more things to come into to, to node. [00:43:19] Bryan: And of course, the reason that we of course, felt that we were being a careful steward and we were actively resisting those things that would cut against its fitness for a production system. But it's some way the community saw it and they, and forked, um, and, and I think the, we knew before the fork that's like, this is not working and we need to get this thing out of our hands. Platform is a reflection of values node summit talk [00:43:43] Bryan: And we're are the wrong hands for this? This needs to be in a foundation. Uh, and so we kind of gone through that breakup, uh, and maybe it was two years after that. That, uh, friend of mine who was um, was running the, uh, the node summit was actually, it's unfortunately now passed away. Charles er, um, but Charles' venture capitalist great guy, and Charles was running Node Summit and came to me in 2017. [00:44:07] Bryan: He is like, I really want you to keynote Node Summit. And I'm like, Charles, I'm not gonna do that. I've got nothing nice to say. Like, this is the, the, you don't want, I'm the last person you wanna keynote. He's like, oh, if you have nothing nice to say, you should definitely keynote. You're like, oh God, okay, here we go. [00:44:22] Bryan: He's like, no, I really want you to talk about, like, you should talk about the Joyent breakup with NodeJS. I'm like, oh man. [00:44:29] Bryan: And that led to a talk that I'm really happy that I gave, 'cause it was a very important talk for me personally. Uh, called Platform is a reflection of values and really looking at the values that we had for Node and the values that Node had for itself. And they didn't line up. [00:44:49] Bryan: And the problem is that the values that Node had for itself and the values that we had for Node are all kind of positives, right? Like there's nobody in the node community who's like, I don't want rigor, I hate rigor. It's just that if they had the choose between rigor and making the language approachable. [00:45:09] Bryan: They would choose approachability every single time. They would never choose rigor. And, you know, that was a, that was a big eye-opener. I do, I would say, if you watch this talk. [00:45:20] Bryan: because I knew that there's, like, the audience was gonna be filled with, with people who, had been a part of the fork in 2014, I think was the, the, the, the fork, the IOJS fork. And I knew that there, there were, there were some, you know, some people that were, um, had been there for the fork and. [00:45:41] Bryan: I said a little bit of a trap for the audience. But the, and the trap, I said, you know what, I, I kind of talked about the values that we had and the aspirations we had for Node, the aspirations that Node had for itself and how they were different. [00:45:53] Bryan: And, you know, and I'm like, look in, in, in hindsight, like a fracture was inevitable. And in 2014 there was finally a fracture. And do people know what happened in 2014? And if you, if you, you could listen to that talk, everyone almost says in unison, like IOJS. I'm like, oh right. IOJS. Right. That's actually not what I was thinking of. [00:46:19] Bryan: And I go to the next slide and is a tweet from a guy named TJ Holloway, Chuck, who was the most prolific contributor to Node. And it was his tweet also in 2014 before the fork, before the IOJS fork explaining that he was leaving Node and that he was going to go. And you, if you turn the volume all the way up, you can hear the audience gasp. [00:46:41] Bryan: And it's just delicious because the community had never really come, had never really confronted why TJ left. Um, there. And I went through a couple folks, Felix, bunch of other folks, early Node folks. That were there in 2010, were leaving in 2014, and they were going to go primarily, and they were going to go because they were sick of the same things that we were sick of. [00:47:09] Bryan: They, they, they had hit the same things that we had hit and they were frustrated. I I really do believe this, that platforms do reflect their own values. And when you are making a software decision, you are selecting value. [00:47:26] Bryan: You should select values that align with the values that you have for that software. That is, those are, that's way more important than other things that people look at. I think people look at, for example, quote unquote community size way too frequently, community size is like. Eh, maybe it can be fine. [00:47:44] Bryan: I've been in very large communities, node. I've been in super small open source communities like AUMs and RAs, a bunch of others. there are strengths and weaknesses to both approaches just as like there's a strength to being in a big city versus a small town. Me personally, I'll take the small community more or less every time because the small community is almost always self-selecting based on values and just for the same reason that I like working at small companies or small teams. [00:48:11] Bryan: There's a lot of value to be had in a small community. It's not to say that large communities are valueless, but again, long answer to your question of kind of where did things go south with Joyent and node. They went south because the, the values that we had and the values the community had didn't line up and that was a very educational experience, as you might imagine. [00:48:33] Jeremy: Yeah. And, and given that you mentioned how, because of those values, some people moved from Node to go, and in the end for much of what oxide is building. You ended up using rust. What, what would you say are the, the values of go and and rust, and how did you end up choosing Rust given that. Go's decisions regarding generics, versioning, compilation speed priority [00:48:56] Bryan: Yeah, I mean, well, so the value for, yeah. And so go, I mean, I understand why people move from Node to Go, go to me was kind of a lateral move. Um, there were a bunch of things that I, uh, go was still garbage collected, um, which I didn't like. Um, go also is very strange in terms of there are these kind of like. [00:49:17] Bryan: These autocratic kind of decisions that are very bizarre. Um, there, I mean, generics is kind of a famous one, right? Where go kind of as a point of principle didn't have generics, even though go itself actually the innards of go did have generics. It's just that you a go user weren't allowed to have them. [00:49:35] Bryan: And you know, it's kind of, there was, there was an old cartoon years and years ago about like when a, when a technologist is telling you that something is technically impossible, that actually means I don't feel like it. Uh, and there was a certain degree of like, generics are technically impossible and go, it's like, Hey, actually there are. [00:49:51] Bryan: And so there was, and I just think that the arguments against generics were kind of disingenuous. Um, and indeed, like they ended up adopting generics and then there's like some super weird stuff around like, they're very anti-assertion, which is like, what, how are you? Why are you, how is someone against assertions, it doesn't even make any sense, but it's like, oh, nope. [00:50:10] Bryan: Okay. There's a whole scree on it. Nope, we're against assertions and the, you know, against versioning. There was another thing like, you know, the Rob Pike has kind of famously been like, you should always just run on the way to commit. And you're like, does that, is that, does that make sense? I mean this, we actually built it. [00:50:26] Bryan: And so there are a bunch of things like that. You're just like, okay, this is just exhausting and. I mean, there's some things about Go that are great and, uh, plenty of other things that I just, I'm not a fan of. Um, I think that the, in the end, like Go cares a lot about like compile time. It's super important for Go Right? [00:50:44] Bryan: Is very quick, compile time. I'm like, okay. But that's like compile time is not like, it's not unimportant, it's doesn't have zero importance. But I've got other things that are like lots more important than that. Um, what I really care about is I want a high performing artifact. I wanted garbage collection outta my life. Don't think garbage collection has good trade offs [00:51:00] Bryan: I, I gotta tell you, I, I like garbage collection to me is an embodiment of this like, larger problem of where do you put cognitive load in the software development process. And what garbage collection is saying to me it is right for plenty of other people and the software that they wanna develop. [00:51:21] Bryan: But for me and the software that I wanna develop, infrastructure software, I don't want garbage collection because I can solve the memory allocation problem. I know when I'm like, done with something or not. I mean, it's like I, whether that's in, in C with, I mean it's actually like, it's really not that hard to not leak memory in, in a C base system. [00:51:44] Bryan: And you can. give yourself a lot of tooling that allows you to diagnose where memory leaks are coming from. So it's like that is a solvable problem. There are other challenges with that, but like, when you are developing a really sophisticated system that has garbage collection is using garbage collection. [00:51:59] Bryan: You spend as much time trying to dork with the garbage collector to convince it to collect the thing that you know is garbage. You are like, I've got this thing. I know it's garbage. Now I need to use these like tips and tricks to get the garbage collector. I mean, it's like, it feels like every Java performance issue goes to like minus xx call and use the other garbage collector, whatever one you're using, use a different one and using a different, a different approach. [00:52:23] Bryan: It's like, so you're, you're in this, to me, it's like you're in the worst of all worlds where. the reason that garbage collection is helpful is because the programmer doesn't have to think at all about this problem. But now you're actually dealing with these long pauses in production. [00:52:38] Bryan: You're dealing with all these other issues where actually you need to think a lot about it. And it's kind of, it, it it's witchcraft. It, it, it's this black box that you can't see into. So it's like, what problem have we solved exactly? And I mean, so the fact that go had garbage collection, it's like, eh, no, I, I do not want, like, and then you get all the other like weird fatwahs and you know, everything else. [00:52:57] Bryan: I'm like, no, thank you. Go is a no thank you for me, I, I get it why people like it or use it, but it's, it's just, that was not gonna be it. Choosing Rust [00:53:04] Bryan: I'm like, I want C. but I, there are things I didn't like about C too. I was looking for something that was gonna give me the deterministic kind of artifact that I got outta C. But I wanted library support and C is tough because there's, it's all convention. you know, there's just a bunch of other things that are just thorny. And I remember thinking vividly in 2018, I'm like, well, it's rust or bust. Ownership model, algebraic types, error handling [00:53:28] Bryan: I'm gonna go into rust. And, uh, I hope I like it because if it's not this, it's gonna like, I'm gonna go back to C I'm like literally trying to figure out what the language is for the back half of my career. Um, and when I, you know, did what a lot of people were doing at that time and people have been doing since of, you know, really getting into rust and really learning it, appreciating the difference in the, the model for sure, the ownership model people talk about. [00:53:54] Bryan: That's also obviously very important. It was the error handling that blew me away. And the idea of like algebraic types, I never really had algebraic types. Um, and the ability to, to have. And for error handling is one of these really, uh, you, you really appreciate these things where it's like, how do you deal with a, with a function that can either succeed and return something or it can fail, and the way c deals with that is bad with these kind of sentinels for errors. [00:54:27] Bryan: And, you know, does negative one mean success? Does negative one mean failure? Does zero mean failure? Some C functions, zero means failure. Traditionally in Unix, zero means success. And like, what if you wanna return a file descriptor, you know, it's like, oh. And then it's like, okay, then it'll be like zero through positive N will be a valid result. [00:54:44] Bryan: Negative numbers will be, and like, was it negative one and I said airo, or is it a negative number that did not, I mean, it's like, and that's all convention, right? People do all, all those different things and it's all convention and it's easy to get wrong, easy to have bugs, can't be statically checked and so on. Um, and then what Go says is like, well, you're gonna have like two return values and then you're gonna have to like, just like constantly check all of these all the time. Um, which is also kind of gross. Um, JavaScript is like, Hey, let's toss an exception. If, if we don't like something, if we see an error, we'll, we'll throw an exception. [00:55:15] Bryan: There are a bunch of reasons I don't like that. Um, and you look, you'll get what Rust does, where it's like, no, no, no. We're gonna have these algebra types, which is to say this thing can be a this thing or that thing, but it, but it has to be one of these. And by the way, you don't get to process this thing until you conditionally match on one of these things. [00:55:35] Bryan: You're gonna have to have a, a pattern match on this thing to determine if it's a this or a that, and if it in, in the result type that you, the result is a generic where it's like, it's gonna be either the thing that you wanna return. It's gonna be an okay that contains the thing you wanna return, or it's gonna be an error that contains your error and it forces your code to deal with that. [00:55:57] Bryan: And what that does is it shifts the cognitive load from the person that is operating this thing in production to the, the actual developer that is in development. And I think that that, that to me is like, I, I love that shift. Um, and that shift to me is really important. Um, and that's what I was missing, that that's what Rust gives you. [00:56:23] Bryan: Rust forces you to think about your code as you write it, but as a result, you have an artifact that is much more supportable, much more sustainable, and much faster. Prefer to frontload cognitive load during development instead of at runtime [00:56:34] Jeremy: Yeah, it sounds like you would rather take the time during the development to think about these issues because whether it's garbage collection or it's error handling at runtime when you're trying to solve a problem, then it's much more difficult than having dealt with it to start with. [00:56:57] Bryan: Yeah, absolutely. I, and I just think that like, why also, like if it's software, if it's, again, if it's infrastructure software, I mean the kinda the question that you, you should have when you're writing software is how long is this software gonna live? How many people are gonna use this software? Uh, and if you are writing an operating system, the answer for this thing that you're gonna write, it's gonna live for a long time. [00:57:18] Bryan: Like, if we just look at plenty of aspects of the system that have been around for a, for decades, it's gonna live for a long time and many, many, many people are gonna use it. Why would we not expect people writing that software to have more cognitive load when they're writing it to give us something that's gonna be a better artifact? [00:57:38] Bryan: Now conversely, you're like, Hey, I kind of don't care about this. And like, I don't know, I'm just like, I wanna see if this whole thing works. I've got, I like, I'm just stringing this together. I don't like, no, the software like will be lucky if it survives until tonight, but then like, who cares? Yeah. Yeah. [00:57:52] Bryan: Gar garbage clock. You know, if you're prototyping something, whatever. And this is why you really do get like, you know, different choices, different technology choices, depending on the way that you wanna solve the problem at hand. And for the software that I wanna write, I do like that cognitive load that is upfront. With LLMs maybe you can get the benefit of the robust artifact with less cognitive load [00:58:10] Bryan: Um, and although I think, I think the thing that is really wild that is the twist that I don't think anyone really saw coming is that in a, in an LLM age. That like the cognitive load upfront almost needs an asterisk on it because so much of that can be assisted by an LLM. And now, I mean, I would like to believe, and maybe this is me being optimistic, that the the, in the LLM age, we will see, I mean, rust is a great fit for the LLMH because the LLM itself can get a lot of feedback about whether the software that's written is correct or not. [00:58:44] Bryan: Much more so than you can for other environments. [00:58:48] Jeremy: Yeah, that is a interesting point in that I think when people first started trying out the LLMs to code, it was really good at these maybe looser languages like Python or JavaScript, and initially wasn't so good at something like Rust. But it sounds like as that improves, if. It can write it then because of the rigor or the memory management or the error handling that the language is forcing you to do, it might actually end up being a better choice for people using LLMs. [00:59:27] Bryan: absolutely. I, it, it gives you more certainty in the artifact that you've delivered. I mean, you know a lot about a Rust program that compiles correctly. I mean, th there are certain classes of errors that you don't have, um, that you actually don't know on a C program or a GO program or a, a JavaScript program. [00:59:46] Bryan: I think that's gonna be really important. I think we are on the cusp. Maybe we've already seen it, this kind of great bifurcation in the software that we writ

Narty się skończyły, pora wrócić do rzeczywistości, która w świecie technologii pędzi szybciej niż kiedykolwiek. W dzisiejszym odcinku Tomek, Wojtek i Sebastian analizują miesiąc pełen "wow momentów", kontrowersji wokół autonomicznych agentów i fundamentalnych zmian w procesie tworzenia oprogramowania.W tym odcinku:

In this mini-panel, Jack, Paige, Paul, and Noel discuss how AI reshaping developer tooling is impacting open source monetization, including the recent Tailwind layoffs and the collapse of Tailwind documentation traffic caused by AI. The conversation expands into broader developer tooling business models and reacts to claims like Ryan Dahl stating that the era of humans writing code is over. They also cover the Astro Cloudflare acquisition, what it means for the Cloudflare developer platform, and how this shapes the frontend frameworks future. Hot takes include light mode vs dark mode SaaS, shifting developer aesthetics, and why AI productivity for developers may now come down to workflow design rather than raw coding skill. Resources Tailwind Layoffs and AI Tailwind layoffs: https://www.businessinsider.com/tailwind-engineer-layoffs-ai-github-2026-1#:~:text=Tailwind%20laid%20off%2075%25%20of,on%20our%20engineering%20team%20lost Tailwind layoffs: https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957 Ryan Dahl Tweet: https://x.com/rough__sea/status/2013280952370573666 Apple and Google joint statement: https://x.com/NewsFromGoogle/status/2010760810751017017 Astro joins Cloudflare Astro joins Cloudflare: https://blog.cloudflare.com/astro-joins-cloudflare We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com, or tweet at us at PodRocketPod. Check out our newsletter! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form, and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. ChaptersSpecial Guest: Jack Herrington.

jQuery is the JavaScript library that just won't quit. 20 years after its inception the team released jQuery 4.0.0, and it brings some notable modernizations including removed support for IE 10, a migration to ES modules, and support for Trusted Types. Node.js creator Ryan Dahl declared earlier this week that “the era of humans writing code is over”, and considering how good AI coding agents have gotten lately, he's probably not wrong. Cloudflare also announces it has acquired popular JavaScript framework Astro. Cloudflare has been a good steward to other OSS projects in the past, and this acquisition allows the Astro team to focus on making the framework even better.Timestamps:0:50 - jQuery 4.07:58 - Is the era of humans writing code over?18:23 - Cloudflare acquires Astro24:54 - Vertical tabs are coming to Chrome29:37 - Apple is going to use Gemini for Siri43:07 - What's making us happyNews:Paige - Ryan Dahl declares humans writing code is overJack - Cloudflare acquires AstroTJ - jQuery 4.0Lightning News: Chrome adds support for vertical tabsApple and Google enter agreement to use Gemini for Apple IntelligenceWhat Makes Us Happy this Week:Paige - Onyx Storm bookJack - Learning to play Born to Run on guitarTJ - Only Murders in the Building TV series and Dungeon Crawler Carl book seriesThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or talk to us on X, Bluesky, or YouTube.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fireFollow us on Bluesky @front-end-fire.comSubscribe to our YouTube channel @Front-EndFirePodcast

In this edition of the Web News, Matt and Mike discuss Ryan Dahl's recent comments regarding software engineers in the world of AI. Ryan recently shared his viewpoint via a post on X where he stated that he thinks the era of humans writing code is over - meaning that SWEs may still have work to do, but that writing syntax won't be it. We unpack this viewpoint and further discuss the world of software engineering as AI continues to invade the coding space for hobby coders, professionals, and vibe coders. For those of you that don't know, Ryan Dahl is the creator of Node.js - so his voice carries some weight in the web development space. Show Notes: https://www.htmlallthethings.com/podcast/the-era-of-humans-writing-code-is-over Use our Scrimba affiliate link (https://scrimba.com/?via=htmlallthethings) for a 20% discount!! Full details in show notes.

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 28/06 a 04/07.☕​ Que tal um café com desconto?Veroo Café: https://codigofonte.click/veroocafeCupom: CODIGOFONTE - Plano anual com brinde especial!

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 28/06 a 04/07.☕​ Que tal um café com desconto?Veroo Café: https://codigofonte.click/veroocafeCupom: CODIGOFONTE - Plano anual com brinde especial!

KP chats with CEO and founder of PraiseCharts.com - Ryan Dahl. He dives into the world of 90s worship, and pulls back the curtain on the current landscape of music industry meets worship songs.  Connect with Ryan: Instagram: @ryandahl  Website: www.praisecharts.com ++++++ This episode was brought to you by PraiseCharts. If you are a Worship leader or musician, when it comes to leading in church or playing worship music, you need reliable, high-quality music resources. That's exactly what PraiseCharts provides. With tens of thousands of songs available in chord charts through orchestrations plus stems, you won't struggle to find the songs you want and make things work for your setting—just instant access to the music your team needs. Check out PraiseCharts.com today and see how it can transform your worship ministry! ++++++++++ To learn more about Kurtis' book Worshipology: www.worshipologybook.com or www.kurtisparks.com 

Join us on PodRocket's yearly wrap-up episode as Emily and our hosts— Paige, Noel, Josh, and Paul—discuss significant tech trends of 2024 and predictions for 2025. Topics include AI advancements, React development, the potential impact of Void0, and the controversy surrounding Oracle's JavaScript trademark. Links Paige https://www.paigeniedringhaus.com https://x.com/pniedri https://paigen11.medium.com https://dev.to/paigen11 https://github.com/paigen11 Noel https://bsky.app/profile/noel.minc.how Josh https://bsky.app/profile/joshuakgoldberg.com https://x.com/JoshuaKGoldberg https://hi.joshuakgoldberg.com https://github.com/JoshuaKGoldberg https://fosstodon.org/@JoshuaKGoldberg https://www.twitch.tv/JoshuaKGoldberg https://www.youtube.com/@JoshuaKGoldberg Paul https://www.linkedin.com/in/paul-mikulskis-37a50b4a/ We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)

Deno (JavaScript runtime) mit der programmier.bar.Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Ready for a chat with the creator of Node? Carl and Richard talk to Ryan Dahl about his work creating NodeJS in 2009 and how he moved on after a few years, leading to the creation of Deno, an opinionated approach to building web applications. Ryan talks about the challenges of simplifying web development by combining all the important things into a single set of tools—saving you the effort of assembling those things yourself. The conversation also digs into how web development has evolved and one of Ryan's current efforts - convincing Oracle to surrender the JavaScript trademark to the world!

Ready for a chat with the creator of Node? Carl and Richard talk to Ryan Dahl about his work creating NodeJS in 2009 and how he moved on after a few years, leading to the creation of Deno, an opinionated approach to building web applications. Ryan talks about the challenges of simplifying web development by combining all the important things into a single set of tools—saving you the effort of assembling those things yourself. The conversation also digs into how web development has evolved and one of Ryan's current efforts - convincing Oracle to surrender the JavaScript trademark to the world!

GOTO Chicago, running from October 21st to 23rd at Convene Willis Tower, will host an exciting range of talks and workshops designed for developers, architects, and tech leaders. Highlights include Ryan Dahl on the future of JavaScript with Deno 2, Andy Greenberg exploring the dark side of cryptocurrency in "Tracers in the Dark," and Dave Taht sharing groundbreaking insights into reducing internet latency. The conference covers AI, cloud-native architectures, security, and much more, including lightning talks that provide quick, impactful insights across a variety of tech topics.This podcast is AI-generated as part of an experimental format, offering a fresh, innovative way to explore conference content.GOTO Chicago 2024:https://gotochgo.com/2024Speakers: https://gotochgo.com/2024/speakers Newsletter: https://blog.gotocon.com/newsletterTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Jerod is joined by Ryan Dahl to discuss his second take on leveling up JavaScript developers all around the world. Jerod asks Ryan why not try to fix or fork Node instead of starting fresh, how Deno (the open source project) can avoid the all too common rug pull (not cool) scenario, what's new in Deno 2 & their pragmatic decision to support npm, they talk JSR, they talk Deno KV & SQLite, they even talk about Ryan's open letter to Oracle in an attempt to free the unused "JavaScript" trademark from the giant's clutches.

Jerod is joined by Ryan Dahl to discuss his second take on leveling up JavaScript developers all around the world. Jerod asks Ryan why not try to fix or fork Node instead of starting fresh, how Deno (the open source project) can avoid the all too common rug pull (not cool) scenario, what's new in Deno 2 & their pragmatic decision to support npm, they talk JSR, they talk Deno KV & SQLite, they even talk about Ryan's open letter to Oracle in an attempt to free the unused "JavaScript" trademark from the giant's clutches.

Jerod is joined by Ryan Dahl to discuss his second take on leveling up JavaScript developers all around the world. Jerod asks Ryan why not try to fix or fork Node instead of starting fresh, how Deno (the open source project) can avoid the all too common rug pull (not cool) scenario, what's new in Deno 2 & their pragmatic decision to support npm, they talk JSR, they talk Deno KV & SQLite, they even talk about Ryan's open letter to Oracle in an attempt to free the unused "JavaScript" trademark from the giant's clutches.

Jerod is joined by Ryan Dahl to discuss his second take on leveling up JavaScript developers all around the world. Jerod asks Ryan why not try to fix or fork Node instead of starting fresh, how Deno (the open source project) can avoid the all too common rug pull (not cool) scenario, what's new in Deno 2 & their pragmatic decision to support npm, they talk JSR, they talk Deno KV & SQLite, they even talk about Ryan's open letter to Oracle in an attempt to free the unused "JavaScript" trademark from the giant's clutches.

Mahmoud Mousa releases Sidekick, a tool for hosting side projects on a cheap VPS, Ryan Dahl, has had enough of Oracle bogarting "JavaScript" but not even using it, Thomas Rampelberg's kty is a sweet terminal for Kubernetes, Redis users are considering alternatives after their relicense & a bunch of smart JS folks wrote up nine Node.js pillars.

Mahmoud Mousa releases Sidekick, a tool for hosting side projects on a cheap VPS, Ryan Dahl, has had enough of Oracle bogarting "JavaScript" but not even using it, Thomas Rampelberg's kty is a sweet terminal for Kubernetes, Redis users are considering alternatives after their relicense & a bunch of smart JS folks wrote up nine Node.js pillars.

Mahmoud Mousa releases Sidekick, a tool for hosting side projects on a cheap VPS, Ryan Dahl, has had enough of Oracle bogarting "JavaScript" but not even using it, Thomas Rampelberg's kty is a sweet terminal for Kubernetes, Redis users are considering alternatives after their relicense & a bunch of smart JS folks wrote up nine Node.js pillars.

Ryan Dahl, co-creator of Deno and creator of Node.js, discusses the evolution and future of Deno, covering its advantages, new features, and its potential impact on web development. Links https://tinyclouds.org https://github.com/ry https://x.com/rough__sea https://www.linkedin.com/in/tinyclouds https://github.com/littledivy/flappybird We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Ryan Dahl.

Today, Charles, Dan, AJ, and Steve dive into a range of fascinating discussions. Joining this episode is special guest, Ryan Dahl, the visionary creator behind Node.js and Deno.In this episode, they traverse an eclectic mix of topics, from humorous offbeat news and dad jokes to in-depth tech discussions. They explore the complexities and legalities surrounding free speech, offering diverse perspectives on its implications in the modern digital landscape.But the heart of our discussion is Ryan Dahl's exploration of Deno 2, the latest evolution in JavaScript's runtime environment. You'll hear about its distinctive features, including the revolutionary JSR project, and how it aims to simplify and secure modern JavaScript development, addressing challenges and limitations found in Node.js. They also discuss the intricacies of TypeScript support, Deno's security model, and the future potential of JavaScript in data science.Join them for a lively conversation packed with insights, technical deep-dives, and plenty of humor. Whether you're a seasoned developer or just starting your coding journey, this episode is sure to offer valuable takeaways and an entertaining ride through the world of modern web development.Sponsors Wix StudioSocialsLinkedIn: Ryan DahlTwitter: @deno_landDenoPicksAJ - SwiftAJ - DenoCharles - Challengers! | Board GameRyan - GrainBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

In this episode of Syntax, Wes and Scott talk with Ryan Dahl about Deno 2.0, its new features and use of web standards, and how it seamlessly integrates with popular frameworks like Next.js. Ryan shares insights on the motivations behind Deno's creation, its emphasis on simplicity and security, and offers his take on the evolving JavaScript ecosystem. Show Notes 00:00 Welcome to Syntax! 00:34 What is Deno? 05:08 Deno 2.0 07:49 NPM compatibility 09:40 What parts of Node aren't doable in Deno? 11:22 Do we need a hard break from Require? 13:51 Package management 16:25 Security and performance benefits of Deno 20:57 Brought to you by Sentry.io 20:57 Thoughts on Bun and Node additions 26:25 Ryan's favorite Deno projects Lume Fresh webgpu-examples gpucraft minecraft clone + deno + webgpu gpucraft example Shaderplay Orillusion 28:42 Will we ever see a unified file system API? 31:49 Typescript 36:12 Jupyter Notebooks with Deno Polars 39:11 AI and WASM in JavaScript 42:01 Deno 2.0 features and future 43:08 Sick Picks & Shameless Plugs Sick Picks Ryan: McCarren Park Shameless Plugs Ryan: https://deno.com/enterprise Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

This week we have Ryan Dahl, the creator of Node and Node. We talk about the road that led from Node to Deno and what he wants to do differently. We also talk about the new javascript registry, JSR, and how they hope to make a runtime agnostic town square. https://github.com/ry https://twitter.com/rough__sea https://deno.com Episode sponsored By Clerk (https://clerk.com) Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership

Deno is a free and open source JavaScript runtime built on Google's V8 engine, Rust, and Tokio. The project was announced by Ryan Dahl in 2018 with the goal of addressing shortcomings of Node.js, which Ryan also created. Since then, the Deno project has grown tremendously in popularity, and they recently announced Deno KV which The post Deno with Luca Casonato appeared first on Software Engineering Daily.

Deno is a free and open source JavaScript runtime built on Google’s V8 engine, Rust, and Tokio. The project was announced by Ryan Dahl in 2018 with the goal of addressing shortcomings of Node.js, which Ryan also created. Since then, the Deno project has grown tremendously in popularity, and they recently announced Deno KV which The post Deno with Luca Casonato appeared first on Software Engineering Daily.

Deno is a free and open source JavaScript runtime built on Google’s V8 engine, Rust, and Tokio. The project was announced by Ryan Dahl in 2018 with the goal of addressing shortcomings of Node.js, which Ryan also created. Since then, the Deno project has grown tremendously in popularity, and they recently announced Deno KV which The post Deno with Luca Casonato appeared first on Software Engineering Daily.

Colleen Rennison and Wide Mouth Mason Both with fine new albums   First hour Colleen Rennison.  Year after year one of the voices to keep an eye on in Vancouver, then Austin, Texas. Formerly the lead singer of No Sinner and a self-admitted artist living a life of booze and partying that bordered on harmful – to self and career. Finally, back in Vancouver, Colleen has found friends who've cared for and helped her recover and do what she was meant to do – write and sing. New album Persephone. not named after the tug. Finally, she's put all the gifts together. Man, is this a good album Check out I Do. Colleen brings tales of dark times and new hope. The second Guests are Shaun Verreault and Safwan Javed – Wide Mouth Mason They have released a new album Late Night Walking They are always pushing forward. Finding a new edge to their music. For example,  one track, Minus 2 Minutes features Joey Landreth on guitar in the left channel only, with Shaun on the right. and Safwan right down the middle. On the album with them Gordie Johnson and Ryan Dahl.

Thank you for tuning in to a new episode of the Overflow Worship Podcast! On this episode we are joined by founder of PraiseCharts, Ryan Dahl. And this year PraiseCharts is celebrating their 25th Anniversary! We love PraiseCharts and if you haven't visited their website, you need to! During this episode Ryan shares how PraiseCharts began in 1998, his passion for resourcing the church worship team, where PraiseCharts is today and how it's continuing to grow! Ryan also shares the importance of doing what you love and how to pursue freedom in your music!   Show Notes:   PraiseCharts: Website, Instagram, Facebook, YouTube   PraiseCharts: "How to Play Piano by Ear" video.   PraiseCharts: Christmas Choral project "Come Behold Him"   PraiseCharts: Sheet music for "Come Behold Him".   PraiseCharts Pro, (our subscription plan).   Want to see the live interview on video? Check it out right here on YouTube!   Please subscribe and write us a review! It helps us reach more people.   As always, stay in touch with us on our socials @overflowworshipofficial @andreaolsonmusic and @worshipleadersonline or email us: info@overflowworship.com

Originally published on December 14th, 2022. We sit down with Ryan Dahl, creator of Deno and Node.js, to talk about his experience in web development, why he created Node.js, and why he sees Deno as the next step for JavaScript runtimes. Links https://twitter.com/deno_land https://deno.com/deploy https://deno.land Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Ryan Dahl.

On this episode of Between the Grooves, we are celebrating 25 years of PraiseCharts with founder Ryan Dahl! Hear all about how Ryan came up with the idea of PraiseCharts, how he sets PraiseCharts apart from his competitors and what his plans are for the future. Social Links Instagram: @betweengroovespod Facebook: @betweengrooves Twitter: @betweengrooves Have a question, comment, or a music project you want to promote? Email betweenthegrooves@faithstrongtoday.comSee omnystudio.com/listener for privacy information.

Luca Casonato is the tech lead for Deno Deploy and a TC39 delegate. Deno is a JavaScript runtime from the original creator of NodeJS, Ryan Dahl. Topics covered: What's a JavaScript runtime How V8 is used Why Deno was created The W3C WinterCG for server-side JavaScript Why it's difficult to ship new features in Node The benefits of web standards Creating an all-inclusive toolset like Rust and Go Deno's node compatibility layer Use cases for WebAssembly Benefits and implementation of Deno Deploy Reasons to deploy on the edge What's coming next Luca Luca Casonato @lcasdev Deno Homepage Deploy Showcase Subhosting Fresh web framework The anatomy of an Isolate Cloud Deno Users Netlify Edge Functions Deno at Slack GitHub Flat Data Shopify Oxygen Other related links Cache Web API V8 (JavaScript and WebAssembly engine) TC39 (JavaScript specification group) Web-interoperable Runtimes Community Group (WinterCG) Cloudflare Workers (Deno Deploy competitor) How Cloudflare KV works CockroachDB (Distributed database) XKCD Standards Comic Transcript You can help edit this transcript on GitHub. [00:00:07] Jeremy: Today I'm talking to Luca Casonato. He's a member of the Deno Core team and a TC 39 Delegate. [00:00:06] Luca: Hey, thanks for having me. What's a runtime? [00:00:07] Jeremy: So today we're gonna talk about Deno, and on the website it says, Deno is a runtime for JavaScript and TypeScript. So I thought we could start with defining what a runtime is. [00:00:21] Luca: Yeah, that's a great question. I think this question actually comes up a lot. It's, it's like sometimes we also define Deno as a headless browser, or I don't know, a, a JavaScript script execution tool. what actually defines runtime? I, I think what makes a runtime a runtime is that it is a, it's implemented in native code. It cannot be self-hosted. Like you cannot self-host a JavaScript runtime. and it executes JavaScript or TypeScript or some other scripting language, without relying on, well, yeah, I guess it's the self-hosting thing. Like it's, it's essentially a, a JavaScript execution engine, which is not self-hosted. So yeah, it, it maybe has IO bindings, but it doesn't necessarily need to like, it. Maybe it allows you to read the, from the file system or, or make network calls. Um, but it doesn't necessarily have to. It's, I think the, the primary definition is something which can execute JavaScript without already being written in JavaScript. How V8 and JavaScript runtimes are related [00:01:20] Jeremy: And when we hear about JavaScript run times, whether it's Deno or Node or Bun, or anything else, we also hear about it in the context of v8. Could you explain the relationship between V8 and a JavaScript run time? [00:01:36] Luca: Yeah. So V8 and, and JavaScript core and Spider Monkey, these are all JavaScript engines. So these are the low level virtual machines that can execute or that can parse your JavaScript code. turn it into byte code, maybe turn it into, compiled machine code, and then execute that code. But these engines, Do not implement any IO functions. They do not. They implement the JavaScript spec as is written. and then they provide extension hooks for, they call these host environments, um, like environments that embed these engines to provide custom functionalities to essentially poke out of the sandbox, out of the, out of the virtual machine. Um, and this is used in browsers. Like browsers have, have these engines built in. This is where they originated from. Um, and then they poke holes into this, um, sandbox virtual machine to do things like, I don't know, writing to the dom or, or console logging or making fetch calls and all these kinds of things. And what a runtime essentially does, a JavaScript runtime is it takes one of these engines and. It then provides its own set of host APIs, like essentially its own set of holes. It pokes into the sandbox. and depending on what the runtime is trying to do, um, the weight will do. This is gonna be different and, and the sort of API that is ultimately exposed to the end user is going to be different. For example, if you compare Deno and node, like node is very loosey goosey, about how it pokes holds into the sandbox, it sort of just pokes them everywhere. And this makes it difficult to enforce things like, runtime permissions for example. Whereas Deno is much more strict about how it, um, pokes holds into its sandbox. Like everything is either a web API or it's behind in this Deno name space, which means that it's, it's really easy to find, um, places where, where you're poking out of the sandbox. and really you can also compare these to browsers. Like browsers are also JavaScript run times. Um, they're just not headless. JavaScript run times, but JavaScript run times that also have a ui. and. . Yeah. Like there, there's, there's a whole Bunch of different kinds of JavaScript run times, and I think we're also seeing a lot more like embedded JavaScript run times. Like for example, if you've used React Native before, you, you may be using Hermes as a, um, JavaScript engine in your Android app, which is like a custom JavaScript engine written just for, for, for React native. Um, and this also is embedded within a, like react native run time, which is specific to React native. so it's also possible to have run times, for example, that are, that can be where the, where the back backing engine can be exchanged, which is kind of cool. [00:04:08] Jeremy: So it sounds like V8's role, one way to look at it is it can execute JavaScript code, but only pure functions. I suppose you [00:04:19] Luca: Pretty much. Yep. [00:04:21] Jeremy: Do anything that doesn't interact with IO so you think about browsers, you were mentioning you need to interact with a DOM or if you're writing a server side application, you probably need to receive or make HTTP requests, that sort of thing. And all of that is not handled by v8. That has to be handled by an external runtime. [00:04:43] Luca: Exactly Like, like one, one. There's, there's like some exceptions to this. For example, JavaScript technically has some IO built in with, within its standard library, like math, random. It's like random number. Generation is technically an IO operation, so, Technically V8 has some IO built in, right? And like getting the current date from the user, that's also technically IO So, like there, there's some very limited edge cases. It's, it's not that it's purely pure, but V8 for example, has a flag to turn it completely deterministic. which means that it really is completely pure. And this is not something which run times usually have. This is something like the feature of an engine because the engine is like so low level that it can essentially, there's so little IO that it's very easy to make deterministic where a runtime higher level, um, has, has io, um, much more difficult to make deterministic. [00:05:39] Jeremy: And, and for things like when you're working with JavaScript, there's, uh, asynchronous programming [00:05:46] Luca: mm-hmm. Concurrent JavaScript execution [00:05:47] Jeremy: So you have concurrency and things like that. Is that a part of V8 or is that the responsibility of the run time? [00:05:54] Luca: That's a great question. So there's multiple parts to this. There's the part, um, there, there's JavaScript promises, um, and sort of concurrent Java or well, yes, concurrent JavaScript execution, which is sort of handled by v8, like v8. You can in, in pure v8, you can create a promise, and you can execute some code within that promise. But without IO there's actually no way to defer time, uh, which means that in with pure v8, you can either, you can create a promise. Which executes right now. Or you can create a promise that never executes, but you can't create a promise that executes in 10 seconds because there's no way to measure 10 seconds asynchronously. What run times do is they add something called an event loop on top of this, um, on top of the base engine and that event loop, for example, like a very simple event loop, for example, might have a timer in it, which every second looks at if there's a timer schedule to run within that second. And if it does, if, if that timer exists, it'll go call out to V8 and say, you can now execute that promise. but V8 is still the one that's keeping track of, of like which promises exist, and the code that is meant to be invoked when they resolve all that kind of thing. Um, but the underlying infrastructure that actually invokes which promises get resolved at what point in time, like the asynchronous, asynchronous IO is what this is called. This is driven by the event loop, um, which is implemented by around time. So Deno, for example, it uses, Tokio for its event loop. This is a, um, an event loop written in Rust. it's very popular in the Rust ecosystem. Um, node uses libuv. This is a relatively popular runtime or, or event loop, um, implementation for c uh, plus plus. And, uh, libuv was written for Node. Tokio was not written for Deno. But um, yeah, Chrome has its own event loop implementation. Bun has its own event loop implementation. [00:07:50] Jeremy: So we, we might go a little bit more into that later, but I think what we should probably go into now is why make Deno, because you have Node that's, uh, currently very popular. The co-creator of Deno, to my understanding, actually created Node. So maybe you could explain to our audience what was missing or what was wrong with Node, where they decided I need to create, a new runtime. Why create a new runtime? (standards compliance) [00:08:20] Luca: Yeah. So the, the primary point of concern here was that node was slowly diverging from browser standards with no real path to, to, to, re converging. Um, like there was nothing that was pushing node in the direction of standards compliance and there was nothing, that was like sort of forcing node to innovate. and we really saw this because in the time between, I don't know, 2015, 2018, like Node was slowly working on esm while browsers had already shipped ESM for like three years. , um, node did not have fetch. Node hasn't had, or node only at, got fetch last year. Right? six, seven years after browsers got fetch. Node's stream implementation is still very divergent from, from standard web streams. Node was very reliant on callbacks. It still is, um, like promises in many places of the Node API are, are an afterthought, which makes sense because Node was created in a time before promises existed. Um, but there was really nothing that was pushing Node forward, right? Like nobody was actively investing in, in, in improving the API of Node to be more standards compliant. And so what we really needed was a new like Greenfield project, which could demonstrate that actually writing a new server side run. Is A viable, and b is totally doable with an API that is more standards combined. Like essentially you can write a browser, like a headless browser and have that be an excellent to use JavaScript runtime, right? And then there was some things that were I on top of that, like a TypeScript support because TypeScript was incredibly, or is still incredibly popular. even more so than it was four years ago when, when Deno was created or envisioned, um, this permission system like Node really poked holes into the V8 sandbox very early on with, with like, it's gonna be very difficult for Node to ever, ever, uh, reconcile this, this. Especially cuz the, some, some of the APIs that it, that it exposes are just so incredibly low level that like, I don't know, you can mutate random memory within your process. Um, which like if you want to have a, a secure sandbox like that just doesn't work. Um, it's not compatible. So there was really needed to be a place where you could explore this, um, direction and, and see if it worked. And Deno was that. Deno still is that, and I think Deno has outgrown that now into something which is much more usable as, as like a production ready runtime. And many people do use it, in production. And now Deno is on the path of slowly converging back with Node, um, in from both directions. Like Node is slowly becoming more standards compliant. and depending on who you ask this was, this was done because of Deno and some people said it would had already been going on and Deno just accelerated it. but that's not really relevant because the point is that like Node is becoming more standard compliant and, and the other direction is Deno is becoming more node compliant. Like Deno is implementing node compatibility layers that allow you to run code that was originally written for the node ecosystem in the standards compliant run time. so through those two directions, the, the run times are sort of, um, going back towards each other. I don't think they'll ever merge. but we're, we're, we're getting to a point here pretty soon, I think, where it doesn't really matter what runtime you write for, um, because you'll be able to write code written for one runtime in the other runtime relatively easily. [00:12:03] Jeremy: If you're saying the two are becoming closer to one another, becoming closer to the web standard that runs in the browser, if you're talking to someone who's currently developing in node, what's the incentive for them to switch to Deno versus using Node and then hope that eventually they'll kind of meet in the middle. [00:12:26] Luca: Yeah, so I think, like Deno is a lot more than just a runtime, right? Like a runtime executes JavaScript, Deno executes JavaScript, it executes type script. But Deno is so much more than that. Like Deno has a built-in format, or it has a built-in linter. It has a built-in testing framework, a built-in benching framework. It has a built-in Bundler, it, it like can create self-hosted, um, executables. yeah, like Bundle your code and the Deno executable into a single executable that you can trip off to someone. Um, it has a dependency analyzer. It has editor integrations. it has, Yeah. Like I could go on for hours, (laughs) about all of the auxiliary tooling that's inside of Deno, that's not a JavaScript runtime. And also Deno as a JavaScript runtime is just more standards compliant than any of the other servers at Runtimes right now. So if, if you're really looking for something which is standards complaint, which is gonna like live on forever, then it's, you know, like you cannot kill off the Fetch API ever. The Fetch API is going to live forever because Chrome supports it. Um, and the same goes for local storage and, and like, I don't know, the Blob API and all these other web APIs like they, they have shipped and browsers, which means that they will be supported until the end of time. and yeah, maybe Node has also reached that with its api probably to some extent. but yeah, don't underestimate the power of like 3 billion Chrome users. that would scream immediately if the Fetch API stopped working Right? [00:13:50] Jeremy: Yeah, I, I think maybe what it sounds like also is that because you're using the API that's used in the browser places where you deploy JavaScript applications in the future, you would hope that those would all settle on using that same API so that if you were using Deno, you could host it at different places and not worry about, do I need to use a special API maybe that you would in node? WinterCG (W3C group for server side JavaScript) [00:14:21] Luca: Yeah, exactly. And this is actually something which we're specifically working towards. So, I don't know if you've, you've heard of WinterCG? It's a, it's a community group at the W3C that, um, CloudFlare and, and Deno and some others including Shopify, have started last year. Um, we're essentially, we're trying to standardize the concept of what a server side JavaScript runtime is and what APIs it needs to have available to be standards compliant. Um, and essentially making this portability sort of written down somewhere and like write down exactly what code you can write and expect to be portable. And we can see like that all of the big, all of the big players that are involved in, in, um, building JavaScript run times right now are, are actively, engaged with us at WinterCG and are actively building towards this future. So I would expect that any code that you write today, which runs. in Deno, runs in CloudFlare, workers runs on Netlify Edge functions, runs on Vercel's Edge, runtime, runs on Shopify Oxygen, is going to run on the other four. Um, of, of those within the next couple years here, like I think the APIs of these is gonna converge to be essentially the same. there's obviously gonna always be some, some nuances. Um, like, I don't know, Chrome and Firefox and Safari don't perfectly have the same API everywhere, right? Like Chrome has some web Bluetooth capabilities that Safari doesn't, or Firefox has some, I don't know, non-standard extensions to the error object, which none of the other runtimes do. But overall you can expect these front times to mostly be aligned. yeah, and I, I think that's, that's really, really, really excellent and that, that's I think really one of the reasons why one should really consider, like building for, for this standard runtime because it, it just guarantees that you'll be able to host this somewhere in five years time and 10 years time, with, with very little effort. Like even if Deno goes under or CloudFlare goes under, or, I don't know, nobody decides to maintain node anymore. It'll be easy to, to run somewhere else. And also I expect that the big cloud vendors will ultimately, um, provide, manage offerings for, for the standards compliant JavaScript on time as well. Is Node part of WinterCG? [00:16:36] Jeremy: And this WinterCG group is Node a part of that as well? [00:16:41] Luca: Um, yes, we've invited Node, um, to join, um, due to the complexities of how node's, internal decision making system works. Node is not officially a member of WinterCG. Um, there is some individual members of the node, um, technical steering committee, which are participating. for example, um, James m Snell is, is the co-chair, is my co-chair on, on WinterCG. He also works at CloudFlare. He's also a node, um, TSC member, Mateo Colina, who has been, um, instrumental to getting fetch landed in Node, um, is also actively involved. So Node is involved, but because Node is node and and node's decision making process works the way it does, node is not officially listed anywhere as as a member. but yeah, they're involved and maybe they'll be a member at some point. But, yeah, let's. , see (laughs) [00:17:34] Jeremy: Yeah. And, and it, so it, it sounds like you're thinking that's more of a, a governance or a organizational aspect of note than it is a, a technical limitation. Is that right? [00:17:47] Luca: Yeah. I obviously can't speak for the node technical steering committee, but I know that there's a significant chunk of the node technical steering committee that is, very favorable towards, uh, standards compliance. but parts of the Node technical steering committee are also not, they are either indifferent or are actively, I dunno if they're still actively working against this, but have actively worked against standards compliance in the past. And because the node governance structure is very, yeah, is, is so, so open and let's, um, and let's, let's all these voices be heard, um, that just means that decision making processes within Node can take so long, like. . This is also why the fetch API took eight years to ship. Like this was not a technical problem. and it is also not a technical problem. That Node does not have URL pattern support or, the file global or, um, that the web crypto API was not on this, on the global object until like late last year, right? Like, these are not technical problems, these are decision making problems. Um, and yeah, that was also part of the reason why we started Deno as, as like a separate thing, because like you can try to innovate node, from the inside, but innovating node from the inside is very slow, very tedious, and requires a lot of fighting. And sometimes just showing somebody, from the outside like, look, this is the bright future you could have, makes them more inclined to do something. Why it takes so long to ship new features in Node [00:19:17] Jeremy: Do, do you have a sense for, you gave the example of fetch taking eight years to, to get into node. Do you, do you have a sense of what the typical objection is to, to something like that? Like I, I understand there's a lot of people involved, but why would somebody say, I, I don't want this [00:19:35] Luca: Yeah. So for, for fetch specifically, there was a, there was many different kinds of concerns. Um, one of the, I, I can maybe list two of them. One of them was for example, that the fetch API is not a good API and as such, node should not have it. which is sort of. missing the point of, because it's a standard API, how good or bad the API is is much less relevant because if you can share the API, you can also share a wrapper that's written around the api. Right? and then the other concern was, node does need fetch because Node already has an HTTP API. Um, so, so these are both kind of examples of, of concerns that people had for a long time, which it took a long time to either convince these people or, or to, push the change through anyway. and this is also the case for, for other things like, for example, web, crypto, um, like why do we need web crypto? We already have node crypto, or why do we need yet another streams? Implementation node already has four different streams implementations. Like, why do we need web streams? and the, the. Like, I don't know if you know this XKCD of, there's 14 competing standards. so let's write a 15th standard, to unify them all. And then at the end we just have 15 competing standards. Um, so I think this is also the kind of concern that people were concerned about, but I, I think what we've seen here is that this is really not a concern that one needs to have because it ends up that, or it turns out in the end that if you implement web APIs, people will use web APIs and will use web APIs only for their new code. it takes a while, but we're seeing this with ESM versus require like new code written with require much less common than it was two years ago. And, new code now using like Xhr, whatever it's called, form request or. You know, the one, I mean, compared to using Fetch, like nobody uses that name. Everybody uses Fetch. Um, and like in Node, if you write a little script, like you're gonna use Fetch, you're not gonna use like Nodes, htp, dot get API or whatever. and we're gonna see the same thing with Readable Stream. We're gonna see the same thing with Web Crypto. We're gonna see, see the same thing with Blob. I think one of the big ones where, where Node is still, I, I, I don't think this is one that's ever gonna get solved, is the, the Buffer global and Node. like we have the Uint8, this Uint8 global, um, and like all the run times including browsers, um, and Buffer is like a super set of that, but it's in global scope. So it, it's sort of this non-standard extension of unit eight array that people in node like to use and it's not compatible with anything else. Um, but because it's so easy to get at, people use it anyway. So those are, those are also kind of problems that, that we'll have to deal with eventually. And maybe that means that at some point the buffer global gets deprecated and I don't know, probably can never get removed. But, um, yeah, these are kinds of conversations that the no TSE is going have to have internally in, I don't know, maybe five years. Write once, have it run on any hosting platform [00:22:37] Jeremy: Yeah, so at a high level, What's shipped in the browser, it went through the ECMAScript approval process. People got it into the browser. Once it's in the browser, probably never going away. And because of that, it's safe to build on top of that for these, these server run times because it's never going away from the browser. And so everybody can kind of use it into the future and not worry about it. Yeah. [00:23:05] Luca: Exactly. Yeah. And that's, and that's excluding the benefit that also if you have code that you can write once and use in both the browser and the server side around time, like that's really nice. Um, like that, that's the other benefit. [00:23:18] Jeremy: Yeah. I think that's really powerful. And that right now, when someone's looking at running something in CloudFlare workers versus running something in the browser versus running something in. it's, I think a lot of people make the assumption it's just JavaScript, so I can use it as is. But it, it, there are at least currently, differences in what APIs are available to you. [00:23:43] Luca: Yep. Yep. Why bundle so many things into Deno? [00:23:46] Jeremy: Earlier you were talking about how Deno is more than just the runtime. It has a linter, formatter, file watcher there, there's all sorts of stuff in there. And I wonder if you could talk a little bit to the, the reasoning behind that [00:24:00] Luca: Mm-hmm. [00:24:01] Jeremy: Having them all be separate things. [00:24:04] Luca: Yeah, so the, the reasoning here is essentially if you look at other modern run time or mo other modern languages, like Rust is a great example. Go is a great example. Even though Go was designed around the same time as Node, it has a lot of these same tools built in. And what it really shows is that if the ecosystem converges, like is essentially forced to converge on a single set of built-in tooling, a that built-in tooling becomes really, really excellent because everybody's using it. And also, it means that if you open any project written by any go developer, any, any rest developer, and you look at the tests, you immediately understand how the test framework works and you immediately understand how the assertions work. Um, and you immediately understand how the build system works and you immediately understand how the dependency imports work. And you immediately understand like, I wanna run this project and I wanna restart it when my file changes. Like, you immediately know how to do that because it's the same everywhere. Um, and this kind of feeling of having to learn one tool and then being able to use all of the projects, like being able to con contribute to open source when you're moving jobs, whatever, like between personal projects that you haven't touched in two years, you know, like being able to learn this once and then use it everywhere is such an incredibly powerful tool. Like, people don't appreciate this until they've used a runtime or, or, or language which provides this to them. Like, you can go to any go developer and ask them if they would like. There, there's this, there's this saying in the Go ecosystem, um, that Go FMT is nobody's favorite, but, or, uh, wait, no, I don't remember what the, how the saying goes, but the saying essentially implies that the way that go FMT formats code, maybe not everybody likes, but everybody loves go F M T anyway, because it just makes everything look the same. And like, you can read your friend's code, your, your colleagues code, your new jobs code, the same way that you did your code from two years ago. And that's such an incredibly powerful feeling. especially if it's like well integrated into your IDE you clone a repository, open that repository, and like your testing panel on the left hand side just populates with all the tests, and you can click on them and run them. And if an assertion fails, it's like the standard output format that you're already familiar with. And it's, it's, it's a really great feeling. and if you don't believe me, just go try it out and, and then you will believe me, (laughs) [00:26:25] Jeremy: Yeah. No, I, I'm totally with you. I, I think it's interesting because with JavaScript in particular, it feels like the default in the community is the opposite, right? There's so many different ways. Uh, there are so many different build tools and testing frameworks and, formatters, and it's very different than, like you were mentioning, a go or a Rust that are more recent languages where they just include that, all Bundled in. Yeah. [00:26:57] Luca: Yeah, and I, I think you can see this as well in, in the time that average JavaScript developer spends configuring their tooling compared to a rest developer. Like if I write Rust, I write Rust, like all day, every day. and I spend maybe two, 3% of my time configuring Rust tooling like. Doing dependency imports, opening a new project, creating a format or config file, I don't know, deleting the build directory, stuff like that. Like that's, that's essentially what it means for me to configure my rest tooling. Whereas if you compare this to like a front-end JavaScript project, like you have to deal with making sure that your React version is compatible with your React on version, it's compatible with your next version is compatible with your ve version is compatible with your whatever version, right? this, this is all not automatic. Making sure that you use the right, like as, as a front end developer, you developer. You don't have just NPM installed, no. You have NPM installed, you have yarn installed, you have PNPM installed. You probably have like, Bun installed. And, and, and I don't know to use any of these, you need to have corepack enabled in Node and like you need to have all of their global bin directories symlinked into your or, or, or, uh, included in your path. And then if you install something and you wanna update it, you don't know, did I install it with yarn? Did I install it with N pNPM? Like this is, uh, significant complexity and you, you tend to spend a lot of time dealing with dependencies and dealing with package management and dealing with like tooling configuration, setting up esent, setting up prettier. and I, I think that like, especially Prettier, for example, really showed, was, was one of the first things in the JavaScript ecosystem, which was like, no, we're not gonna give you a config where you, that you can spend like six hours configuring, it's gonna be like seven options and here you go. And everybody used it because, Nobody likes configuring things. It turns out, um, and even though there's always the people that say, oh, well, I won't use your tool unless, like, we, we get this all the time. Like, I'm not gonna use Deno FMT because I can't, I don't know, remove the semicolons or, or use single quotes or change my tab width to 16. Right? Like, wait until all of your coworkers are gonna scream at you because you set the tab width to 16 and then see what they change it to. And then you'll see that it's actually the exact default that, everybody uses. So it'll, it'll take a couple more years. But I think we're also gonna get there, uh, like Node is starting to implement a, a test runner. and I, I think over time we're also gonna converge on, on, on, on like some standard build tools. Like I think ve, for example, is a great example of this, like, Doing a front end project nowadays. Um, like building new front end tooling that's not built on Vite Yeah. Don't like, Vite's it's become the standard and I think we're gonna see that in a lot more places. We should settle on what tools to use [00:29:52] Jeremy: Yeah, though I, I think it's, it's tricky, right? Because you have so many people with their existing projects. You have people who are starting new projects and they're just searching the internet for what they should use. So you're, you're gonna have people on web pack, you're gonna have people on Vite, I guess now there's gonna be Turbo pack, I think is another one that's [00:30:15] Luca: Mm-hmm. [00:30:16] Jeremy: There's, there's, there's all these different choices, right? And I, I think it's, it's hard to, to really settle on one, I guess, [00:30:26] Luca: Yeah, [00:30:27] Jeremy: uh, yeah. [00:30:27] Luca: like I, I, I think this is, this is in my personal opinion also failure of the Node Technical Steering committee, for the longest time to not decide that yes, we're going to bless this as the standard format for Node, and this is the standard package manager for Node. And they did, they sort of did, like, they, for example, node Blessed NPM as the standard, package manager for N for for node. But it didn't innovate on npm. Like no, the tech nodes, tech technical steering committee did not force NPM to innovate NPMs, a private company ultimately bought by GitHub and they had full control over how the NPM cli, um, evolved and nobody forced NPM to, to make sure that package install times are six times faster than they were. Three years ago, like nobody did that. so it didn't happen. And I think this is, this is really a failure of, of the, the, the, yeah, the no technical steering committee and also the wider JavaScript ecosystem of not being persistent enough with, with like focus on performance, focus on user experience, and, and focus on simplicity. Like things got so out of hand and I'm happy we're going in the right direction now, but, yeah, it was terrible for some time. (laughs) Node compatibility layer [00:31:41] Jeremy: I wanna talk a little bit about how we've been talking about Deno in the context of you just using Deno using its own standard library, but just recently last year you added a compatibility shim where people are able to use node libraries in Deno. [00:32:01] Luca: Mm-hmm. [00:32:01] Jeremy: And I wonder if you could talk to, like earlier you had mentioned that Deno has, a different permissions model. on the website it mentions that Deno's HTTP server is two times faster than node in a Hello World example. And I'm wondering what kind of benefits people will still get from Deno if they choose to use packages from Node. [00:32:27] Luca: Yeah, it's a great question. Um, so I think a, again, this is sort of a like, so just to clarify what we actually implemented, like what we have is we have support for you to import NPM packages. Um, so you can import any NPM package from NPM, from your type script or JavaScript ECMAScript module, um, that you have, you already have for your Deno code. Um, and we will under the hood, make sure that is installed somewhere in some directory globally. Like PNPM does. There's no local node modules folder you have to deal with. There's no package of Jason you have to deal with. Um, and there's no, uh, package. Jason, like versioning things you need to deal with. Like what you do is you do import cowsay from NPM colon cowsay at one, and that will import cowsay with like the semver tag one. Um, and it'll like do the sim resolution the same way node does, or the same way NPM does rather. And what you get from that is that essentially it gives you like this backdoor to a callout to all of the existing node code that Isri been written, right? Like you cannot expect that Deno developers, write like, I don't know. There was this time when Deno did not really have that many, third party modules yet. It was very early on, and I don't know the, you either, if you wanted to connect to Postgres and there was no Postgres driver available, then the solution was to write your own Postgres driver. And that is obviously not great. Um, (laughs) . So the better solution here is to let users for these packages where there's no Deno native or, or, or web native or standard native, um, package for this yet that is importable with url. Um, specifiers, you can import this from npm. Uh, so it's sort of this like backdoor into the existing NPM ecosystem. And we explicitly, for example, don't allow you to, create a package.json file or, import bare node specifiers because we don't, we, we want to stay standards compliant here. Um, but to make this work effectively, we need to give you this little back door. Um, and inside of this back door. All hell is like, or like everything is terrible inside there, right? Like inside there you can do bare specifiers and inside there you can like, uh, there's package.json and there's crazy node resolution and underscore underscore DIRNAME and common js. And like all of that stuff is supported inside of this backdoor to make all the NPM packages work. But on the outside it's exposed as this nice, ESM only, NPM specifiers. and the, the reason you would want to use this over, like just using node directly is because again, like you wanna use TypeScript, no config, like necessary. You want to use, you wanna have a formatter you wanna have a linter, you wanna have tooling that like does testing and benchmarking and compiling or whatever. All of that's built in. You wanna run this on the edge, like close to your users and like 30 different, 35 different, uh, points of presence. Um, it's like, Okay, push it to your git repository. Go to this website, click a button two times, and it's running in 35 data centers. like this is, this is the kind of ex like developer experience that you can, you do not get. You, I will argue that you cannot get with Node right now. Like even if you're using something like ts-node, it is not possible to get the same level of developer experience that you do with Deno. And the, the, the same like speed at which you can iterate, iterate on your projects, like create new projects, iterate on them is like incredibly fast in Deno. Like, I can open a, a, a folder on my computer, create a single file, may not ts, put some code in there and then call Deno Run may not. And that's it. Like I don't, I did not need to do NPM install I did not need to do NPM init -y and remove the license and version fields and from, from the generated package.json and like set private to true and whatever else, right? It just all works out of the box. And I think that's, that's what a lot of people come to deno for and, and then ultimately stay for. And also, yeah, standards compliance. So, um, things you build in Deno now are gonna work in five, 10 years, with no hassle. Node shims and testing [00:36:39] Jeremy: And so with this compatibility layer or this, this shim, is it where the node code is calling out to node APIs and you're replacing those with Deno compatible equivalents? [00:36:54] Luca: Yeah, exactly. Like for example, we have a shim in place that shims out the node crypto API on top of the web crypto api. Like sort of, some, some people may be familiar with this in the form of, um, Browserify shims. if anybody still remembers those, it's essentially. , your front end tooling, you were able to import from like node crypto in your front end projects and then behind the scenes your web packs or your browser replies or whatever would take that import from node crypto and would replace it with like the shim that was essentially exposed the same APIs node crypto, but under the hood, wasn't implemented with native calls, but was implemented on top of web crypto, or implemented in user land even. And Deno does something similar. there's a couple edge cases of APIs that there's, where, where we do not expose the underlying thing that we shim to, to end users, outside of the node shim. So like there's some, some APIs that I don't know if I have a good example, like node nextTick for example. Um, like to properly be able to shim node nextTick, you need to like implement this within the event loop in the runtime. and. , you don't need this in Deno, because Deno, you use the web standard queueMicrotask to, to do this kind of thing. but to be able to shim it correctly and run node applications correctly, we need to have this sort of like backdoor into some ugly APIs, um, which, which natively integrate in the runtime, but, yeah, like allow, allow this node code to run. [00:38:21] Jeremy: A, anytime you're replacing a component with a, a shim, I think there's concerns about additional bugs or changes in behavior that can be introduced. Is that something that you're seeing and, and how are you accounting for that? [00:38:38] Luca: Yeah, that's, that's an excellent question. So this is actually a, a great concern that we have all the time. And it's not just even introducing bugs, sometimes it's removing bugs. Like sometimes there's bugs in the node standard library which are there, and people are relying on these bugs to be there for the applications to function correctly. And we've seen this a lot, and then we implement this and we implement from scratch and we don't make that same bug. And then the test fails or then the application fails. So what we do is, um, we actually run node's test suite against Deno's Shim layer. So Node has a very extensive test suite for its own standard library, and we can run this suite against, against our shims to find things like this. And there's still edge cases, obviously, which node, like there was, maybe there's a bug which node was not even aware of existing. Um, where maybe this, like it's is, it's now standard, it's now like intended behavior because somebody relies on it, right? Like the second somebody relies on, on some non-standard or some buggy behavior, it becomes intended. Um, but maybe there was no test that explicitly tests for this behavior. Um, so in that case we'll add our own tests to, to ensure that. But overall we can already catch a lot of these by just testing, against, against node's tests. And then the other thing is we run a lot of real code, like we'll try run Prisma and we'll try run Vite and we'll try run NextJS and we'll try run like, I don't know, a bunch of other things that people throw at us and, check that they work and they work and there's no bugs. Then we did our job well and our shims are implemented correctly. Um, and then there's obviously always the edge cases where somebody did something absolutely crazy that nobody thought possible. and then they'll open an issue on the Deno repo and we scratch our heads for three days and then we'll fix it. And then in the next release there'll be a new bug that we added to make the compatibility with node better. so yeah, but I, yeah. Running tests is the, is the main thing running nodes test. Performance should be equal or better [00:40:32] Jeremy: Are there performance implications? If someone is running an Express App or an NextJS app in Deno, will they get any benefits from the Deno runtime and performance? [00:40:45] Luca: Yeah. It's actually, there is performance implications and they're usually. The opposite of what people think they are. Like, usually when you think of performance implications, it's always a negative thing, right? It's always okay. Like you, it's like a compromise. like the shim layer must be slower than the real node, right? It's not like we can run express faster than node can run, express. and obviously not everything is faster in Deno than it is in node, and not everything is faster in node than it is in Deno. It's dependent on the api, dependent on, on what each team decided to optimize. Um, and this also extends to other run times. Like you can always cherry pick results, like, I don't know, um, to, to make your runtime look faster in certain benchmarks. but overall, what really matters is that you do not like, the first important step for for good node compatibility is to make sure that if somebody runs your code or runs their node code in Deno or your other run type or whatever, It performs at least the same. and then anything on top of that great cherry on top. Perfect. but make sure the baselines is at least the same. And I think, yeah, we have very few APIs where we behave, where we, where, where like there's a significant performance degradation in Deno compared to Node. Um, and like we're actively working on these things. like Deno is not a, a, a project that's done, right? Like we have, I think at this point, like 15 or 16 or 17 engineers working on Deno, spanning across all of our different projects. And like, we have a whole team that's dedicated to performance, um, and a whole team that's dedicated node compatibility. so like these things get addressed and, and we make patch releases every week and a minor release every four weeks. so yeah, it's, it's not a standstill. It's, uh, constantly improving. What should go into the standard library? [00:42:27] Jeremy: Uh, something that kind of makes Deno stand out as it's standard library. There's a lot more in there than there is in in the node one. [00:42:38] Luca: Mm-hmm. [00:42:39] Jeremy: Uh, I wonder if you could speak to how you make decisions on what should go into it. [00:42:46] Luca: Yeah, so early on it was easier. Early on, the, the decision making process was essentially, is this something that a top 100 or top 1000 NPM library implements? And if it is, let's include it. and the decision making is still short of based on that. But right now we've already implemented most of the low hanging fruit. So things that we implement now are, have, have discussion around them whether we should implement them. And we have a process where, well we have a whole team of engineers on our side and we also have community members that, that will review prs and, and, and make comments. Open issues and, and review those issues, to sort of discuss the pros and cons of adding any certain new api. And sometimes it's also that somebody opens an issue that's like, I want, for example, I want an API to, to concatenate two unit data arrays together, which is something you can really easily do node with buffer dot con cat, like the scary buffer thing. and there's no standards way of doing that right now. So we have to have a little utility function that does that. But in parallel, we're thinking about, okay, how do we propose, an addition to the web standards now that makes it easy to concatenate iterates in the web standards, right? yeah, there's a lot to it. Um, but it's, it's really, um, it's all open, like all of our, all of our discussions for, for, additions to the standard library and things like that. It's all, all, uh, public on GitHub and the GitHub issues and GitHub discussions and GitHub prs. Um, so yeah, that's, that's where we do that. [00:44:18] Jeremy: Yeah, cuz to give an example, I was a little surprised to see that there is support for markdown front matter built into the standard library. But when you describe it as we look at the top a hundred thousand packages, are people looking at markdown? Are they looking at front matter? I, I'm sure there's a fair amount that are so that that makes sense. [00:44:41] Luca: Yeah, like it sometimes, like that one specifically was driven by, like, our team was just building a lot of like little blog pages and things like that. And every time it was either you roll your own front matter part or you look for one, which has like a subtle bug here and the other one has a subtle bug there and really not satisfactory with any of them. So, we, we roll that into the standard library. We add good test coverage for it good, add good documentation for it, and then it's like just a resource that people can rely on. Um, and you don't, you then don't have to make the choice of like, do I use this library to do my front meta parsing or the other library? No, you just use the one that's in the standard library. It's, it's also part of this like user experience thing, right? Like it's just a much nicer user experience, not having to make a choice, about stuff like that. Like completely inconsequential stuff. Like which library do we use to do front matter parsing? (laughs) [00:45:32] Jeremy: yeah. I mean, I think when, when that stuff is not there, then I think the temptation is to go, okay, let me see what node modules there are that will let me parse the front matter. Right. And then it, it sounds like probably ideally you want people to lean more on what's either in the standard library or what's native to the Deno ecosystem. Yeah. [00:46:00] Luca: Yeah. Like the, the, one of the big benefits is that the Deno Standard Library is implemented on top of web standards, right? Like it's, it's implemented on top of these standard APIs. so for example, there's node front matter libraries which do not run in the browser because the browser does not have the buffer global. maybe it's a nice library to do front matter pricing with, but. , you choose it and then three days later you decide that actually this code also needs to run in the browser, and then you need to go switch your front matter library. Um, so, so those are also kind of reasons why we may include something in Strand Library, like maybe there's even really good module already to do something. Um, but if there's certain reliance on specific node features that, um, we would like that library to also be compatible with, with, with web standards, we'll, uh, we might include in the standard library, like for example, YAML Parser, um, or the YAML Parser in the standard library is, is a fork of, uh, of the node YAML module. and it's, it's essentially that, but cleaned up and, and made to use more standard APIs rather than, um, node built-ins. [00:47:00] Jeremy: Yeah, it kind of reminds me a little bit of when you're writing a front end application, sometimes you'll use node packages to do certain things and they won't work unless you have a compatibility shim where the browser can make use of certain node APIs. And if you use the APIs that are built into the browser already, then you won't, you won't need to deal with that sort of thing. [00:47:26] Luca: Yeah. Also like less Bundled size, right? Like if you don't have to shim that, that's less, less code you have to ship to the client. WebAssembly use cases [00:47:33] Jeremy: Another thing I've seen with Deno is it supports running web assembly. [00:47:40] Luca: Mm-hmm. [00:47:40] Jeremy: So you can export functions and call them from type script. I was curious if you've seen practical uses of this in production within the context of Deno. [00:47:53] Luca: Yeah. there's actually a Bunch of, of really practical use cases, so probably the most executed bit of web assembly inside of Deno right now is actually yes, build like, yes, build has a web assembly, build like yeses. Build is something that's written and go. You have the choice of either running. Um, natively in machine code as, as like an ELF process on, on Linux or on on Windows or whatever. Or you can use the web assembly build and then it runs in web assembly. And the web assembly build is maybe 50% slower than the, uh, native build, but that is still significantly faster than roll up or, or, or, or I don't know, whatever else people use nowadays to do JavaScript Bun, I don't know. I, I just use es build always, um, So, um, for example, the Deno website, is running on Deno Deploy. And Deno Deploy does not allow you to run Subprocesses because it's, it's like this edge run time, which, uh, has certain security permissions that it's, that are not granted, one of them being sub-processes. So it needs to execute ES build. And the way it executes es build is by running them inside a web assembly. Um, because web assembly is secure, web assembly is, is something which is part of the JavaScript sandbox. It's inside the JavaScript sandbox. It doesn't poke any holes out. Um, so it's, it's able to run within, within like very strict security context. . Um, and then other examples are, I don't know, you want to have a HTML sanitizer, which is actually built on the real HTML par in a browser. we, we have an hdml sanitizer called com or, uh, ammonia, I don't remember. There's, there's an HTML sanitizer library on denoland slash x, which is built on the html parser from Firefox. Uh, which like ensures essentially that your html, like if you do HTML sanitization, you need to make sure your HTML par is correct, because if it's not, you might like, your browser might parse some HTML one way and your sanitizer pauses it another way and then it doesn't sanitize everything correctly. Um, so there's this like the Firefox HTML parser compiled to web assembly. Um, you can use that to. HTML sanitization, or the Deno documentation generation tool, for example. Uh, Deno Doc, there's a web assembly built for it that allows you to programmatically, like generate documentation for, for your type script modules. Um, yeah, and, and also like, you know, deno fmt is available as a WebAssembly module for programmatic access and a Bunch of other internal Deno, programs as well. Like, or, uh, like components, not programs. [00:50:20] Jeremy: What are some of the current limitations of web assembly and Deno for, for example, from web assembly, can I make HTTP requests? Can I read files? That sort of thing. [00:50:34] Luca: Mm-hmm. . Yeah. So web assembly, like when you spawn as web assembly, um, they're called instances, WebAssembly instances. It runs inside of the same vm, like the same, V8 isolate is what they're called, but. it does not have it, it's like a completely fresh sandbox, sort of, in the sense that I told you that between a runtime and like an engine essentially implements no IO calls, right? And a runtime does, like a runtime, pokes holds into the, the, the engine. web assembly by default works the same way that there is no holes poked into its sandbox. So you have to explicitly poke some holes. Uh, if you want to do HTTP calls, for example, when, when you create web assembly instance, it gives you, or you can give it something called imports, uh, which are essentially JavaScript function bindings, which you can call from within the web assembly. And you can use those function bindings to do anything you can from JavaScript. You just have to pass them through explicitly. and. . Yeah. Depending on how you write your web assembly, like if you write it in Rust, for example, the tooling is very nice and you can just call some JavaScript code from your Rust, and then the build system will automatically make sure that the right function bindings are passed through with the right names. And like, you don't have to deal with anything. and if you're writing go, it's slightly more complicated. And if you're writing like raw web assembly, like, like the web assembly, text format and compiling that to a binary, then like you have to do everything yourself. Right? It's, it's sort of the difference between writing C and writing JavaScript. Like, yeah. What level of abstraction do you want? It's definitely possible though, and that's for limitations. it, the same limitations as, as existing browsers apply. like the web assembly support in Deno is equivalent to the web assembly support in Chrome. so you can do, uh, many things like multi-threading and, and stuff like that already. but especially around, shared mutable memory, um, and having access to that memory from JavaScript. That's something which is a real difficulty with web assembly right now. yeah, growing web assembly memory is also rather difficult right now. There's, there's a, there's a couple inherent limitations right now with web assembly itself. Um, but those, those will be worked out over time. And, and Deno is like very up to date with the version of, of the standard, it, it implements, um, through v8. Like we're, we're, we're up to date with Chrome Beta essentially all the time. So, um, yeah. Any, anything you see in, in, in Chrome beta is gonna be in Deno already. Deno Deploy [00:52:58] Jeremy: So you talked a little bit about this before, the Deno team, they have their own, hosting. Platform called Deno Deploy. So I wonder if you could explain what that is. [00:53:12] Luca: Yeah, so Deno has this really nice, this really nice concept of permissions which allow you to, sorry, I'm gonna start somewhere slightly, slightly unrelated. Maybe it sounds like it's unrelated, but you'll see in a second. It's not unrelated. Um, Deno has this really nice permission system which allows you to sandbox Deno programs to only allow them to do certain operations. For example, in Deno, by default, if you try to open a file, it'll air out and say you don't have read permissions to read this file. And then what you do is you specify dash, dash allow read um, maybe you have to give it. they can either specify, allow, read, and then it'll grant to read access to the entire file system. Or you can explicitly specify files or folders or, any number of things. Same goes for right permissions, same goes for network permissions. Um, same goes for running subprocesses, all these kind of things. And by limiting your permissions just a little bit. Like, for example, by just disabling sub-processes and foreign function interface, but allowing everything else, allowing reeds and allowing network access and all that kind of stuff. we can run Deno programs in a way that is significantly more cost effective to you as the end user than, and, and like we can cold start them much faster than, like you may be able to with a, with a more conventional container based, uh, system. So what, what do you, what Deno Deploy is, is a way to run JavaScript or Deno Code, on our data centers all across the world with very little latency. like you can write some JavaScript code which execute, which serves HTTP requests deploy that to our platform, and then we'll make sure to spin that code up all across the world and have your users be able to access it through some URL or, or, or some, um, custom domain or something like that. and this is some, this is very similar to CloudFlare workers, for example. Um, and it's like Netlify Edge functions is built on top of Deno Deploy. Like Netlify Edge functions is implemented on top of Deno Deploy, um, through our sub hosting product. yeah, essentially Deno Deploy is, is, um, yeah, a cloud hosting service for JavaScript, um, which allows you to execute arbitrary JavaScript. and there there's a couple, like different directions we're going there. One is like more end user focused, where like you link your GitHub repository and. Like, we'll, we'll have a nice experience like you do with Netlify and Versace, that word like your commits automatically get deployed and you get preview deployments and all that kind of thing. for your backend code though, rather than for your front end websites. Although you could also write front-end websites and you know, obviously, and the other direction is more like business focused. Like you're writing a SaaS application and you want to allow the user to customize, the check like you're writing a SaaS application that provides users with the ability to write their own online store. Um, and you want to give them some ability to customize the checkout experience in some way. So you give them a little like text editor that they can type some JavaScript into. And then when, when your SaaS application needs to hit this code path, it sends a request to us with the code, we'll execute that code for you in a secure way. In a secure sandbox. You can like tell us you, this code only has access to like my API server and no other networks to like prevent data exfiltration, for example. and then you do, you can have all this like super customizable, code in inside of your, your SaaS application without having to deal with any of the operational complexities of scaling arbitrary code execution, or even just doing arbitrary code execution, right? Like it's, this is a very difficult problem and give it to someone else and we deal with it and you just get the benefits. yeah, that's Deno Deploy, and it's built by the same team that builds the Deno cli. So, um, all the, all of your favorite, like Deno cli, or, or Deno APIs are available in there. It's just as web standard is Deno, like you have fetch available, you have blob available, you have web crypto available, that kind of thing. yeah. Running code in V8 isolates [00:56:58] Jeremy: So when someone ships you their, their code and you run it, you mentioned that the, the cold start time is very low. Um, how, how is the code being run? Are people getting their own process? It sounds like it's not, uh, using containers. I wonder if you could explain a little bit about how that works. [00:57:20] Luca: Yeah, yeah, I can, I can give a high level overview of how it works. So, the way it works is that we essentially have a pool of, of Deno processes ready. Well, it's not quite Deno processes, it's not the same Deno CLI that you download. It's like a modified version of the Deno CLI based on the same infrastructure, that we have spun up across all of our different regions across the world, uh, across all of our different data centers. And then when we get a request, we'll route that request, um, the first time we get request for that, that we call them deployments, that like code, right? We'll take one of these idle Deno processes and will assign that code to run in that process, and then that process can go serve the requests. and these process, they're, they're, they're isolated and they're, you. it's essentially a V8 isolate. Um, and it's a very, very slim, it's like, it's a much, much, much slimmer version of the Deno cli essentially. Uh, which the only thing it can do is JavaScript execution and like, it can't even execute type script, for example, like type script is we pre-process it up front to make the the cold start faster. and then what we do is if you don't get a request for some amount of. , we'll, uh, spin down that, um, that isolate and, uh, we'll spin up a new idle one in its place. And then, um, if you get another request, I don't know, an hour later for that same deployment, we'll assign it to a new isolate. And yeah, that's a cold start, right? Uh, if you have an isolate which receives, or a, a deployment rather, which receives a Bunch of traffic, like let's say you receive a hundred requests per second, we can send a Bunch of that traffic to the same isolate. Um, and we'll make sure that if, that one isolate isn't able to handle that load, we'll spin it out over multiple isolates and we'll, we'll sort of load balance for you. Um, and we'll make sure to always send to the, to the point of present that's closest to, to the user making the request. So they get very minimal latency. and they get we, we've these like layers of load balancing in place and, and, and. I'm glossing over a Bunch of like security related things here about how these, these processes are actually isolated and how we monitor to ensure that you don't break out of these processes. And for example, Deno Deploy does, it looks like you have a file system cuz you can read files from the file system. But in reality, Deno Deploy does not have a file system. Like the file system is a global virtual file system. which is, is, uh, yeah, implemented completely differently than it is in Deno cli. But as an end user you don't have to care about that because the only thing you care about is that it has the exact same API as the Deno cli and you can run your code locally and if it works there, it's also gonna work in deploy. yeah, so that's, that's, that's kind of. High level of Deno Deploy. If, if any of this sounds interesting to anyone, by the way, uh, we're like very actively hiring on, on Deno Deploy. I happen to be the, the tech lead for, for a Deno Deploy product. So I'm, I'm always looking for engineers, to, to join our ranks and, and build cool distributed systems. Deno.com/jobs. [01:00:15] Jeremy: for people who aren't familiar with the isolates, are these each run in their own processes, or do you have a single process and that has a whole Bunch of isolates inside it? [01:00:28] Luca: in, in the general case, you can say that we run, uh, one isolate per process. but there's many asterisks on that. Um, because, it's, it's very complicated. I'll just say it's very complicated. Uh, in, in the general case though, it's, it's one isolate per process. Yeah. Configuring permissions [01:00:45] Jeremy: And then you touched a little bit on the permissions system. Like you gave the example of somebody could have a website where they let their users give them code to execute. how does it look in terms of specifying what permissions people have? Like, is that a configuration file? Are those flags you pass in? What, what does that look? [01:01:08] Luca: Yeah. So, so that product is called sub hosting. It's, um, slightly different from our end user platform. Um, it's essentially a service that allows you to, like, you email us, well, we'll send you a, um, onboard you, and then what you can do is you can send HTTP requests to a certain end point with a, authentication token and. a reference to some code to execute. And then what we'll do is, we'll, um, when we receive that HTTP request, we'll fetch the code, it's spin up and isolate, execute the code. execute the code. We serve the request, return you the response, um, and then we'll pipe logs to you and, and stuff like that. and the, and, and part of that is also when we, when we pull the, um, the, the code for to spin up the isolate, that code doesn't just include the code that we're executing, but also includes things like permissions, and, and various other, we call this isolate configuration. Um, you can inspect, this is all public. we have public docs for this at Deno.com/subhosting. I think. Yes, Deno.com/subhosting. [01:02:08] Jeremy: And is that built on top of something that's a part of the public Deno project, the open source part? Or is this specific to this sub hosting

Sam and Ryan chat about how to avoid a flicker of content on initial render due to mismatched server/client rendering. They also chat about the pros and cons of React Hooks, and using StackBlitz containers to debug OSS issues.Topics include:0:00 – Intro1:46 – Ryan Florence's tweets about Hooks, useEffect and refs18:12 – How to avoid SSR/CSR rendering mismatches when your initial render depends on client-side APIs37:40 – Using StackBlitz for reproduction in open source45:17 – Isolated app development environments with JavaScript containersLinks:Ryan Florence's tweets on HooksDan Abramov's replyReact beta docs on bugs found from double renderingReact beta docs on bugs found from re-running EffectsStackBlitzChangelog episode with Ryan Dahl about Deno Deploy as a platform

Ryan Dahl stops by to talk about Node, Deno, JavaScript, testing, V8, and thoughts around getting started with Deno.

Deno creator Ryan Dahl goes one-on-one with Jerod to discuss their new npm support, why he's so excited about JavaScript containers, Deno Deploy's present & future, what he thinks about alternative runtimes like Bun, WinterCG, how Wasm fits into the story & more!

Deno creator Ryan Dahl goes one-on-one with Jerod to discuss their new npm support, why he's so excited about JavaScript containers, Deno Deploy's present & future, what he thinks about alternative runtimes like Bun, WinterCG, how Wasm fits into the story & more!

We sit down with Ryan Dahl, creator of Deno and Node.js, to talk about his experience in web development, why he created Node.js, and why he sees Deno as the next step for JavaScript runtimes. Links https://twitter.com/deno_land https://deno.com/deploy https://deno.land Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Ryan Dahl.

In this supper club episode of Syntax, Wes and Scott talk with Ryan Dahl about Deno. Why was Deno created? What is Deno written in? How is Deno so much faster? And what's the future of Deno? Gatsby - Sponsor Today's episode was sponsored by Gatsby, the fastest frontend for the headless web. Gatsby is the framework of choice for content-rich sites backed by a headless CMS as its GraphQL data layer makes it straightforward to source website content from anywhere. Gatsby's opinionated, React-based framework makes the hardest parts of building a performant website simpler. Visit Gatsby.dev/Syntax to get your first Gatsby site up in minutes and experience the speed. ⚡️ Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Sanity - Sponsor Sanity.io is a real-time headless CMS with a fully customizable Content Studio built in React. Get a Sanity powered site up and running in minutes at sanity.io/create. Get an awesome supercharged free developer plan on sanity.io/syntax. Show Notes 00:36 Welcome Tinyclouds.org Ry on GitHub Deno Deno Discord 01:18 The introduction of Node 02:51 Why are you still betting on JavaScript for the web? 05:34 Why did you make Deno? 09:04 How does TypeScript fit into the landscape? 11:40 How is Deno so much faster? 13:28 Sponsor: Sanity 14:17 What is Deno written in? 15:56 Should developers be learning Rust? 18:27 Will libraries that work on npm eventually work in Deno? 21:52 Are we going to use Node API's or web spec? 24:31 Sponsor: Sentry 25:31 What is tooling like for Deno? WinterCG Deno VS Code Extension 29:27 What is Deno deploy? Deno Deploy 34:01 Deno's framework Fresh 38:56 Client side vs server side rendering 41:27 Sponsor: Gatsby 42:28 What's the future of Deno? 43:39 Supper club questions 53:30 SIIIIICK ××× PIIIICKS ××× Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Ryan Dahl is the co-founder and creator of Deno, a runtime for JavaScript, TypeScript, and WebAssembly based on the V8 JavaScript engine and the Rust programming language. He is also the creator of Node.js. We interviewed Dahl for The New Stack Technical Founder Odyssey series. "Yeah, so we have a JavaScript runtime," Dahl said. "It's pretty similar in, in essence, to Node. It executes some JavaScript, but it's much more modern. " The Deno project started four years ago, Dahl said. He recounted how writing code helped him rethink how he developed Node. Dahl wrote a demo of a modern, server-side JavaSript runtime. He didn't think it would go anywhere, but sure enough, it did. People got pretty interested in it. Deno has "many, many" components, which serve as its foundation. It's written in Rust and C++ with a different type of event loop library. Deno has non-blocking IO as does Node. Dahl has built his work on the use of asynchronous technologies. The belief system carries over into how he manages the company. Dahl is an asynchronous guy and runs his company in such a fashion. As an engineer, Dahl learned that he does not like to be interrupted by meetings. The work should be as asynchronous as possible to avoid interruptions. Deno, the company, started during the pandemic, Dahl said. Everyone is remote. They pair program a lot and focus on short, productive conversations. That's an excellent way to socialize and look deeper into problems. How is for Dahl to go from programming to CEO? "I'd say it's relatively challenging," Dahl said. I like programming a lot. Ideally, I would spend most of my time in an editor solving programming problems. That's not really what the job of being a CEO is." Dahl said there's a lot more communication as the CEO operates on a larger scale. Engineering teams need management to ensure they work together effectively, deliver features and solve problems for developers. Overall, Dahl takes it one day at a time. He has no fundamental theory of management. He's just trying to solve problems as they come. "I mean, my claim to fame is like bringing asynchronous sockets to the mainstream with nonblocking IO and stuff. So, you know, asynchronous is deeply embedded and what I'm thinking about. When it comes to company organization, asynchronous means that we have rotating meeting schedules to adapt to people in different time zones. We do a lot of meeting recordings. So if you can't make it for whatever reason, you're not in the right time zone, you're, you know, you're, picking up your kids, whatever. You can go back and watch the recording. So we basically record every every meeting, we try to keep the meeting short. I think that's important because nobody wants to watch hours and hours of videos. And we use, we use chats a lot. And chat and email are forms of asynchronous communication where you don't need to kind of meet with people one on one. And yeah, I guess I guess the other aspect of that is just keeping meetings to a minimum. Like there's there's a few situations where you really need to get everybody in the room. I mean, there are certainly times when you need to do that. But I tried to avoid that as much as possible, because I think that really disrupts the flow of a lot of people working."

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 03/09 a 09/09!

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 03/09 a 09/09!

Ryan Dahl is the founder of Praisecharts and someone who is always pushing the envelope when it comes to serving the church. In this interview we talk about arranging for choirs, making partners out of competition and supporting musicians who are feeling left behind by technology.

Ryan Dahl is the founder of Praisecharts and someone who is always pushing the envelope when it comes to serving the church. In this interview we talk about arranging for choirs, making partners out of competition and supporting musicians who are feeling left behind by technology.

This week on the show we welcome Ryan Dahl. Ryan has served churches like North Langley Community Church and Pacific Rim Church in Langley British Columbia. Ryan is the founder and owner of PraiseCharts. Praise Charts serves Worship Leaders and churches with sheet music, chord and lyric sheets, arrangements and more. We talk with Ryan about the history of PraiseCharts, some big projects they are working on, the best ways to search for stuff on their site, and more. SHOW NOTES --- Support this podcast: https://anchor.fm/makingsundayhappen/support

Join our host, Andrea Olson, and our special guest Ryan Dahl, founder of PraiseCharts! They discuss everything from personal worship experiences, different needs in worship resources, the importance of authenticity, and what PraiseCharts is up to now as an organization. Don't miss out on this exclusive conversation! Show Notes: Visit PraiseCharts' website: https://www.praisecharts.com/ Instagram: https://www.instagram.com/praisecharts/ Facebook: https://www.facebook.com/praisecharts As always, stay in touch with us on our socials @overflowworshipofficial @andreaolsonmusic and @overflowresource or email us: info@overflowworship.com Podcast music created by Andrea Olson

Join our host, Andrea Olson, and our special guest Ryan Dahl, founder of PraiseCharts! They discuss everything from personal worship experiences, different needs in worship resources, the importance of authenticity, and what PraiseCharts is up to now as an organization. Don't miss out on this exclusive conversation! Show Notes: Visit PraiseCharts' website: https://www.praisecharts.com/ Instagram: https://www.instagram.com/praisecharts/ Facebook: https://www.facebook.com/praisecharts As always, stay in touch with us on our socials @overflowworshipofficial @andreaolsonmusic and @overflowresource or email us: info@overflowworship.com Podcast music created by Andrea Olson

Join Jason Squires as he sits down and chats with the Ryan Dahl, the founder of PraiseCharts. Jason and Ryan continue this month's discussion on putting out fires on Sunday morning. To learn more about Praise Charts, visit www.praisecharts.com.

Join Jason Squires as he sits down and chats with the Ryan Dahl, the founder of PraiseCharts. Jason and Ryan continue this month's discussion on putting out fires on Sunday morning. To learn more about Praise Charts, visit www.praisecharts.com.

Join Jason Squires as he sits down and chats with the Ryan Dahl, the founder of PraiseCharts. Jason and Ryan continue this month's discussion on putting out fires on Sunday morning. To learn more about Praise Charts, visit www.praisecharts.com.

Deno is a “modern” runtime for JavaScript and TypeScript that is built in Rust. This makes it very fast! If you are familiar with Node.js then you will be right at home with Deno. It is very similar but has some improvements over Node.js. In fact, the creator of Deno, Ryan Dahl, also created Node and Deno is meant to be the successor to Node.js. Jesse Hall joins Michael to talk about Deno and MongoDB. Check out the article Jesse wrote which covers this topic in more detail.  Checkout Jesse's Video on the topic, on YouTube.

Ryan Dahl, the Founder of PraiseCharts, joins LC Founder Matt McCoy to talk about three things he wish he knew when he started leading worship! The post 089 – Three Things I Wish I Knew When I Started Leading Worship w/ Ryan Dahl first appeared on WorshipFuel.

Ryan Dahl, the Founder of PraiseCharts, joins LC Founder Matt McCoy to talk about three things he wish he knew when he started leading worship!

This week we're joined by Ryan Dahl, Node.js creator, and now the creator of Deno - a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. We talk with Ryan about the massive success of Node and how it impacted his life, and how he eventually created Deno and what he's doing differently this time around. We also talk about The Deno Company and what's in store for Deno Deploy.

This week we're joined by Ryan Dahl, Node.js creator, and now the creator of Deno - a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. We talk with Ryan about the massive success of Node and how it impacted his life, and how he eventually created Deno and what he's doing differently this time around. We also talk about The Deno Company and what's in store for Deno Deploy.

In the first of this new series, Luke and Ryan Dahl from Praisecharts talk about the lyrical content, musicality and stories behind the latest worship songs!   Listen to the songs here: http://bit.ly/Churchfront-New-Worship-Song-Review_AppleMusic http://bit.ly/Churchfront-New-Worship-Music-Review_Spotify   praisecharts.com/live worshipministryschool.com

In this episode, Ryan Dahl from PraiseCharts sits down with Matt, Derek and Slack from Loop Community to discuss the upcoming Worship Innovators Conference. This virtual conference is happening on June 7 and will be a great day of practical training for worship leaders. Learn more about the conference in this episode and then sign... View Article The post 087 – The Worship Innovators Conference w/ Ryan Dahl first appeared on WorshipFuel.

In this episode, Ryan Dahl from PraiseCharts sits down with Matt, Derek and Slack from Loop Community to discuss the upcoming Worship Innovators Conference. This virtual conference is happening on June 7 and will be a great day of practical training for worship leaders. Learn more about the conference in […]

The creator of Node.js, Ryan Dahl, released a new shiny runtime for Javascript and TypeScript in 2018 called Deno. Release 1.0 finally came out in 2020, and eager developers flocked to use Deno in production. Or did they? In this TechWeeklies talk, Minna briefly introduces the features and design aims of Deno. Then she addresses the obligatory question "how does it compare to Node?". The talk also includes a live coding demo to showcase how easy it is to use Deno for your daily ad-hoc scripting needs.   Presenter: Minna Niemi  

The creator of Node.js, Ryan Dahl, released a new shiny runtime for Javascript and TypeScript in 2018 called Deno. Release 1.0 finally came out in 2020, and eager developers flocked to use Deno in production. Or did they? In this TechWeeklies talk, Minna briefly introduces the features and design aims of Deno. Then she addresses the obligatory question "how does it compare to Node?". The talk also includes a live coding demo to showcase how easy it is to use Deno for your daily ad-hoc scripting needs.   Presenter: Minna Niemi  

Ruby has gone off the rails this week, and Wes is here to explain what’s happened. Plus emails into the show send Chris into a full Linux panic.

Praise Charts founder Ryan Dahl joins the podcast to talk about creating positive team culture and finding songs for every worship moment. He also talks a lot about corn hole. Jason and Daniel discuss positive creative perspective.

Praise Charts founder Ryan Dahl joins the podcast to talk about creating positive team culture and finding songs for every worship moment. He also talks a lot about corn hole. Jason and Daniel discuss positive creative perspective.

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 6.1.3 has been released Rails 6.1 adds query method associated to check for the association presence A more secure bundler: We fixed our source priorities (Revert disable_multisource changes) The Monotonic Clock and Why You Should Care About It Neighbor - nearest neighbor search for Rails and Postgres Prosopite is able to auto-detect Rails N+1 queries with zero false positives / false negatives Twterm - a full-featured TUI Twitter client Web Announcing Vite 2.0 Interview with Ryan Dahl, Creator of Node.js Avoiding npm substitution attacks Hiding Content Responsibly Metascraper is library to easily scrape metadata from an article on the web using Open Graph metadata, regular HTML metadata, and series of fallbacks A11y Dialog NetplayJS - make P2P multiplayer games in Javascript, no server hosting required

Wer sein Studium abbricht, um ins Denoland zu gehen, hat sicher eine interessante Geschichte zu erzählen. Aus diesem Grund haben wir in dieser Folge Luca Casonato zu Gast, der uns von Deno erzählt, einer Laufzeitumgebung für JavaScript und TypeScript. Deno wurde 2018 von Ryan Dahl, dem Schöpfer von Node.js, auf der JSConf EU vorgestellt (hier geht's zur Aufzeichnung des Talks). Er beschreibt darin fundamentale Schwächen von Node, die er bereut und nun mit Deno lösen möchte. Unser Gast Luca arbeitet als eine der wenigen Personen hauptsächlich am Projekt und spricht mit uns über die größten Unterschiede zwischen den beiden Varianten. In dieser Folge streifen wir das Dependency-Management von Deno, seine Eigenschaften als opinionated Runtime und seine hohe Sicherheit gegenüber Node. Hier kommt ihr zu Lucas Webseite und seinem Twitter-Profil. Auf der Webseite von Deno könnt ihr euch noch mehr Infos einholen. Picks of the Day Luca: Die Deno-Extension für Visual Studio Code mit cooler Autocompletion. Fabi: JSConf Vortrag von Philip Roberts: What the Heck is the Event Loop anyway. Ein Must-Watch für alle Javascript-EntwicklerInnen. Ihr habt euch schon immer gefragt, was die Event Loop ist bzw. wie sie funktioniert? Dann ist das Video genau richtig. Ansonsten ist es aber auch nochmal die perfekte, unterhaltsame Auffrischung, um die Event Loop komprimiert in 25 Minuten erklärt zu bekommen. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback. podcast@programmier.bar Folgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. Twitter Instagram  Facebook Meetup YouTube Musik: Hanimo 

In September of 2008, Google's Chromium Project released V8, a JavaScript engine, as part of a browser optimization wave that heralded the era of JavaScript browser applications that we both love, and love to hate. Less than a year later, in 2009, Ryan Dahl announced (at this very conference!) a way to run the V8 browser environment outside of the browser- Node.js, a platform that held the promise of unifying web application development, where both client and server side development could happen in the same language - JavaScript. A decade later, V8, JavaScript, and its new buddy WebAssembly, have expanded to lands charted only a few years after Node.js debuted- known (confusingly) as the “Edge”. In this talk, we'll introduce what the “Edge” is and why we are excited for it to revolutionize computation on the web. We'll explore how this adventurous JavaScript engine, V8, is so well suited to tasks previously limited to Virtual Machines, Containers, or even simply Operating Systems. Finally, we'll talk about security, Spectre, and ask ourselves the age old question, “You can do it, but should you?”.

Learn more at https://denocode.com Deno is a Javascript and Typescript runtime from the creator of Node.js For anyone that doesn't know Node.js is a server-side Javascript runtime. It's used by millions of projects across the globe and powers the backends and API's of many of the world's leading websites. Then came Deno (aka Deno.js or Deno JS), an improved and updated runtime that is quick, more secure and modern. Created by Ryan Dahl (who was the original creator of Node.js) the project was started in 2018 and has reached a stage where it's become a serious competitor to the Node ecosystem. From my blog at: https://jamesbachini.com/deno-js/

O mundo de JavaScript mais uma vez muda tudo, surge um competente substituto ao Node.js, o Deno. Ele terá futuro? Funciona bem? O que é bom, o que precisa melhorar? Comentamos tudo neste episódio. Feed do podcast: www.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: www.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos: www.lambda3.com.br/feed/podcast-nao-tecnico Lambda3 · #200 - Deno Pauta: O que é Deno Como pronuncia? Vai substituir o Node.js? História Os 7 arrependimentos Dependências e compatibilidade dos módulos TypeScript será o principal foco do Deno? Como está o suporte a TypeScript no Deno Como está a experiência de desenvolvimento com Deno Suporte de editor de texto/IDE Testes automatizados Ferramentas de build Serviços em nuvem Standard Library do Deno Como migrar projetos Node.js Quanto de conhecimento é aproveitado do Node.js para o Deno Qual será o futuro do Node.js e do Deno Links Citados: Site do Deno Video do Ryan Dahl falando dos 10 arrependimentos (que são só 7) Palestra "Simple made easy" de Rich Hickey no InfoQ Participantes: Andre Valenti – @awvalenti Giovanni Bassi - @giovannibassi Lucas Teles – @lucasteles42 William Grasel – @willgmbr Edição: Compasso Coolab Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 - creativecommons.org/licenses/by/3.0

Deno is a secure runtime for JavaScript & TypeScript created by the creator of Node.js (Ryan Dahl). David Else, software developer at Else Web Development, has been working with the project for a while aND talks with Danny and Erik about the latest Deno release. Visit the website for This Week in Web, resources & more: https://thewebplatformpodcast.com/199-deno   Follow The Web Platform podcast on Twitter for regular updates @TheWebPlatform.

In this episode, Lindsay, Steve, and Austin talk with Gregg Pollack of Vue Mastery about his course with Evan You on the new reactivity model in Vue 3. We also discuss the Composition API, and whether it is the right decision to use. At the end, we discuss marketing and building up an audience for your own video courses. Panel Steve Edwards Lindsay Wardell Austin Gil Guest Gregg Pollack "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! Links Vue 3 Overview - Vue 3 Deep Dive with Evan You | Vue Mastery Why the Composition API - Vue 3 Essentials | Vue Mastery Creating the Best Video Programming Tutorials | Vue Mastery Reflect - JavaScript | MDN Proxy - JavaScript | MDN Picks Gregg Pollack: Follow Gregg on Twitter > @greggpollack, email: gregg@vuemastery.com Westworld Star Trek: Picard Austin Gil: Follow Austin on Twitter > @Stegosource JSDoc @ts-check jsconfig.json Lindsay Wardell: Follow Lindsay on Twitter > @Yagaboosh Deno 1.0 10 Things I Regret About Node.js - Ryan Dahl Steve Edwards: Follow Steve on Twitter > @wonder95 Pink Floyd: A Momentary Lapse of Reason Follow Views on Vue on Twitter > @viewsonvue

In this episode, Lindsay, Steve, and Austin talk with Gregg Pollack of Vue Mastery about his course with Evan You on the new reactivity model in Vue 3. We also discuss the Composition API, and whether it is the right decision to use. At the end, we discuss marketing and building up an audience for your own video courses. Panel Steve Edwards Lindsay Wardell Austin Gil Guest Gregg Pollack "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! Links Vue 3 Overview - Vue 3 Deep Dive with Evan You | Vue Mastery Why the Composition API - Vue 3 Essentials | Vue Mastery Creating the Best Video Programming Tutorials | Vue Mastery Reflect - JavaScript | MDN Proxy - JavaScript | MDN Picks Gregg Pollack: Follow Gregg on Twitter > @greggpollack, email: gregg@vuemastery.com Westworld Star Trek: Picard Austin Gil: Follow Austin on Twitter > @Stegosource JSDoc @ts-check jsconfig.json Lindsay Wardell: Follow Lindsay on Twitter > @Yagaboosh Deno 1.0 10 Things I Regret About Node.js - Ryan Dahl Steve Edwards: Follow Steve on Twitter > @wonder95 Pink Floyd: A Momentary Lapse of Reason Follow Views on Vue on Twitter > @viewsonvue

En este episodio te cuento que es Deno, sus principales características y diferencias con Node y descubrimos si Node tiene o no los días contados.Deja tu comentario idea o feedback como un mensaje de voz en https://www.speakpipe.com/CafeConTech y tu voz estará en el showO sigamos la conversación en redes sociales, encuentrame en instagram y twitter como @cafe_contech o en el email cafecontechpodcast@gmail.com.Y recuerda que https://www.instagram.com/primatestostadores/ te regalan un 10% de descuento al usar el código cafecontechLinksDeno http://deno.land/Ryan Dahl - 10 Things I regret about nodejs https://www.youtube.com/watch?v=M3BM9TB-8yAMás sobre V8: https://hackernoon.com/javascript-v8-engine-explained-3f940148d4efMás sobre Rust: https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/Tokio: https://tokio.rsMúsicaOpening and Outro Music by DanoSongs https://danosongs.com/Background Music Music:Thief in the Night by Kevin MacLeodLink: https://incompetech.filmmusic.io/song/4521-thief-in-the-nightLicense: http://creativecommons.org/licenses/by/4.0/Support the show (https://www.buymeacoffee.com/matiasfha)

Dal creatore di node.js Ryan Dahl, Deno il runtime per javascript e typescript che colma le carenze di node e ne indirizza gli sviluppi futuri.Security by default, all''avvio della nostra applicazione definiamo i diritti che questa dovrà avere sul sistema: accedere alla rete, al disco e il nostro software ci garantisce una maggiore tranquillità.Un nuovo modo di gestire le dipendenze.Tante altre novità che si propongono di stravolgere il mondo del javascript.## Links- https://www.infoworld.com/article/3529779/what-is-deno-a-better-nodejs.html- https://academind.com/learn/node-js/denojs-first-look/- https://youtu.be/8CtFu4xtuj0- https://www.freecodecamp.org/news/the-deno-handbook/- https://medium.com/@HolyJSconf/ryan-dahl-d139d8a8fb07- https://www.freecodecamp.org/news/the-deno-handbook/- https://blog.begin.com/testing-in-deno-the-basics-943916d85224- https://github.com/swc-project/swc## Contatti@brainrepo su twitter o via mail a info@gitbar.it## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPN e Broke For Free - Something Elated

A Rust-based Node.js alternative is exciting developers while the language itself celebrates its fifth birthday, the Maui Project unveils its first stable toolkit, Mozilla rolls back Lockwise integration with operating system passwords, and Finnix lands its first new edition in five years.

This episode was recorded Thursday, May 9th, two days after Stack Overflow announced it was going to furlough 15% of its staff. We talk about how this process played out internally and the ways in which we are hoping to grow our business so we can bring these great people back. You can read more about it in a blog post from our CEO here.After that, we discuss Zoom's acquisition of Keybase. Usage and wider public awareness of Zoom have been growing by leaps and bounds as the world shifts to remote work and learning during this pandemic. This has exposed some security issues with Zoom's platform, and the acquisition of Keybase seems to be aimed at shoring up their cybersecurity and encryption capabilities. Sara, never one to miss an opportunity to plug Bitcoin, hips us to The Halvening. What does it all mean? Read more about it here.Finally, Paul walks us through Deno, which was created by Ryan Dahl, who also created Node.js. Deno is  "a brand new JavaScript runtime for the backend, but instead of being written in C++, it’s written in Rust, based on the Tokio platform (which provides the asynchronous runtime needed by JavaScript), still running Google’s V8 engine though." You can read more about it here.Our lifeboater of the week is Stack Overflow user James Kanze, who was awarded the badge for answering the question: C++: What is the difference between ostream and ostringstream?Thanks for listening :)

This episode was recorded Thursday, May 9th, two days after Stack Overflow announced it was going to furlough 15% of its staff. We talk about how this process played out internally and the ways in which we are hoping to grow our business so we can bring these great people back. You can read more about it in a blog post from our CEO here.After that, we discuss Zoom's acquisition of Keybase. Usage and wider public awareness of Zoom have been growing by leaps and bounds as the world shifts to remote work and learning during this pandemic. This has exposed some security issues with Zoom's platform, and the acquisition of Keybase seems to be aimed at shoring up their cybersecurity and encryption capabilities. Sara, never one to miss an opportunity to plug Bitcoin, hips us to The Halvening. What does it all mean? Read more about it here.Finally, Paul walks us through Deno, which was created by Ryan Dahl, who also created Node.js. Deno is  "a brand new JavaScript runtime for the backend, but instead of being written in C++, it's written in Rust, based on the Tokio platform (which provides the asynchronous runtime needed by JavaScript), still running Google's V8 engine though." You can read more about it here.Our lifeboater of the week is Stack Overflow user James Kanze, who was awarded the badge for answering the question: C++: What is the difference between ostream and ostringstream?Thanks for listening :)

In this episode of Syntax, Scott and Wes talk about how to get better at problem solving — one of the most important skills to build as a developer. Netlify - Sponsor Netlify is the best way to deploy and host a front-end website. All the features developers need right out of the box: Global CDN, Continuous Deployment, one click HTTPS and more. Hit up netlify.com/syntax for more info. Prismic - Sponsor Prismic is a Headless CMS for your next front end project. Create complex content type, relate data, and have your clients edit it all with the Prismic UI. Then pull the data into your project with their JSON or GraphQL API. Try it out with your next project - Gatsby, React + Apollo, or any other language. Check out their examples to get you started at Prismic.io/syntax. Show Notes 2:43 - Gather info What is this thing trying to do? Use tools DevTools are your best friend during this phase 8:01 - Know where to look (and use tools) Dev tools for client side Error logs Sentry LogRocket The most experienced people in any field know how to ask the right questions. Some of this will come with experience and nothing else. If you’ve seen a problem before, it’s easier to solve. 10:00 - Look at the end game What are you really trying to do here? Don’t focus so much on the tech that you miss the bigger picture. 13:17 - Read Again Error logs provide the best clues. Read them closely. Actually read your code — don’t skim it. Write comments while reading it, or follow existing comments — good for documenting, but also for structuring your thoughts. 18:08 - Make it simple (break it into smaller parts) Limit the number of inputs and outputs Get it working in a limited capacity (e.g. safe mode, Codepen, etc.) Comment out major sections of code until you have a working example Does this problem exist outside of the framework? Does this work in a clean environment? 25:35 - Take yourself out of your environment You should be able to take a look at the problem at all zoom levels Does it work locally but not on the server? Does it work in other browsers? 27:32 - Stay calm It’s easy to get nervous or worked up when the stakes are high It won’t serve you to panic. If you are panicking, take a 10 min walk to deep breath Take a shower, lift weights (seriously) 30:14 - Talk it over Getting the perspective of another developer can be invaluable 32:28 - Make things obvious Use debugger or label logs — don’t let it be ambiguous For CSS bugs, use primary colors to make things stand out Use the right tool to make the problem stand out Layers for CSS issues Network for network issues Performance tab (etc.) 35:12 - Use Git correctly to free up your techniques If you’re code commits are up to date, you can heavily modify code without fear of deleting things — just revert to a previous commit once you find the issue and fix. 36:10 - Don’t jump at solutions Take the time to fully dissect the problem Question you assumptions It can’t possibly be a problem with ____. Well maybe it is. Wes once spent hours trying to diagnose a check engine light when the gas cap was lose. 43:51 - Get good at pattern matching This comes with experience When did this problem start? Did we deploy any code? Did we change any logic? 44:54 - Get good at googling Being able to describe your problem is key. Search the error from Firefox Links DevTools Sentry LogRocket CodePen Syntax 154: SVGs with Sara Soueidan @walpolea Syntax 152: Debugging Tools + Tips @bowlendev @dan_abramov Ryan Dahl on creating Node.js @LaurieonTech Firefox DuckDuckGo ××× SIIIIICK ××× PIIIICKS ××× Scott: Jeremy Ethier Youtube Channel Wes: Marpac Rohm Sound Machine Shameless Plugs Scott: Typescript in React Course - Sign up for the year and save 25%! Wes: Beginner Javascript Course Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

Today's guest is Ryan Dahl, bass player for the band Go Murphy! Besides chatting about Ryan's music, most of this episode is devoted to an epic adventure to Cuba Ryan took (on a tiny sailboat) almost twenty years ago! Help us keep the lights on by donating to our Patreon! www.patreon.com/jjmeetsworld

The Belgian Waffle Show is back and we are going to catch up with our Hardman winner Ryan Dahl. Ryan clearly qualifies for this award with his story on how he came back from a broken neck in less than a year to be fit & ready for the full Waffle. You will also hear from the man behind the BWR as Michael Marckx  discusses why Ryan deserves this award and possible future plans for the Belgian Waffle Ride in 2020. @BelgianWaffleRide

In this session, Jake interviews Ryan Dahl, the founder of PraiseCharts. He shares the story behind this amazing resource for worship ministries and tips for better resourcing your team. Check out PraiseCharts - www.praisecharts.com Join Worship Leader School - www.worshipleaderschool.com  

Simple Programmer is now BACK with a brand new YouTube ChannelSUBSCRIBE HERE: https://simpleprogrammer.com/subscribespyt   You're going for your next coding interview for a node.js job. Then, you should expect lots of different questions regarding node.js. What do you do then? Why don't so many developers still don't prepare for questions about programming language and stuff? Node.js framework is actually not a framework or a library, but a runtime environment, based on Chrome’s V8 JavaScript engine. The technology was first introduced back in 2009 by Ryan Dahl at the annual European JSConf and was immediately recognized as “the most exciting single piece of software in the current JavaScript universe”. However, it wasn’t until recently that a wide adoption of server-side JavaScript with Node.js started. The interest in this technology peaked in 2014, as per Google Trends, and remains high. (Source: https://www.altexsoft.com/blog/engineering/the-good-and-the-bad-of-node-js-web-app-development/) In this case, you definitely should be prepared to answer questions like what are the pros & cons of node.js, what is node.js, and more. Answers should look like this: "Using Node.js for backend, you automatically get all the pros of full stack JavaScript development, such as: better efficiency and overall developer productivity code sharing and reuse speed and performance easy knowledge sharing within a team huge number of free tools" In today's video we'll go through some Q&A about node.js and how you can nail your next coding interview applying for a node.js position.

On today's episode, the BBR crew tastes and reviews some porters, and educates on the difference between porters and stouts. We sample Leinenkugel's Snow Drift Vanilla Porter, Junkyard's Scout Camp Barrel-aged Porter, Summit's Great Northern Porter, Deschute's Black Butte Porter, Empyrean's Long Route Peanut Butter Porter, and Ommegang's Mother of Dragons. This has been a Predakit Productions episode of Brews, Booze, & Reviews! If you have any questions or comments, please feel free to email us at brewsboozeandreviews@hotmail.com. We here at the dungeon also want to give thanks to Todd Ruzicka and Aimee Klein from Beware the Vine for permission to use their song Sex, Drugs, and Cabaret off of the album of the same name. If you like the song and want to hear more from Beware the Vine, or wish to buy any songs, you can go to https://store.cdbaby.com/cd/bewarethevine and make your purchases there! We also want to give thanks to Ryan Dahl for his fantastic graphic design work in creating our logos. If you like this episode and want to hear more, please rate and review our podcast. We appreciate the feedback we get from our listeners in helping us make better content for future episodes. On behalf of everyone at Brews, Booze, & Reviews, may your glasses be full, and your spirits high! Cheers! --- Support this podcast: https://anchor.fm/brews-booze-and-reviews/support

"Faktolero"; "The Very Slow Movie Player"; IT-Keller ist für den Podcastpreis 2019 in der Kategorie Technik (Abstimmung bis 15.02.2019 möglich) nominiert; "10 Things I Regret About Node.js" - Ryan Dahl; Aua-uff-Code! Episode 31; Easterhegg 2019; FaceTime-Bug; Debian auf Gemini PDA; Gemini Partition Tool; Planet Computers Cosmo Communicator; Elementary OS; Vala (Programmiersprache); Office 365 vs. Office 2019; Wir löschen unsere Facebook-Accounts; "3 Schweinehunde"-Podcast (Hörer:innenläufe in Wien und Köln) und Laufgadgets (Stryd-Sensor, ANT Funknetzwerkstandard, FIT Dateiformat, GoldenCheetah); Wir haben keine Ahnung, wie sich eine mögliche Polumkehr auswirkt; PyDays Vienna, 3. bis 4. Mai 2019 (Call for Participation); Podcasting Meetup Österreich, 8. März 2019 Gäste: Bernhard, Stefan und Ulrich

Recording date: 2018-10-25 Tweet John Papa https://twitter.com/john_papa Ward Bell https://twitter.com/wardbell Dan Wahlin https://twitter.com/dan wahlin Tierney Cyren https://twitter.com/bitandbang Show Notes: (0:01:11) Ward reads the mailbag about Node versioning (0:01:39) Tierney talks about Node.js versioning https://nodejs.org/en/ (0:01:56) Tierney discusses the Node.js LTS schedule (0:02:18) Ward asks how he would go about moving from v8 to v10 of Node.js (0:02:48) John asks if the code needs to change or just recompile (0:04:40) Tierney explains the node.js release lines work https://nodesource.com/blog/understanding-how-node-js-release-lines-work/ (0:05:10) Tierney explains there can be more than one active LTS at a time (0:05:39) John dsicusses how the Node.js LTS chart is helpful https://github.com/nodejs/Release#release-schedule (0:06:10) Ward asks what is he missing if he doesn;t move to a new release (0:06:30) Tierney explains vthat you may miss vulnerability patches (0:07:30) Tierney explains how he recommends thinking about how long you should stay on a release line (0:08:10) Tierney says Laurie Voss https://twitter.com/seldo of npm had a talk about the Fortune 50 companies who use Node.js (0:08:46) Ward asks what the relationship is between Node.js and npm (0:09:00) Tierney says npm is a company https://npmjs.com (0:09:39) Tierney mentions Isaac - CEO of npm https://twitter.com/izs?lang=en (0:12:32) John asks Tierney what the performance is of Node.js (0:14:11) Tierney talks about how LinkedIn used Node.js (0:14:33) Tierney says Paypal is the largest public deployment of Node.js on the planet (0:14:50) Tierney says Walmart uses Node.js which helps them with Black Friday sales (0:16:04) tc39 spec https://tc39.github.io/ecma262/ (0:16:48) Node.js performance tips https://www.smashingmagazine.com/2018/06/nodejs-tools-techniques-performance-servers/ (0:17:01) Ward asks what level of javascript features are implemented in Node.js (0:17:40) Tierney talks about ESM (module system) (0:19:40) John and Tierney talk about tools for application performance monitoring (0:21:04) New Relic and AppDynamics are great tools for this (0:21:40) Tierney talks about when the event loop is blocked (0:21:45) JSON.parse can sneak up on you, as it blocks the event loop (0:22:46) NSolid is a replacement for node.js runtime - does perf monitoring too https://nodesource.com/products/nsolid (0:22:50) John asks if you can use NSolid for production deployments without slow-downs (0:22:50) Tierney talks about the performance impact of using NSolid for monitoring (0:23:30) John talks about an AST http://www.syntaxsuccess.com/viewarticle/javascript-ast (0:26:10) Async hooks is a new tool that ships in node that pulls data out to help APM's (App Performance Monitoring) help get data (0:27:00) Ward asks if there are tools that will check for anti patterns, for CI (0:27:50) Tierney talks about tools that NodeSource has written to help look for issues in Node code (certified modules) (0:28:57) ncm-ci is the tool https://github.com/nodesource/ncm-ci (0:29:11) Ward mentions tools like Lighthouse for chrome https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=en (0:29:15) Tierney commits to writign Lighthouse for Node.js by the end of the podcast (jokingly) (0:30:32) Greenkeeper is a github integration app that auto checks dependencies https://greenkeeper.io/ and analyzes your npm package (0:31:09) Snyk looks for security vulnerabilities in packages https://snyk.io (0:32:01) Node awesome list https://github.com/sindresorhus/awesome-nodejs (0:33:14) Tierney has his own list for Node.js https://github.com/bnb/awesome-awesome-nodejs (0:33:30) Ward asks Tierney whaat the top 10 Node.js tools everyone needs (0:36:00) Ward says he is looking for a middle ground between all of the tools and just the most important tools (0:37:49) John asks what you can do to secure Node.js apps (0:39:50) Tierney talks about how you can submit vulnerabilities to https://hackerone.com/nodejs-ecosystem (0:40:09) John asks Tierney about npm vs yarn (0:50:51) Yarn https://yarnpkg.com/en/ (0:42:20) Tierney talks about his interest in Go https://golang.org/ (0:43:30) Tierney talks about how Ryan Dahl created Node.js https://jaxenter.com/ryan-dahl-fixing-node-deno-146190.html (0:45:01) Someone to follow - Dave Geddes at https://gedd.ski/ (0:45:58) Someone to follow - Sherry List https://twitter.com/sherrrylst (0:46:41) Someone to follow - Franziska Hinkelmann https://twitter.com/fhinkel Resources Node.js Everywhere with Environment Variables https://medium.com/the-node-js-collection/making-your-node-js-work-everywhere-with-environment-variables-2da8cdf6e786 by John Papa Eleven Tips to Scale Node.js https://medium.com/microsoftazure/eleven-tips-to-scale-node-js-65cbf6deef6e by Brian Holt async await in Node.js https://blog.risingstack.com/mastering-async-await-in-nodejs/ Certified Modules from Node Source https://nodesource.com/products/certified-modules Blog posts by Tierney https://nodesource.com/blog/author/bitandbang Node Collection - medium blog https://medium.com/the-node-js-collection Tierney says use security tools like helmet https://github.com/helmetjs/helmet Ryan Dahl - creator of Node http://tinyclouds.org/ npm audit in ci system https://docs.npmjs.com/getting-started/running-a-security-audit WardInSpace: https://docs.npmjs.com/cli/audit NPM Audit Node security working group https://medium.com/the-node-js-collection/meet-the-node-js-security-working-group-30b9f00b678 WardInSpace: Node Security Working Group https://github.com/nodejs/security-wg Tierney-Cyren: https://internetbugbounty.org/ WardInSpace: https://www.rust-lang.org/en-US/ Rust

Panel Brendan Eich Joe Eames Aaron Frost AJ ONeal Jamison Dance Tim Caswell Charles Max Wood Discussion 01:57 – Brendan Eich Introduction JavaScript [Wiki] Brendan Eich [Wiki] 02:14 – Origin of JavaScript Java Netscape Jim Clark Marc Andreesen NCSA Mosaic NCSA HTTPd Lynx (Web Browser) Lou Montulli Silicon Graphics Kernel Tom Paquin Kipp Hickman MicroUnity Sun Microsystems Andreas Bechtolsheim Bill Joy Sun-1 Scheme Programming Language Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson, Gerald Jay Sussman & Julie Sussman Guy Steele Gerald Sussman SPDY Rob McCool Mike McCool Apache Mocha Peninsula Creamery, Palo Alto, CA Main () and Other Methods (C# vs Java) Static in Java, Static Variables, Static Methods, Static Classes 10:38 – Other Languages for Programmers Visual Basic Chrome Blacklist Firefox 12:38 – Naming JavaScript and Writing VMs Canvas Andrew Myers 16:14 – Envisioning JavaScript’s Platform Web 2.0 AJAX Hidaho Design Opera Mozilla Logo Smalltalk Self HyperTalk Bill Atkinson HyperCard Star Wars Trench Run 2.0 David Ungar Craig Chambers Lars Bak Strongtalk TypeScript HotSpot V8 Dart Jamie Zawinski 24:42 – Working with ECMA Bill Gates Blackbird Spyglass Carl Cargill Jan van den Beld Philips Mike Cowlishaw Borland David M. Gay ECMAScript Lisp Richard Gabriel 31:26 – Naming Mozilla Jamie Zawinski Godzilla 31:57 – Time-Outs 32:53 – Functions Clojure John Rose Oracle Scala Async.io 38:37 – XHR and Microsoft Flash Hadoop Ricardo Jenez Ken Smith Brent Noorda Ray Noorda .NET Shon Katzenberger Anders Hejlsberg NCSA File Formats 45:54 – SpiderMonkey Chris Houck Brendan Eich and Douglas Crockford – TXJS 2010 Douglas Crockford JavaScript: The Good Parts by Douglas Crockford TXJS.com ActionScript Flex Adobe E4X BEA Systems John Schneider Rhino JScript roku Waldemar Horwat Harvard Putnam Math Competition Chris Wilson Silverlight Allen Wirfs-Brock NDC Oslo 2014 JSConf Brendan JSConf Talks 59:58 – JavaScript and Mozilla GIP SSLeay Eric A. Young Tim Hudson Digital Styles Raptor Gecko ICQ and AIM PowerPlant CodeWarrior Camino David Hyatt Lotus Mitch Kapor Ted Leonsis Mitchell Baker David Baren Phoenix Tinderbox Harmony 1:14:37 – Surprises with Evolution of JavaScript Ryan Dahl node.js Haskell Elm Swift Unity Games Angular Ember.js Dojo jQuery react ClojureScript JavaScript Jabber Episode #107: ClojureScript & Om with David Nolen MVC 01:19:43 – Angular’s HTML Customization Sweet.js JavaScript Jabber Episode #039: Sweet.js with Tim Disney TC39 Rick Waldron 01:22:27 – Applications with JavaScript SPA’s Shumway Project IronRuby 01:25:45 – Future of Web and Frameworks LLVM Chris Lattner Blog Epic Games Emscripten Autodesk PortableApps WebGL 01:29:39 – ASM.js Dart.js John McCutchen Monster Madness Anders Hejlsberg, Steve Lucco, Luke Hoban: TypeScript 0.9 – Generics and More (Channel 9, 2013) Legacy 01:32:58 – Brendan’s Future with JavaScript Picks hapi.js (Aaron) JavaScript Disabled: Should I Care? (Aaron) Aaron’s Frontend Masters Course on ES6 (Aaron) Brendan’s “Cool Story Bro” (AJ) [YouTube] Queen – Don't Stop Me Now (AJ) Trending.fm (AJ) WE ARE DOOMED soundtrack EP by Robby Duguay (Jamison) Hohokum Soundtrack (Jamison) Nashville Outlaws: A Tribute to Mötley Crüe (Joe) Audible (Joe) Stripe (Chuck) Guardians of the Galaxy (Brendan)

Panel Brendan Eich Joe Eames Aaron Frost AJ ONeal Jamison Dance Tim Caswell Charles Max Wood Discussion 01:57 – Brendan Eich Introduction JavaScript [Wiki] Brendan Eich [Wiki] 02:14 – Origin of JavaScript Java Netscape Jim Clark Marc Andreesen NCSA Mosaic NCSA HTTPd Lynx (Web Browser) Lou Montulli Silicon Graphics Kernel Tom Paquin Kipp Hickman MicroUnity Sun Microsystems Andreas Bechtolsheim Bill Joy Sun-1 Scheme Programming Language Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson, Gerald Jay Sussman & Julie Sussman Guy Steele Gerald Sussman SPDY Rob McCool Mike McCool Apache Mocha Peninsula Creamery, Palo Alto, CA Main () and Other Methods (C# vs Java) Static in Java, Static Variables, Static Methods, Static Classes 10:38 – Other Languages for Programmers Visual Basic Chrome Blacklist Firefox 12:38 – Naming JavaScript and Writing VMs Canvas Andrew Myers 16:14 – Envisioning JavaScript’s Platform Web 2.0 AJAX Hidaho Design Opera Mozilla Logo Smalltalk Self HyperTalk Bill Atkinson HyperCard Star Wars Trench Run 2.0 David Ungar Craig Chambers Lars Bak Strongtalk TypeScript HotSpot V8 Dart Jamie Zawinski 24:42 – Working with ECMA Bill Gates Blackbird Spyglass Carl Cargill Jan van den Beld Philips Mike Cowlishaw Borland David M. Gay ECMAScript Lisp Richard Gabriel 31:26 – Naming Mozilla Jamie Zawinski Godzilla 31:57 – Time-Outs 32:53 – Functions Clojure John Rose Oracle Scala Async.io 38:37 – XHR and Microsoft Flash Hadoop Ricardo Jenez Ken Smith Brent Noorda Ray Noorda .NET Shon Katzenberger Anders Hejlsberg NCSA File Formats 45:54 – SpiderMonkey Chris Houck Brendan Eich and Douglas Crockford – TXJS 2010 Douglas Crockford JavaScript: The Good Parts by Douglas Crockford TXJS.com ActionScript Flex Adobe E4X BEA Systems John Schneider Rhino JScript roku Waldemar Horwat Harvard Putnam Math Competition Chris Wilson Silverlight Allen Wirfs-Brock NDC Oslo 2014 JSConf Brendan JSConf Talks 59:58 – JavaScript and Mozilla GIP SSLeay Eric A. Young Tim Hudson Digital Styles Raptor Gecko ICQ and AIM PowerPlant CodeWarrior Camino David Hyatt Lotus Mitch Kapor Ted Leonsis Mitchell Baker David Baren Phoenix Tinderbox Harmony 1:14:37 – Surprises with Evolution of JavaScript Ryan Dahl node.js Haskell Elm Swift Unity Games Angular Ember.js Dojo jQuery react ClojureScript JavaScript Jabber Episode #107: ClojureScript & Om with David Nolen MVC 01:19:43 – Angular’s HTML Customization Sweet.js JavaScript Jabber Episode #039: Sweet.js with Tim Disney TC39 Rick Waldron 01:22:27 – Applications with JavaScript SPA’s Shumway Project IronRuby 01:25:45 – Future of Web and Frameworks LLVM Chris Lattner Blog Epic Games Emscripten Autodesk PortableApps WebGL 01:29:39 – ASM.js Dart.js John McCutchen Monster Madness Anders Hejlsberg, Steve Lucco, Luke Hoban: TypeScript 0.9 – Generics and More (Channel 9, 2013) Legacy 01:32:58 – Brendan’s Future with JavaScript Picks hapi.js (Aaron) JavaScript Disabled: Should I Care? (Aaron) Aaron’s Frontend Masters Course on ES6 (Aaron) Brendan’s “Cool Story Bro” (AJ) [YouTube] Queen – Don't Stop Me Now (AJ) Trending.fm (AJ) WE ARE DOOMED soundtrack EP by Robby Duguay (Jamison) Hohokum Soundtrack (Jamison) Nashville Outlaws: A Tribute to Mötley Crüe (Joe) Audible (Joe) Stripe (Chuck) Guardians of the Galaxy (Brendan)

Panel Brendan Eich Joe Eames Aaron Frost AJ ONeal Jamison Dance Tim Caswell Charles Max Wood Discussion 01:57 – Brendan Eich Introduction JavaScript [Wiki] Brendan Eich [Wiki] 02:14 – Origin of JavaScript Java Netscape Jim Clark Marc Andreesen NCSA Mosaic NCSA HTTPd Lynx (Web Browser) Lou Montulli Silicon Graphics Kernel Tom Paquin Kipp Hickman MicroUnity Sun Microsystems Andreas Bechtolsheim Bill Joy Sun-1 Scheme Programming Language Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson, Gerald Jay Sussman & Julie Sussman Guy Steele Gerald Sussman SPDY Rob McCool Mike McCool Apache Mocha Peninsula Creamery, Palo Alto, CA Main () and Other Methods (C# vs Java) Static in Java, Static Variables, Static Methods, Static Classes 10:38 – Other Languages for Programmers Visual Basic Chrome Blacklist Firefox 12:38 – Naming JavaScript and Writing VMs Canvas Andrew Myers 16:14 – Envisioning JavaScript’s Platform Web 2.0 AJAX Hidaho Design Opera Mozilla Logo Smalltalk Self HyperTalk Bill Atkinson HyperCard Star Wars Trench Run 2.0 David Ungar Craig Chambers Lars Bak Strongtalk TypeScript HotSpot V8 Dart Jamie Zawinski 24:42 – Working with ECMA Bill Gates Blackbird Spyglass Carl Cargill Jan van den Beld Philips Mike Cowlishaw Borland David M. Gay ECMAScript Lisp Richard Gabriel 31:26 – Naming Mozilla Jamie Zawinski Godzilla 31:57 – Time-Outs 32:53 – Functions Clojure John Rose Oracle Scala Async.io 38:37 – XHR and Microsoft Flash Hadoop Ricardo Jenez Ken Smith Brent Noorda Ray Noorda .NET Shon Katzenberger Anders Hejlsberg NCSA File Formats 45:54 – SpiderMonkey Chris Houck Brendan Eich and Douglas Crockford – TXJS 2010 Douglas Crockford JavaScript: The Good Parts by Douglas Crockford TXJS.com ActionScript Flex Adobe E4X BEA Systems John Schneider Rhino JScript roku Waldemar Horwat Harvard Putnam Math Competition Chris Wilson Silverlight Allen Wirfs-Brock NDC Oslo 2014 JSConf Brendan JSConf Talks 59:58 – JavaScript and Mozilla GIP SSLeay Eric A. Young Tim Hudson Digital Styles Raptor Gecko ICQ and AIM PowerPlant CodeWarrior Camino David Hyatt Lotus Mitch Kapor Ted Leonsis Mitchell Baker David Baren Phoenix Tinderbox Harmony 1:14:37 – Surprises with Evolution of JavaScript Ryan Dahl node.js Haskell Elm Swift Unity Games Angular Ember.js Dojo jQuery react ClojureScript JavaScript Jabber Episode #107: ClojureScript & Om with David Nolen MVC 01:19:43 – Angular’s HTML Customization Sweet.js JavaScript Jabber Episode #039: Sweet.js with Tim Disney TC39 Rick Waldron 01:22:27 – Applications with JavaScript SPA’s Shumway Project IronRuby 01:25:45 – Future of Web and Frameworks LLVM Chris Lattner Blog Epic Games Emscripten Autodesk PortableApps WebGL 01:29:39 – ASM.js Dart.js John McCutchen Monster Madness Anders Hejlsberg, Steve Lucco, Luke Hoban: TypeScript 0.9 – Generics and More (Channel 9, 2013) Legacy 01:32:58 – Brendan’s Future with JavaScript Picks hapi.js (Aaron) JavaScript Disabled: Should I Care? (Aaron) Aaron’s Frontend Masters Course on ES6 (Aaron) Brendan’s “Cool Story Bro” (AJ) [YouTube] Queen – Don't Stop Me Now (AJ) Trending.fm (AJ) WE ARE DOOMED soundtrack EP by Robby Duguay (Jamison) Hohokum Soundtrack (Jamison) Nashville Outlaws: A Tribute to Mötley Crüe (Joe) Audible (Joe) Stripe (Chuck) Guardians of the Galaxy (Brendan)

Welcome back to Acronyminizable (or is it Acronymizable?)! Nach kurzer Sprachverwirrung heute wieder mit diversen Themen, so wie sonst auch. u.a. Webtechnologien, wohlwollenden Diktatoren und öffentlichem Nahverkehr. Shownotes Öffi (und ÖPNV Navigator) IP-KOM-ÖV Video AppStore Review Guidelines History Apple fixes other apps https://twitter.com/shafikyaghmour/status/1018148796432171009 CSS: A new kind of JavaScript squirt.io ist wohl verschwunden, aber spritz gibt es noch BeeLine Reader freakshow 220 On my misalignment with Apple's love affair with Swift - monkeydom tc39 panel auf jsconf2018 dev.tube https://tc39.github.io/beta/ java 10 kriegt type inference kilians esolang talk any vs unknown in typescript 3.0 eslint postmortem 10 Dinge die Ryan Dahl an Node.js bereurt deno ain't node.jos NaDDPod actix-web https://github.com/actix/actix-web/issues/289 stars https://github.com/huginn/huginn not hugin http://hugin.sourceforge.net/ https://rclone.org unison https://github.com/dflemstr/type-info https://github.com/yingDev/Tickeys

Recently, there was an issue with eslint-scope that gave the JavaScript community a good scare. I wrote about it one day after it happened os feel free to go and read the article here: https://oprea.rocks/blog/fix-eslint-scope-backdoor The gist was that some malicious third party was exfiltrating NPM auth tokens that it would probably later use to infect more packages in a ripple-like manner. What's even funnier is that while I was listening to Ryan Dahl's 2018 JSConf presentation, I heard him complain about a similar hypothetical situation with ESLint, namely, that it could take over your computer, due to Node's non-restrictive model with filesystem and network access. It's the first episode I've recorded in a while and I'd be happy if you would listen to it and give me some feedback. I'm going to publish a new episode each Tuesday so stay tuned.

Dans cet épisode, Guillaume et Emmanuel discutent GraalVM, Java LTS, MS-DOS, gVisor, GitHub et microframeworks. Enregistré le 14 juin 2018 Téléchargement de l’épisode LesCastCodeurs-Episode–191.mp3 News Correction Article de performance SpringBoot classique vs réactif L’article “SpringBoot 2 performance — servlet stack vs WebFlux reactive stack” est à prendre avec de grosses pincettes. Le client HTTP utilisé pour la version servlet est celui par défaut Java à base d’URLConnection. Pas de reused de la connection…. A 2500 users sur un benchmark IO bound avec un tel ratio wait/processing, il ne devrait pas avoir une telle différence de throughput. Nicolas Labro Langages GraalVM Les limitations de SubstrateVM Retour d’impression sur GraalVM GraalVM avec Play Framework Java 11 more than just features Replacing reflection with invokedynamic Librairies The rise of Microframeworks The state of Java/Kotlin Microframeworks in 2018 L’équipe de Grails a sorti un nouveau micro-framework, Micronaut, basé sur Netty et sans Spring, pour plus de légèreté Un workshop sur Micronaut pour démarrer avec Micronaut Est-ce qu’on a toujours besoin de Spock avec l’arrivée de JUnit 5 ? TL;DR : oui :-) Middleware JakartaEE is officially out Barre de progression de la contribution Oracle à Jakarta EE The state of Spring Java in 2018 Camel et Bean Validation débat Camel est l’option « no code » Infrastructure MS-DOS expliqué ! gVisor Product Manager de Google expliquant que gVisor est utilisé par App Engine et Cloud Functions Lancement de Skaffold pour automatiser le développement sur Kubernetes Skaffold sur Github Skaffold and Kaniko: Bringing Kubernetes to Developers Cloud Node 8 sur App Engine Web Angular 6 What’s new in Angular6 What’s new in Angular CLI 6.0 Les regrets de Ryan Dahl sur Node.JS (et lancement de son nouveau framework Deno) Article sur ses regrets On peut faire mieux que console.log() Outillage GitHub se fait gobber par Microsoft L’équipe Java Mission Control virée par Oracle Gradle 4.8 Méthodologies Hiérarchie et documentation Comment un agent public peut contribuer à l’Open Source Sécurité Custom domains on GitHub Pages gain support for HTTPS Vulnérabilité dans Git amenant à une exécution à distance Outils de l’épisode Byteman et injection de faute GitIgnore.io Outil de crowdcasting de Pierre Carion Rubrique débutant Crowdcast de Pierre Carion Pour un débutant qu’est-ce: les forces de Java ou de la JVM qui rend Java encore attractif bon choix pour commencer un projet en 2018 Conférences EclipseCon les 13 et 14 juin 2018 JHipster Conf le 21 juin DevFest Lille le 21 juin 2018 Voxxed Luxembourg le 22 juin 2018 Sunny Tech les 28 et 29 juin 2018 Jenkins User Conference le 28 juin 2018 Jug Summer Camp le 14 septembre 2018 - Le CfP est ouvert. Paris Web les 4, 5 et 6 octobre 2018 DevFest Nantes les 18 et 19 octobre 2018 - Le CfP est ouvert. Jenkins World Europe du 22 au 25 octobre 2018 à Nice - (utilisez le code JWAHERITIER pour obtenir 20% de réduction). VoxxedDays Microservices du 29 au 31 octobre 2018 DevFest Toulouse le 8 novembre 2018 Codeurs en Seine le 22 novembre 2018 Nous contacter Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/  

Big week! KBall, Nick, and JBall (nooch) dive deep in to the 2018 Node.js user survey results. What does it all mean?! They also review Ryan Dahl’s “10” regrets about Node and sound off on Microsoft’s assimilatio… err… acquisition of GitHub.

Big week! KBall, Nick, and JBall (nooch) dive deep in to the 2018 Node.js user survey results. What does it all mean?! They also review Ryan Dahl’s “10” regrets about Node and sound off on Microsoft’s assimilatio… err… acquisition of GitHub.