Podcasts about TypeScript

We sit down with Brendan Eich, the creator of JavaScript and CEO of Brave, to cover indirect prompt injection threats, why senior devs still can't trust AI-generated code, and how Brave is building agent security from scratch.We cover:- How Indirect Prompt Injection Actually Works- Why ChatGPT Silently Downgrades Your Security- Can Senior Devs Trust AI-Generated Code?- Brave's Agent Mode Defense System-The Future of Crypto Micropayments via Solana & NEAR- Why the AI Bubble Will Slowly Burst- Should Young People Still Study CS?Timestamps:00:00 Intro00:26 Brave's AI Integration & Leo01:00 Browser Knowledge Agents03:37 Indirect Prompt Injection Explained05:20 Brave's Agent Mode Security Layers07:13 AI-Generated Code: Can You Trust It?08:05 Using Claude, Cursor & Open Code at Brave11:09 Inventing JavaScript in 10 Days11:14 Hibachi, infiniFi Ads12:57 TypeScript's AI Feedback Loop13:06 Lean Engineering & Minimum Viable Product15:40 Should Young People Study CS?17:17 Vibe Coding & AI Slop17:32 Relay Ad18:05 Brave's Privacy-First AI Approach20:15 Crypto Agent Commerce & Security22:52 AI Hype, S-Curves & the Bubble23:04 Micropayments & the Death of SaaS24:31 Solana Settlement & NEAR Partnership26:25 Blockchain Privacy vs. Coinbase PanopticonWebsite: https://therollup.co/Spotify: https://open.spotify.com/show/1P6ZeYd...Podcast: https://therollup.co/category/podcastFollow us on X: https://www.x.com/therollupcoFollow Rob on X: https://www.x.com/robbie_rollupFollow Andy on X: https://www.x.com/ayyyeandyJoin our TG group: https://t.me/+TsM1CRpWFgk1NGZhThe Rollup Disclosures: https://goodidea.ventures

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

Wes and Scott talk about the latest dev news: Node enabling Temporal by default, OpenAI acquiring OpenClaw, TypeScript 6, new TanStack and Deno releases, the explosion of AI agent platforms, and more. Courtney Tolinski's Podcast Phases: A Parenting Podcast https://phases.fm/ Show Notes 00:00 Welcome to Syntax! 01:11 Brought to you by Sentry.io 02:40 Node.js enables Temporal by default Enable Temporal by default 04:08 OpenClaw acquired by OpenAI OpenClaw, OpenAI and the future 09:36 Bots are taking over the internet Wes' tweet 15:30 TypeScript 6 Beta Announcing TypeScript 6.0 Beta 17:00 TanStack Hotkeys for type-safe shortcuts TanStack Hotkeys 18:05 Components will kill webpages Components Will Kill Pages 19:39 Is Google Translate just an LLM? Viridian's tweet 23:29 Shaders.com 26:49 Voxtral Mini Realtime Voxtral Realtime Demo 29:51 Deno launches Sandboxes Introducing Deno Sandbox 32:39 Oz by Warp.dev 38:10 Augment Code Intent 40:10 Sick Picks + Shameless Plugs Sick Picks Scott: Samsung Remote Wes: Ice Shameless Plugs Syntax YouTube Channel 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 on JavaScript Jabber, we're joined (again!) by Val Karpov — the maintainer of Mongoose — to talk about what's new in Mongoose 9, how async stack traces are changing the debugging game, and why AI is quietly reshaping the way we build developer tools.We dig into stricter TypeScript support, the removal of callback-based middleware, and what it really takes to modernize a massive codebase. Then we shift gears into Mongoose Studio, a schema-aware, AI-enhanced MongoDB GUI that brings streaming query results, map visualizations, and even LLM-powered document generation into your workflow. If you've ever wrestled with debugging database issues or squinting at raw JSON, this episode will get your wheels turning.We also explore Cassandra integration, vector search, Bun vs. Deno, and what AI means for the future of software engineering. There's a lot here — especially if you're working in Node.js, MongoDB, or building backend-heavy JavaScript apps.

It's survey results reason, and the State of React 2025 results are in! As in the past, Next.js continues to dominate as one of the most used frameworks, but TanStack Start is one to watch. Other honorable mentions include: Zustand, Vite, and (most importantly) Front-end Fire tying for fifth place in the podcast section. Thank you, listeners!Google has a new proposal called WebMCP, which is a way to define structured tools for agents visiting a site, ensuring they can perform actions with increased speed, reliability, and precision.And instead of complicated build processes to convert HTML to markdown for AI agents' benefit, Cloudflare now offers real-time content conversion when AI systems request pages from any Cloudflare site. That's pretty great!Timestamps:1:03 - State of React survey results12:22 - WebMCP24:27 - Markdown for AI agents34:27 - TypeScript 6.0 beta38:00 - Chrome gets split view41:09 - What's making us happyNews:Paige - Markdown for AI agentsJack - WebMCPTJ - State of React 2025 survey results and Claude ReceiptsLightning News: TypeScript 6.0 betaChrome gets split viewWhat Makes Us Happy this Week:Paige - New Girl TV showJack - GridfinityTJ - The ResidenceThanks 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

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubCheck out more here:https://gotopia.tech/episodes/420Bill Frasure - Co-Author of  "Effect Oriented Programming"Bruce Eckel - Author of many books such as "Thinking in Java", "Thinking in C++" & Atomic Kotlin & Co-Author of  "Effect Oriented Programming"James Ward - Principal Developer Advocate at AWS & Co-Author of  "Effect Oriented Programming"Andrew Harmel-Law - Technical Principal at Thoughtworks & Author of "Facilitating Software Architecture"RESOURCESBillhttps://github.com/swoogleshttps://x.com/bill_frasureBrucehttps://bsky.app/profile/bruceeckel.bsky.socialhttps://x.com/BruceEckelhttps://github.com/BruceEckelhttps://www.linkedin.com/in/bruceeckelJameshttps://bsky.app/profile/jamesward.comhttps://twitter.com/_JamesWardhttps://github.com/jameswardhttps://www.linkedin.com/in/jameswardAndrewhttps://bsky.app/profile/andrewhl.bsky.socialhttps://twit.social/@ahlhttps://x.com/al94781https://github.com/andrewharmellawhttps://www.linkedin.com/in/andrewharmellawhttps://andrewharmellaw.github.ioLinkshttps://effectorientedprogramming.comhttps://happypathprogramming.comhttps://zio.devhttps://www.unison-lang.orghttps://www.roc-lang.orgDESCRIPTIONAndrew Harmel-Law explores the core concepts of effect oriented programming with authors Bill Frasure, Bruce Eckel, and James Ward. The discussion reveals that effects are composable operations that encapsulate side effects and defer execution, giving developers the right handles to manage unpredictability through compiler-checked types.The authors explain how ZIO tracks three critical types: outputs, failures, and environmental requirements, enabling better testing with mock clocks and random number generators.They share their intentional avoidance of intimidating functional programming terminology like "monads" proving you don't need mathematical foundations to understand effects. The conversation covers effect systems' expansion beyond Scala into TypeScript, Kotlin, and new languages like Unison and Roc, and how their collaborative writing process with strict constraints like 47-character line limits - created a coherent 100-page book readable in portrait mode on your phone.RECOMMENDED BOOKSBill Frasure, Bruce Eckel, James Ward • Effect Oriented Programming • https://amzn.to/4sO6wLVBruce Eckel & Svetlana Isakova • Atomic Kotlin • https://amzn.to/4qT1gEQBruce Eckel • Thinking in C++ • https://amzn.to/4qnrIGWAndrew Harmel-Law • Facilitating Software Architecture • https://amzn.eu/d/5kZKVfUSam Keen • Clean Architecture with Python • https://amzn.to/4pBT5g0Eric Evans • Domain-Driven Design • https://amzn.to/3tnGhwmBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking 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!

OpenClaw is a self-hosted AI agent daemon that executes autonomous tasks through messaging apps like WhatsApp and Telegram using persistent memory. It integrates with Claude Code to enable software development and administrative automation directly from mobile devices. Links Notes and resources at ocdevel.com/mlg/mla-29 Try a walking desk - stay healthy & sharp while you learn & code Generate a podcast - use my voice to listen to any AI generated content you want OpenClaw is a self-hosted AI agent daemon (Node.js, port 18789) that executes autonomous tasks via messaging apps like WhatsApp or Telegram. Developed by Peter Steinberger in November 2025, the project reached 196,000 GitHub stars in three months. Architecture and Persistent Memory Operational Loop: Gateway receives message, loads SOUL.md (personality), USER.md (user context), and MEMORY.md (persistent history), calls LLM for tool execution, streams response, and logs data. Memory System: Compounds context over months. Users should prompt the agent to remember specific preferences to update MEMORY.md. Heartbeats: Proactive cron-style triggers for automated actions, such as 6:30 AM briefings or inbox triage. Skills: 5,705+ community plugins via ClawHub. The agent can author its own skills by reading API documentation and writing TypeScript scripts. Claude Code Integration Mobile to Deploy Workflow: The claude-code-skill bridge provides OpenClaw access to Bash, Read, Edit, and Git tools via Telegram. Agent Teams: claude-team manages multiple workers in isolated git worktrees to perform parallel refactors or issue resolution. Interoperability: Use mcporter to share MCP servers between Claude Code and OpenClaw. Industry Comparisons vs n8n: Use n8n for deterministic, zero-variance pipelines. Use OpenClaw for reasoning and ambiguous natural language tasks. vs Claude Cowork: Cowork is a sandboxed, desktop-only proprietary app. OpenClaw is an open-source, mobile-first, 24/7 daemon with full system access. Professional Applications Therapy: Voice to SOAP note transcription. PHI requires local Ollama models due to a lack of encryption at rest in OpenClaw. Marketing: claw-ads for multi-platform ad management, Mixpost for scheduling, and SearXNG for search. Finance: Receipt OCR and Google Drive filing. Requires human review to mitigate non-deterministic LLM errors. Real Estate: Proactive transaction deadline monitoring and memory-driven buyer matching. Security and Operations Hardening: Bind to localhost, set auth tokens, and use Tailscale for remote access. Default settings are unsafe, exposing over 135,000 instances. Injection Defense: Add instructions to SOUL.md to treat external emails and web pages as hostile. Costs: Software is MIT-licensed. API costs are paid per-token or bundled via a Claude subscription key. Onboarding: Run the BOOTSTRAP.md flow immediately after installation to define agent personality before requesting tasks.

En este episodio hablamos de Electrobun, una alternativa moderna para crear aplicaciones de escritorio usando TypeScript con rendimiento casi nativo. Analizamos cómo combina Bun y el WebView del sistema para ofrecer apps más ligeras, rápidas y pequeñas que Electron, y qué significa esto realmente para desarrolladores que buscan velocidad sin sacrificar experiencia de usuario

Artificial intelligence used to live in strategy decks and conference keynotes—but now it's showing up in a very different place: right on the assembly tables where SPD technicians build trays for the next case. And it's arriving at a time when the pressure on sterile processing has never been higher. As surgical volumes climb and staffing shortages continue to strain hospital teams, SPDs are being asked to move faster while making zero mistakes. Even a single missing instrument can mean tray rework, case delays, and tension between departments. That's why AI-powered computer vision is gaining attention: not as a futuristic replacement for technicians, but as a second set of eyes built directly into the workflow.Can AI meaningfully reduce tray errors and compliance risk in SPDs—without disrupting workflows or replacing the human expertise at the center of sterile processing?Welcome to ConCensis. Continuing from a previous episode in this two-part conversation, host Daniel Litwin rejoins Censis Chief Technology Officer Harshil Goradia and Senior Director of Product Development Seamus Johnson to explore the future of AI in sterile processing. The episode centers on Censis Technologies' AI-powered sterile processing solution, Assembly Copilot: Final Check, a computer vision tool that detects missing chemical integrators before trays leave the assembly area. Together, the group discusses real-world results from early adopters, how the tool integrates seamlessly into existing workflows, and what the next three to five years of AI innovation in SPDs could look like.What you'll learn…How Final Check drove missing integrator occurrences down to zero by flagging omissions in real time—stopping trays before they left assembly and required rework or delayed a case.Why embedded computer vision and real-time alerts strengthen compliance without adding tool fatigue, integrating directly into technician workflows instead of forcing teams to adopt separate systems or change standard work processes.What responsible AI adoption looks like in sterile processing, including human-in-the-loop oversight, transparent governance practices, and a phased approach that builds trust with technicians and hospital leadership.Harshil Goradia serves as the Chief Technology Officer and VP of IT at Censis Technologies, where he leads global engineering, AI, innovation, and digital transformation initiatives across commercial and government healthcare businesses. He has a proven track record of launching revenue-generating AI products, building AI-native data platforms, modernizing cloud and IT infrastructure, and driving measurable growth, efficiency gains, and cybersecurity excellence within large enterprise environments, including Fortive and Fortune 100 organizations. Previously, he led AI Centers of Excellence and large-scale cloud, ERP, and digital transformation programs across the U.S., Europe, and Asia, delivering multi-million-dollar impact and scaling high-performing global technology teams.Seamus Johnson is a Senior Software Developer at Censis Technologies with more than two decades of experience building and scaling healthcare technology solutions. He specializes in software architecture, cloud systems, database design, cybersecurity, and full-stack development using technologies such as C#, Angular, and TypeScript. With a background in physics from Tennessee Technological University and prior experience at Northrop Grumman, Johnson brings deep technical expertise and long-standing industry experience to the development of secure, high-performance applications for sterile processing and hospital environments.

Eighteen months ago, Tyler Cloutier appeared on the show with what sounded like an ambitious (some might say crazy) plan: build a new distributed database from scratch, then use it to power a massively multiplayer online game. That's two of the hardest problems in software, tackled simultaneously. But sometimes the best infrastructure comes from solving your own impossible problems.The game, Bitcraft, has now launched on Steam. SpacetimeDB has hit version 1.0. And Tyler returns to share what actually happened when theory met production reality. We cover the launch day performance disasters (including a cascading failure caused by logging while holding a lock), why single-threaded execution running entirely from L1 cache can outperform sophisticated multi-threaded approaches by two orders of magnitude, and how the database's reducer model - borrowed from functional programming - enables zero-downtime code deployments. We also get into how SpacetimeDB is expanding beyond games with TypeScript support and React hooks that make building real-time multiplayer web apps surprisingly simple.If you're building anything where multiple users need to see the same data update in real time - which, as Tyler points out, describes most successful applications from Figma to Facebook - SpacetimeDB's approach of treating every app as a multiplayer game might be worth understanding.--Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/joinSpacetimeDB: https://spacetimedb.com/SpacetimeDB on GitHub: https://github.com/clockworklabs/SpacetimeDBOur previous episode with Tyler: https://youtu.be/roEsJcQYjd8Clockwork Labs: https://clockworklabs.io/Bitcraft Online: https://bitcraftonline.com/Bitcraft on Steam: https://store.steampowered.com/app/3454650/BitCraft_OnlineWebAssembly: https://webassembly.org/Flecs (ECS for C/C++): https://www.flecs.dev/flecs/TigerBeetle: https://tigerbeetle.com/CockroachDB: https://www.cockroachlabs.com/Google Cloud Spanner: https://cloud.google.com/spannerErlang: https://www.erlang.org/Apache Kafka: https://kafka.apache.org/Tyler Cloutier on X: https://x.com/TylerFCloutierTyler Cloutier on LinkedIn: https://www.linkedin.com/in/tylercloutier/--Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/0:00 Intro2:01 The Architecture of SpacetimeDB5:01 Client-Side Prediction in Multiplayer Games11:00 Reducers and Event Streaming15:00 Launching Bitcraft on Steam19:00 Debugging Launch Performance Problems26:56 Hot-Swapping Server Code Without Downtime30:01 In-Memory Tables and Query Optimization42:00 Is SpacetimeDB Only For Games?51:00 Performance Benchmarking For Web Workloads55:00 Why Single-Threaded Beats Multi-Threaded1:00:01 Multi-Version Concurrency Control Trade-offs1:05:01 Sharding Data Across Multiple Nodes1:10:56 Inter-Module Communication and Actor Models1:17:00 Replication and the Write-Ahead Log1:24:00 Supported Client Languages1:29:00 Getting Started With SpacetimeDB1:39:02 Outro

AI agents failed spectacularly at teamwork, performing ~50% worse than one solo agent!This week, we're discussing Stanford's CooperBench study (a benchmark, testing whether AI agents can collaborate on real coding tasks across Python, TypeScript, Go, and Rust) and why AI-developer coordination collapses, even with a constant chat.Listen or watch as Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel dig into the methods and findings of Stanford's 2026 CooperBench experiment and learn about the three capability gaps that caused these failures: • Expectation Failures (42%): Agents ignored shared plans or misunderstood scope• Commitment Failures (32%): Promised work was never completed• Communication Failures (26%): Silence, spam, or hallucinationsThe experiment's findings seem to confirm human-refined agile practices. The episode ends with a concrete call to action: stop treating AI as teammates. Use them as solo contributors. And if you must coordinate? Build working agreements, not handoffs.This episode is for anyone navigating the AI hype cycle and wondering if swarms of agents are going to coordinate everyone out of a job!#Agile #AI #ProductManagementSOURCECooperBench: Benchmarking AI Agents' Cooperation (Stanford University & SAP Labs US)https://cooperbench.com/https://cooperbench.com/static/pdfs/main.pdfLINKSYouTube: https://www.youtube.com/@arguingagileSpotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596INTRO MUSICToronto Is My BeatBy Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Change is unavoidable in software, so how do you make it safe to evolve systems without breaking trust? In this episode, we're joined by Elmer Bulthuis for a wide-ranging conversation about building software that can adapt over time. We explore how Rust's ownership model shapes clearer thinking about design, why WebAssembly is becoming a practical way to share complex logic across platforms, and how Elmer has used Rust and WASM in real projects to keep behaviour consistent across TypeScript and .NET without duplicating effort.We also dig into the everyday practices that make long-lived systems possible: choosing names that work in context, designing abstractions that don't leak, and treating tests as living documentation rather than a checkbox. Elmer shares thoughtful perspectives on local-first development, keeping CI honest, and using AI as a helpful power tool for refactoring without outsourcing engineering judgement. Along the way, we touch on team culture, ego-free collaboration, and even yoga — because sustainable software is ultimately built by sustainable people.Connect with Elmer:LinkedIn: https://www.linkedin.com/in/elmerbulthuisGithub: https://github.com/elmerbulthuis___

Scott and Wes sit down with Dimitri Metropolis to explore the wild edges of TypeScript—from running Doom in the type system to building tools like Typeslayer. They dig into Turing-complete types, performance limits, and what the future might hold for TypeScript and programming languages as a whole. Show Notes 00:00 Welcome to Syntax! 00:27 Dimitri Metropolis Introduction 01:29 What is Doom in TypeScript? 03:10 TypeScript Types and Turing Completeness 04:06 Project Overview and Challenges 04:57 ASCII Art and Visual Representation 06:50 Performance Issues with TypeScript 09:27 Brought to you by Sentry.io 09:51 Typeslayer Tool Introduction 16:19 Building in Tauri 20:54 Challenges around packaging 24:03 Future of TypeScript and AI 27:40 Is the Go-based compiler significantly faster? TSperf 30:23 Should there be something to follow Typescript? 36:27 Staying up to date with WASM. 37:08 SquiggleConf Overview 38:26 Hosting a conference 40:45 What are your thoughts on Zig? 45:07 Vibe coding as an end goal 50:01 Sick Picks & Shameless Plugs Sick Picks Dimitri: pullfrog Shameless Plugs Dimitri: Michigan TypeScript on YouTube 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

The public has been fascinated by the experience of interacting with large language models, or LLMs, like OpenAI's ChatGPT and Google's Gemini. In this episode we will look at current work with LLMs that plays to their strengths and involves a lower risk of inaccurate outputs. In particular we will look at the use of LLMs to translate between languages. Software teams generally operate in their native language. Once they have finished building their system, they often want to make it available in other languages to access other markets. The process of making a program that was originally written for one language usable by people who speak other languages is called internationalization. Historically internationalization has been a slow and expensive process. Today we will be talking with Archie McKenzie, the founder of a Silicon Valley startup that is offering internationalization services to software teams. Archie is atypical in various ways. A Briton, Archie came to the US to study Classics at Princeton. He ventured into a course taught by a famous computer scientist, Brian Kernighan, whose teaching inspired Archie to switch from Ancient Greek and Latin to Java, Python, and Typescript. After graduating from Princeton in 2024, Archie started a company called General Translation to develop and commercialize internationalization automation for software development projects.

1855 kicks off with a bombshell AP investigation revealing how Silicon Valley giants IBM, Intel, NVIDIA, Oracle, and more spent decades building China’s surveillance state. Also covered, malicious Chrome extensions stealing credentials from 170+ sites, Microsoft’s ambitious Rust migration plans, China’s combat-ready humanoid robot, and Japan restarting the world’s largest nuclear plant. -Want to be a Guest on a Podcast or YouTube Channel? Sign up for GuestMatch.Pro -Thinking of buying a Starlink? Use my link to support the show. Subscribe to the Newsletter. Email Ray if you want to get in touch! Like and Follow Geek News Central’s Facebook Page. Support my Show Sponsor: Best Godaddy Promo Codes $11.99 – For a New Domain Name cjcfs3geek $6.99 a month Economy Hosting (Free domain, professional email, and SSL certificate for the 1st year.) Promo Code: cjcgeek1h $12.99 a month Managed WordPress Hosting (Free domain, professional email, and SSL certificate for the 1st year.) Promo Code: cjcgeek1w Support the show by becoming a Geek News Central Insider Get 1Password Full Summary Cochrane opens episode 1855 with a bombshell. The Associated Press released a major investigation into Silicon Valley’s role building China’s surveillance state. Companies like IBM, Intel, NVIDIA, and Oracle sold technologies for facial recognition and predictive policing. These tools enabled mass detention in Xinjiang. Cochrane expressed horror at the findings and emphasized American companies’ complicity in human rights abuses. Next, the podcast covered serious browser security concerns. Two malicious Chrome extensions had been stealing credentials from over 170 websites for years. Cochrane stressed the need for caution when installing plugins. He also highlighted how attackers exploit trusted extensions through manipulative tactics. Additionally, Cochrane discussed Microsoft’s ambitious plan to replace all C/C++ code with Rust by 2030. The company faces ongoing security challenges from memory safety issues in legacy languages. However, he noted this remains a research project rather than an official goal. Still, the move reflects broader industry trends toward Rust adoption. The episode then featured GitHub Universe 2025’s most influential open-source projects. Cochrane remarked on how the development landscape continues to evolve. TypeScript has emerged as a dominant language alongside new tools that streamline workflows. Meanwhile, advancements in humanoid robotics took center stage. Engine AI unveiled its T800 combat-ready humanoid robot with impressive features. The company even released a viral video of the robot kicking its CEO to prove authenticity. Following this, Cochrane covered the Blackbird flying car prototype. This eVTOL innovation showcases paradigm-shifting propulsion technology. It could transform urban transportation in the coming decades. The podcast also reviewed Android Central’s best smartphones of 2025. OnePlus 15 claimed the top spot thanks to its impressive specs and consumer-focused features. Furthermore, Cochrane addressed a controversial topic: Anna’s Archive scraping Spotify’s entire library. He expressed mixed feelings about the situation. On one hand, artists and the music industry face real harm. On the other, questions about digital preservation and access deserve consideration. Finally, the episode explored groundbreaking brain simulation research. Japan’s Fugaku supercomputer enabled unprecedented neural modeling. This marks a significant step toward understanding neurological diseases. Cochrane wrapped up by discussing Japan’s plans to restart the Kashiwazaki-Kariwa nuclear plant. Local residents remain concerned about safety despite government approval. The decision reflects Japan’s shifting energy strategy post-Fukushima. As the episode closed, Cochrane wished listeners a Happy New Year. He encouraged self-reflection and thanked everyone for tuning in throughout the year. Show Links Silicon Valley’s Role in Building China’s Surveillance State Two Chrome Extensions Caught Secretly Stealing Credentials from Over 170 Sites Microsoft to Replace All C/C++ Code With Rust By 2030 This Year’s Most Influential Open Source Projects EngineAI Unveils T800: Combat-Ready Humanoid Targets Mass Production Aviation Startup Shares Incredible Video of Prototype EV’s Maiden Takeoff Flight Android Central’s Best of 2025: Phones Pirate Archivist Group Scrapes Spotify’s 300TB Library This Breakthrough Brain Simulation Captures a True Brain at Work Japan Prepares to Restart World’s Biggest Nuclear Plant The post Money over Ethics: Silicon Valley and China’s Police State #1855 appeared first on Geek News Central.

In this episode of the Crazy Wisdom Podcast, host Stewart Alsop sits down with Mike Bakon to explore the fascinating intersection of hardware hacking, blockchain technology, and decentralized systems. Their conversation spans from Mike's childhood fascination with taking apart electronics in 1980s Poland to his current work with ESP32 microcontrollers, LoRa mesh networks, and Cardano blockchain development. They discuss the technical differences between UTXO and account-based blockchains, the challenges of true decentralization versus hybrid systems, and how AI tools are changing the development landscape. Mike shares his vision for incentivizing mesh networks through blockchain technology and explains why he believes mass adoption of decentralized systems will come through abstraction rather than technical education. The discussion also touches on the potential for creating new internet infrastructure using ad hoc mesh networks and the importance of maintaining truly decentralized, permissionless systems in an increasingly surveilled world. You can find Mike in Twitter as @anothervariable.Check out this GPT we trained on the conversationTimestamps00:00 Introduction to Hardware and Early Experiences02:59 The Evolution of AI in Hardware Development05:56 Decentralization and Blockchain Technology09:02 Understanding UTXO vs Account-Based Blockchains11:59 Smart Contracts and Their Functionality14:58 The Importance of Decentralization in Blockchain17:59 The Process of Data Verification in Blockchain20:48 The Future of Blockchain and Its Applications34:38 Decentralization and Trustless Systems37:42 Mainstream Adoption of Blockchain39:58 The Role of Currency in Blockchain43:27 Interoperability vs Bridging in Blockchain47:27 Exploring Mesh Networks and LoRa Technology01:00:25 The Future of AI and DecentralizationKey Insights1. Hardware curiosity drives innovation from childhood - Mike's journey into hardware began as a child in 1980s Poland, where he would disassemble toys like battery-powered cars to understand how they worked. This natural curiosity about taking things apart and understanding their inner workings laid the foundation for his later expertise in microcontrollers like the ESP32 and his deep understanding of both hardware and software integration.2. AI as a research companion, not a replacement for coding - Mike uses AI and LLMs primarily as research tools and coding companions rather than letting them write entire applications. He finds them invaluable for getting quick answers to coding problems, analyzing Git repositories, and avoiding the need to search through Stack Overflow, but maintains anxiety when AI writes whole functions, preferring to understand and write his own code.3. Blockchain decentralization requires trustless consensus verification - The fundamental difference between blockchain databases and traditional databases lies in the consensus process that data must go through before being recorded. Unlike centralized systems where one entity controls data validation, blockchains require hundreds of nodes to verify each block through trustless consensus mechanisms, ensuring data integrity without relying on any single authority.4. UTXO vs account-based blockchains have fundamentally different architectures - Cardano uses an extended UTXO model (like Bitcoin but with smart contracts) where transactions consume existing UTXOs and create new ones, keeping the ledger lean. Ethereum uses account-based ledgers that store persistent state, leading to much larger data requirements over time and making it increasingly difficult for individuals to sync and maintain full nodes independently.5. True interoperability differs fundamentally from bridging - Real blockchain interoperability means being able to send assets directly between different blockchains (like sending ADA to a Bitcoin wallet) without intermediaries. This is possible between UTXO-based chains like Cardano and Bitcoin. Bridges, in contrast, require centralized entities to listen for transactions on one chain and trigger corresponding actions on another, introducing centralization risks.6. Mesh networks need economic incentives for sustainable infrastructure - While technologies like LoRa and Meshtastic enable impressive decentralized communication networks, the challenge lies in incentivizing people to maintain the hardware infrastructure. Mike sees potential in combining blockchain-based rewards (like earning ADA for running mesh network nodes) with existing decentralized communication protocols to create self-sustaining networks.7. Mass adoption comes through abstraction, not education - Rather than trying to educate everyone about blockchain technology, mass adoption will happen when developers can build applications on decentralized infrastructure that users interact with seamlessly, without needing to understand the underlying blockchain mechanics. Users should be able to benefit from decentralization through well-designed interfaces that abstract away the complexity of wallets, addresses, and consensus mechanisms.

In dieser Revision drehen wir nochmal das Glücksrad – allerdings zum Themenbereich TypeScript und React. Gemeinsam mit unserem Gast Kiki (Hans-Christian Otto), seines Zeichens Paramount Leader von Suo…

Show DescriptionAfter a bit of gaming talk, Chris and Dave are sharing a bunch of cool projects that our Discord community members have been sharing over the past year including things like a web component based admin bar, shape CSS generators, new website portfolios, HTML-first web framework, email markup databases, miniature paintings, AI tools and ducks, and a lot more. ShopTalk will be taking a break after this episode until the new year. Happy holidays for 2025 and we look forward to a great year in 2026 sharing our love of all things HTML, CSS, and building websites. Listen on WebsiteWatch on YouTubeLinks BALL x PIT on Steam Overwatch 2 Call of Duty® | Best-Selling Video Game Franchise THE FINALS on Steam Welcome to Steam Home | Vulkan | Cross platform 3D Graphics Dota 2 Counter-Strike 2 Learn JavaScript, React, and TypeScript to Node.js, Fullstack, and Backend | Frontend Masters HTML for People GitHub - StfBauer/markshell: Markshell allows you to convert Markdown to a beautiful output on the shell, Ideal for any custom built NodeJS CLI. Admin Bar Component | Will Browar ship-shape.win Quina - Menu Crashlands 2 | Games | Butterscotch Shenanigans How Many Dudes? on Steam Unoffice Hours Webring Unoffice Hours - Dave Smyth Dynamic Dummy Image Generator - DummyImage.com Lynn Fisher Nestflix o(m)g:image | Question 1 Making o(m)g:image, Part III: The HTML - Jim Nielsen's Blog Outlyne - AI Website Builder | Create Stunning Websites with AI Greenwood I Hid a Dozen Easter Eggs on This Website – Unapologetic MacStories - Apple news, app reviews, and stories by Federico Viticci and friends. SotB14 | State of the Browser 14 The Email Markup Database (2) Post | LinkedIn Storybook MCP sneak peek Andy Ford - miniature painter Rubber AI Baseline Tennis - Ulimate Tennis ladder for competitive and casual players Intersecting Us - Where we explore math stories together. bitty - a web tool for interesting pages Dolphin Maker 2.0 Chris Enns + Lemon Productions SponsorsStudioworksManage clients and contacts, send branded invoices, receive payments, access educational resources, and connect with a supportive community. We're building the best business hub for freelancers who want a custom client experience that feels polished and professional — with much more in store.

BONUS: Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase In this fascinating conversation, veteran software engineer and author Lou Franco shares hard-won lessons from decades at startups, Trello, and Atlassian. We explore his book "Swimming in Tech Debt," diving deep into the 8 Questions framework for evaluating tech debt decisions, personal practices that compound over time, team-level strategies for systematic improvement, and leadership approaches that balance velocity with sustainability. Lou reveals why tech debt is often the result of success, how to navigate the spectrum between ignoring debt and rewriting too much, and practical techniques individuals, teams, and leaders can use starting today. The Exit Interview That Changed Everything "We didn't go slower by paying tech debt. We went actually faster, because we were constantly in that code, and now we didn't have to run into problems." — Lou Franco   Lou's understanding of tech debt crystallized during an exit interview at Atalasoft, a small startup where he'd spent years. An engineer leaving the company confronted him: "You guys don't care about tech debt." Lou had been focused on shipping features, believing that paying tech debt would slow them down. But this engineer told a different story — when they finally fixed their terrible build and installation system, they actually sped up. They were constantly touching that code, and removing the friction made everything easier. This moment revealed a fundamental truth: tech debt isn't just about code quality or engineering pride. It's about velocity, momentum, and the ability to move fast sustainably. Lou carried this lesson through his career at Trello (where he learned the dangers of rewriting too much) and Atlassian (where he saw enterprise-scale tech debt management). These experiences became the foundation for "Swimming in Tech Debt." Tech Debt Is the Result of Success "Tech debt is often the result of success. Unsuccessful projects don't have tech debt." — Lou Franco   This reframes the entire conversation about tech debt. Failed products don't accumulate debt — they disappear before it matters. Tech debt emerges when your code survives long enough to outlive its original assumptions, when your user base grows beyond initial expectations, when your team scales faster than your architecture anticipated. At Atalasoft, they built for 10 users and got 100. At Trello, mobile usage exploded beyond their web-first assumptions. Success creates tech debt by changing the context in which code operates. This means tech debt conversations should happen at different intensities depending on where you are in the product lifecycle. Early startups pursuing product-market fit should minimize tech debt investments — move fast, learn, potentially throw away the code. Growth-stage companies need balanced approaches. Mature products benefit significantly from tech debt investments because operational efficiency compounds over years. Understanding this lifecycle perspective helps teams make appropriate decisions rather than applying one-size-fits-all rules. The 8 Questions Framework for Tech Debt Decisions "Those 8 questions guide you to what you should do. If it's risky, has regressions, and you don't even know if it's gonna work, this is when you're gonna do a project spike." — Lou Franco   Lou introduces a systematic framework for evaluating whether to pay tech debt, inspired by Bob Moesta's push-pull forces from product management. The 8 questions create a complete picture:   Visibility — Will people outside the team understand what we're doing? Alignment — Does this match our engineering values and target architecture? Resistance — How hard is this code to work with right now? Volatility — How often do we touch this code? Regression Risk — What's the chance we'll introduce new problems? Project Size — How big is this to fix? Estimate Risk — How uncertain are we about the effort required? Outcome Uncertainty — How confident are we the fix will actually improve things?   High volatility and high resistance with low regression risk? Pay the debt now. High regression risk with no tests? Write tests first, then reassess. Uncertain outcomes on a big project? Do a spike or proof of concept. The framework prevents both extremes — ignoring costly debt and undertaking risky rewrites without proper preparation. Personal Practices That Compound Daily "When I sit down at my desk, the first thing I do is I pay a little tech debt. I'm looking at code, I'm about to change it, do I even understand it? Am I having some kind of resistance to it? Put in a little helpful comment, maybe a little refactoring." — Lou Franco   Lou shares personal habits that create compounding improvements over time. Start each coding session by paying a small amount of tech debt in the area you're about to work — add a clarifying comment, extract a confusing variable, improve a function name. This warms you up, reduces friction for your actual work, and leaves the code slightly better than you found it. The clean-as-you-go philosophy means tech debt never accumulates faster than you can manage it. But Lou's most powerful practice comes at the end of each session: mutation testing by hand. Before finishing for the day, deliberately break something — change a plus to minus, a less-than to less-than-or-equal. See if tests catch it. Often they don't, revealing gaps in test coverage. The key insight: don't fix it immediately. Leave that failing test as the bridge to tomorrow's coding session. It connects today's momentum to tomorrow's work, ensuring you always start with context and purpose rather than cold-starting each day. Mutation Testing: Breaking Things on Purpose "Before I'm done working on a coding session, I break something on purpose. I'll change a plus to a minus, a less than to a less than equals, and see if tests break. A lot of times tests don't break. Now you've found a problem in your test." — Lou Franco   Manual mutation testing — deliberately breaking code to verify tests catch the break — reveals a critical gap in most test suites. You can have 100% code coverage and still have untested behavior. A line of code that's executed during tests isn't necessarily tested — the test might not actually verify what that line does. By changing operators, flipping booleans, or altering constants, you discover whether your tests protect against actual logic errors or just exercise code paths. Lou recommends doing this manually as part of your daily practice, but automated tools exist for systematic discovery: Stryker (for JavaScript, C#, Scala) and MutMut (for Python) can mutate your entire codebase and report which mutations survive uncaught. This isn't just about test quality — it's about understanding what your code actually does and building confidence that changes won't introduce subtle bugs. Team-Level Practices: Budgets, Backlogs, and Target Architecture "Create a target architecture document — where would we be if we started over today? Every PR is an opportunity to move slightly toward that target." — Lou Franco   At the team level, Lou advocates for three interconnected practices. First, create a target architecture document that describes where you'd be if starting fresh today — not a detailed design, but architectural patterns, technology choices, and structural principles that represent current best practices. This isn't a rewrite plan; it's a North Star. Every pull request becomes an opportunity to move incrementally toward that target when touching relevant code. Second, establish a budget split between PM-led feature work and engineering-led tech debt work — perhaps 80/20 or whatever ratio fits your product lifecycle stage. This creates predictable capacity for tech debt without requiring constant negotiation. Third, hold quarterly tech debt backlog meetings separate from sprint planning. Treat this backlog like PMs treat product discovery — explore options, estimate impacts, prioritize based on the 8 Questions framework. Some items fit in sprints; others require dedicated engineers for a quarter or two. This systematic approach prevents tech debt from being perpetually deprioritized while avoiding the opposite extreme of engineers disappearing into six-month "improvement" projects with no visible progress. The Atlassian Five-Alarm Fire "The Atlassian CTO's 'five-alarm fire' — stopping all feature development to focus on reliability. I reduced sync errors by 75% during that initiative." — Lou Franco   Lou shares a powerful example of leadership-driven tech debt management at scale. The Atlassian CTO called a "five-alarm fire" — halting all feature development across the company to focus exclusively on reliability and tech debt. This wasn't panic; it was strategic recognition that accumulated debt threatened the business. Lou worked on reducing sync errors, achieving a 75% reduction during this focused period. The initiative demonstrated several leadership principles: willingness to make hard calls that stop revenue-generating feature work, clear communication of why reliability matters strategically, trust that teams will use the time wisely, and commitment to see it through despite pressure to resume features. This level of intervention is rare and shouldn't be frequent, but it shows what's possible when leadership truly prioritizes tech debt. More commonly, leaders should express product lifecycle constraints (startup urgency vs. mature product stability), give teams autonomy to find appropriate projects within those constraints, and require accountability through visible metrics and dashboards that show progress. The Rewrite Trap: Why Big Rewrites Usually Fail "A system that took 10 years to write has implicit knowledge that can't be replicated in 6 months. I'm mostly gonna advocate for piecemeal migrations along the way, reducing the size of the problem over time." — Lou Franco   Lou lived through Trello's iOS navigation rewrite — a classic example of throwing away working code to start fresh, only to discover all the edge cases, implicit behaviors, and user expectations baked into the "old" system. A codebase that evolved over several years contains implicit knowledge — user workflows, edge case handling, performance optimizations, and subtle behaviors that users rely on even if they never explicitly requested them. Attempting to rewrite this in six months inevitably misses critical details. Lou strongly advocates for piecemeal migrations instead. The Trello "Decaffeinate Project" exemplifies this approach — migrating from CoffeeScript to TypeScript incrementally, with public dashboards showing the percentage remaining, interoperable technologies allowing gradual transition, and the ability to pause or reverse if needed. Keep both systems running in parallel during migrations. Use runtime observability to verify new code behaves identically to old code. Reduce the problem size steadily over months rather than attempting big-bang replacements. The only exception: sometimes keeping parallel systems requires scaffolding that creates its own complexity, so evaluate whether piecemeal migration is actually simpler or if you're better off living with the current system. Making Tech Debt Visible Through Dashboards "Put up a dashboard, showing it happen. Make invisible internal improvements visible through metrics engineering leadership understands." — Lou Franco   One of tech debt's biggest challenges is invisibility — non-technical stakeholders can't see the improvement from refactoring or test coverage. Lou learned to make tech debt work visible through dashboards and metrics. The Decaffeinate Project tracked percentage of CoffeeScript files remaining, providing a clear progress indicator anyone could understand. When reducing sync errors, Lou created dashboards showing error rates declining over time. These visualizations serve multiple purposes: they demonstrate value to leadership, create accountability for engineering teams, build momentum as progress becomes visible, and help teams celebrate wins that would otherwise go unnoticed. The key is choosing metrics that matter to the business — error rates, page load times, deployment frequency, mean time to recovery — rather than pure code quality metrics like cyclomatic complexity that don't translate outside engineering. Connect tech debt work to customer experience, reliability, or developer productivity in ways leadership can see and value. Onboarding as a Tech Debt Opportunity "Unit testing is a really great way to learn a system. It's like an executable specification that's helping you prove that you understand the system." — Lou Franco   Lou identifies onboarding as an underutilized opportunity for tech debt reduction. When new engineers join, they need to learn the codebase. Rather than just reading code or shadowing, Lou suggests having them write unit tests in areas they're learning. This serves dual purposes: tests are executable specifications that prove understanding of system behavior, and they create safety nets in areas that likely lack coverage (otherwise, why would new engineers be confused by the code?). The new engineer gets hands-on learning, the team gets better test coverage, and everyone wins. This practice also surfaces confusing code — if new engineers struggle to understand what to test, that's a signal the code needs clarifying comments, better naming, or refactoring. Make onboarding a systematic tech debt reduction opportunity rather than passive knowledge transfer. Leadership's Role: Constraints, Autonomy, and Accountability "Leadership needs to express the constraints. Tell the team what you're feeling about tech debt at a high level, and what you think generally is the appropriate amount of time to be spent on it. Then give them autonomy." — Lou Franco   Lou distills leadership's role in tech debt management to three elements. First, express constraints — communicate where you believe the product is in its lifecycle (early startup, rapid growth, mature cash cow) and what that means for tech debt tolerance. Are we pursuing product-market fit where code might be thrown away? Are we scaling a proven product where reliability matters? Are we maintaining a stable system where operational efficiency pays dividends? These constraints help teams make appropriate trade-offs. Second, give autonomy — once constraints are clear, trust teams to identify specific tech debt projects that fit those constraints. Engineers understand the codebase's pain points better than leaders do. Third, require accountability — teams must make their work visible through dashboards, metrics, and regular updates. Autonomy without accountability becomes invisible engineering projects that might not deliver value. Accountability without autonomy becomes micromanagement that wastes engineering judgment. The balance creates space for teams to make smart decisions while keeping leadership informed and confident in the investment. AI and the Future of Tech Debt "I really do AI-assisted software engineering. And by that, I mean I 100% review every single line of that code. I write the tests, and all the code is as I would have written it, it's just a lot faster. Developers are still responsible for it. Read the code." — Lou Franco   Lou has a chapter about AI in his book, addressing the elephant in the room: will AI-generated code create massive tech debt? His answer is nuanced. AI can accelerate development tremendously if used correctly — Lou uses it extensively but reviews every single line, writes all tests himself, and ensures the code matches what he would have written manually. The problem emerges with "vibe coders" — non-developers using AI to generate code they don't understand, creating unmaintainable messes that become someone else's problem. Developers remain responsible for all code, regardless of how it's generated. This means you must read and understand AI-generated code, not blindly accept it. Lou also raises supply chain security concerns — dependencies can contain malicious code, and AI might introduce vulnerabilities developers miss. His recommendation: stay six months behind on dependency updates, let others discover the problems first, and consider separate sandboxed development machines to limit security exposure. AI is a powerful tool, but it doesn't eliminate the need for engineering judgment, testing discipline, or code review practices. The Style Guide Beyond Formatting "Have a style guide that goes beyond formatting to include target architecture. This is the kind of code we want to write going forward." — Lou Franco   Lou advocates for style guides that extend beyond tabs-versus-spaces formatting rules to include architectural guidance. Document patterns you want to move toward: how should components be structured, what state management approaches do we prefer, how should we handle errors, what testing patterns should we follow? This creates a shared understanding of the target architecture without requiring a massive design document. When reviewing pull requests, teams can reference the style guide to explain why certain approaches align with where the codebase is headed versus perpetuating old patterns. This makes tech debt conversations less personal and more objective — it's not about criticizing someone's code, it's about aligning with team standards and strategic direction. The style guide becomes a living document that evolves as the team learns and technology changes, capturing collective wisdom about what good code looks like in your specific context. Recommended Resources Some of the resources mentioned in this episode include:  Steve Blank's Four Steps To Epiphany The podcast episode with Bernie Maloney where we discuss the critical difference between "enterprise" and "startup". And Geoffrey Moore's Crossing the Chasm, and Dealing with Darwin.   About Lou Franco   Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.   You can link with Lou Franco on LinkedIn and learn more at LouFranco.com.

Lords: * Hallie * Peter * https://www.paschaefer.com/ Topics: * Do you know where all your things are? * How education doesn't melt * Bebop Bytes Back * Augustus Gloop by Roald Dahl * https://allpoetry.com/-Augustus-Gloop...- Microtopics: * The Directrix of Cybernetic Security. * Unity licensing from Unity as Unity. * Fantasy Book of the Month. (FBOM) * Part zombie, part ghost. * Accidentally GenMoing your WriMo. * A house with a bunch of your things in it, and they're everywhere. * Knowing someone who knows how to find things and knowing someone who knows where things are. * Knowing where to put something because it's where you first thought to look for it. * A person who itches when they see somebody not using a switch statement. * Having been gradually removing yourself from social media since back when Twitter was Twitter. * Back when you could get out of a chair without grunting. * Getting the whooping cough and coughing your disc out. (And you're in your twenties.) * Whether your dad named you after the murderous robot in 2001. * Seeing your students cheating poorly and teaching them how to do it well. * Scaffolding it pedagogically. * Big boat: hard turn. * How do we get education to exhibit swarm behavior? * A brand new exciting way to be bummed. * Education by Panopticon. * LLMs exposing how much of people's jobs and education are bullshit busywork. * When does the salt jump? * Putting together the 50s and then putting together the tens and then putting together the fours. * The simplest shallowest version of active listening that exists. * Doritos hacking the learning loop. * Continually finding new opiates of the masses. * Typing hex opcodes into the Beboputer. * An effective educational tool that has never been less appealing to the youth it's targeted at. * Steve Jobs coming out of his grave and slitting your throat if you install a programming tool on your iPhone. * Making the sun wink and realizing that this is the rest of your life. * Deescalating your LLM partner when it has an anxiety attack. * Your Socratic Oxford Don persona. * The Life Cycle of Software Objects. * There is a mistake, and it is being overcome. * Steps you can take to avoid Godzilla coming back and nature reclaiming the earth. * A poem written by a beloved children's author who absolutely loathes fat people. * Whether the terrible children in Charlie and the Chocolate Factory are all based on people that Roald Dahl knew. * SwitchBitch, Roald Dahl's famous Typescript library. * Making sure your weirdness is a kindness. * Roald Dahl: boy did he do the stuff. * Penning The Twits in an effort to "do something against beards." * Why Stephen King? * The Dollar Babies. * Whether Stephen King is still on MySpace. * Walking down the road and hearing Stephen King yelling at cloud. * The Dave Barry game jam. * Going into the sewer and solving puzzle platformer problems. * Group hug vs. forming a blob. * Tube Hippo is back! * The game engine sorting hat. * Coming out of character to talk about Inform 7. * The year that you fucked around with interactive fiction but never shipped anything. * Presuming that interactive fiction has continued to be great even after you stopped playing. * Choosing Twine over Inform 7 because of your absolutely enormous forelimbs. * LLMs as an extremely fancy Tarot deck.

Episode Highlights[00:00:48] What Makes Software MaintainableDon explains why unnecessary complexity is the biggest barrier to maintainability, drawing on themes from A Philosophy of Software Design.[00:03:14] The Cost of Clever AbstractionsA real story from a Node.js API shows how an unused abstraction layer around MongoDB made everything harder without delivering value.[00:04:00] Shaping Teams and Developer ToolsDon describes the structure of the Search Craft engineering team and how the product grew out of recurring pain points in client projects.[00:06:36] Reducing Complexity Through SDK and Infra DesignWhy Search Craft intentionally limits configuration to keep setup fast and predictable.[00:08:33] Lessons From ConsultingRobby and Don compare consulting and product work, including how each environment shapes developers differently.[00:15:34] Inherited Software and Abandoned DependenciesDon shares the problems that crop up when community packages fall behind—especially in ecosystems like React Native.[00:18:00] Evaluating Third-Party LibrariesSignals Don looks for before adopting a dependency: adoption, update cadence, issue activity, and whether the library is “done.”[00:19:40] Designing Code That Remains UnderstandableWhy clear project structure and idiomatic naming matter more than cleverness.[00:20:29] RFCs as a Cultural AnchorHow Don's team uses RFCs to align on significant changes and avoid decision churn.[00:23:00] Documentation That Adds ContextDocumentation should explain why, not echo code. Don walks through how his team approaches this.[00:24:11] Type Systems and MaintainabilityHow Don's journey from PHP and JavaScript to TypeScript and Rust changed his approach to structure and communication.[00:27:05] Testing With TypesStable type contracts make tests cleaner and less ambiguous.[00:27:45] Building Trust in AI SystemsDon discusses repeatability, hallucinations, and why tools like MCP matter for grounding LLM behavior.[00:29:28] AI in Developer ToolsSearch Craft's MCP server lets developers talk to the platform conversationally instead of hunting through docs.[00:33:21] Improving Legacy Systems SlowlyThe Strangler pattern as a practical way to replace old systems one endpoint at a time.[00:34:11] Deep Work and Reducing Reactive NoiseDon encourages developers to carve out time for uninterrupted thinking rather than bouncing between notifications.[00:36:09] Measuring ProgressBuild times, test speeds, and coverage provide signals teams can use to track actual improvement.[00:38:24] Changing Opinions Over a CareerWhy Don eventually embraced TypeScript after originally writing it off.[00:39:15] Industry Trends and Repeating CyclesSPAs, server rendering, and the familiar pendulum swing in web architecture.[00:41:26] Experimentation and Team AutonomyHow POCs and side projects surface organically within Don's team.[00:44:42] Growing Skills Through Intentional GoalsSetting learning targets in 1:1s to support long-term developer growth.[00:47:19] Where to Find DonLinkedIn, Blue Sky, and his site: donmckinnon.dev.Resources MentionedA Philosophy of Software Design by John OusterhoutJohn Ousterhout's Maintainable.fm Interview (Episode 131)Search CraftElasticAlgoliaWordPress Plugin DirectoryRequest for Comments (RFC)Strangler Fig PatternC2 WikiModel Context Protocol (MCP)Glam AIAubrey/Maturin Series by Patrick O'BrianMaster and Commanderdonmckinnon.devThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Kubernetes has relied on role-based access control (RBAC) since 2017, but its simplicity limits what developers can express, said Micah Hausler, principal engineer at AWS, on The New Stack Makers. RBAC only allows actions; it can't enforce conditions, denials, or attribute-based rules. Seeking a more expressive authorization model for Kubernetes, Hausler explored Cedar, an authorization engine and policy language created at AWS in 2022 and later open-sourced. Although not designed specifically for Kubernetes, Cedar proved capable of modeling its authorization needs in a concise, readable way. Hausler highlighted Cedar's clarity—nontechnical users can often understand policies at a glance—as well as its schema validation, autocomplete support, and formal verification, which ensures policies are correct and produce only allow or deny outcomes.Now onboarding to the CNCF sandbox, Cedar is used by companies like Cloudflare and MongoDB and offers language-agnostic tooling, including a Go implementation donated by StrongDM. The project is actively seeking contributors, especially to expand bindings for languages like TypeScript, JavaScript, and Python.Learn more from The New Stack about Cedar:Ceph: 20 Years of Cutting-Edge Storage at the Edge The Cedar Programming Language: Authorization SimplifiedJoin our community of newsletter subscribers to stay on top of the news and at the top of your game.  Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Scott and CJ sit down live at JSNation NYC with Iwo Plaza, creator of TypeGPU, to dig into how WebGPU is unlocking a new wave of graphics and compute power on the web. They chat about shader authoring in TypeScript, the future of GPU-powered AI in the browser, and what it takes to build a killer developer-friendly graphics library. Show Notes 00:00 Welcome to Syntax! 00:32 What is TypeGPU? High-level overview and why it exists 01:20 WebGPU vs WebGL – the new era of GPU access on the web 01:47 Why shader languages are hard + making them accessible 02:24 Iwo's background in C++, OpenGL, and discovering JS 03:06 Sharing graphics work on the web vs native platforms 03:29 WebGPU frustrations that inspired TypeGPU 04:17 Making GPU–CPU data exchange easier with Zod-like schemas 05:01 Writing shaders in JavaScript + the unified type system 05:38 How the “use_gpu” directive works under the hood 06:05 Building a compiler that turns TypeScript into shader code 07:00 Type inference, primitives, structs, and TypeScript magic 08:21 Leveraging existing tooling via Unplugin + bundler integration 09:15 How TypeGPU extracts ASTs and generates TinyEST metadata 10:10 Runtime shader generation vs build-time macros 11:07 How the AST is traversed + maintaining transparency in output 11:43 Example projects like Jelly Shader and community reception 12:05 Brought to you by Sentry.io 12:30 Does TypeGPU replace 3JS? How it fits the existing ecosystem 13:20 Low-level control vs high-level abstractions 14:04 Upcoming Three.js integration – plugging TypeGPU into materials compute shaders 15:34 Making GPU development more approachable 16:26 Docs, examples, and the philosophy behind TypeGPU documentation 17:03 Building features by building examples first 18:13 Using examples as a test suite + how docs shape API design 19:00 Docs as a forcing function for intuitive APIs 20:21 GPU for AI – browser inference and future abstractions 21:11 How AI examples inform new libraries (noise, inference, etc.) 21:57 Keeping the core package small and flexible 22:44 Building “TypeGPU AI”-style extensions without bloating the core 23:07 The cost of AI examples and building everything from scratch 23:41 Standard library design and future of the ecosystem 24:04 Closing thoughts from Iwo – OSS, GPU renaissance, and encouragement 24:34 Sick Picks & Shameless Plugs Sick Picks Iwo: Perogies Shameless Plugs Iwo: Syntax Podcast 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

Doom has seemingly been ported to every electronic device imaginable, including picture frames, lamps, and coffee machines. The meme of “it runs Doom” has become so widespread that it spawned the r/itrunsdoom sub-Reddit. Recently, Doom made headlines again for being ported to TypeScript. The project involved representing Doom entirely in TypeScript, three and a half The post Running Doom in TypeScript with Dimitri Mitropoulos appeared first on Software Engineering Daily.

Doom has seemingly been ported to every electronic device imaginable, including picture frames, lamps, and coffee machines. The meme of “it runs Doom” has become so widespread that it spawned the r/itrunsdoom sub-Reddit. Recently, Doom made headlines again for being ported to TypeScript. The project involved representing Doom entirely in TypeScript, three and a half The post Running Doom in TypeScript with Dimitri Mitropoulos appeared first on Software Engineering Daily.

In this episode, we dive into NASA's first test flight of the ultra-quiet X-59 supersonic jet, explore the futuristic Phantom transparent 4K monitor, and break down World Labs' breakthrough 3D world-modeling AI. We also cover TypeScript's unexpected rise in the AI era, the world's first mass delivery of humanoid factory workers, and how you can now run powerful open-source AI models locally. It's a packed show full of aviation, robotics, and cutting-edge tech that's reshaping the future. Want to be a Guest on a Podcast or YouTube Channel? Sign up for GuestMatch.Pro Thinking of buying a Starlink? Use my link to support the show. Don’t tell me you’ve been using the same password for every site? You’ll thank me later, Get 1Password. Subscribe to the Newsletter. Email Ray if you want to get in touch! Like and Follow Geek News Central’s Facebook Page. Support my Show Sponsor: Best Godaddy Promo Codes $11.99 – For a New Domain Name cjcfs3geek $6.99 a month Economy Hosting (Free domain, professional email, and SSL certificate for the 1st year.) Promo Code: cjcgeek1h $12.99 a month Managed WordPress Hosting (Free domain, professional email, and SSL certificate for the 1st year.) Promo Code: cjcgeek1w Support the show by becoming a Geek News Central Insider Full Summary In episode 1852 of the Geek News Central podcast, host Ray Cochrane welcomes listeners back after a brief hiatus, explaining the delay due to personal and professional commitments. He kicks off the show by discussing an exciting breakthrough from NASA: the successful test flight of the X-59, an experimental aircraft designed to quiet the sonic boom, potentially paving the way for commercial supersonic flight over land. Ray notes that the X-59, which resembles a swordfish, recently completed its first test flight in California, focusing on functionality rather than speed. It is intended to gather data on the aircraft’s noise impact on communities, indicating a significant step towards improving commercial travel times. After this, Ray thanks the podcast’s sponsor, GoDaddy, highlighting their hosting services and mentioning various promotional offers. He encourages listeners to support the show directly through the GoDaddy links, emphasizing their reliability in supporting the podcast. Following the sponsor message, Ray transitions into another topic, discussing a new prototype transparent 4K monitor named the Phantom developed by Virtual Instruments. The monitor is designed to allow users to see their environment through the screen while achieving remarkable brightness levels. Next, he introduces an innovative AI model called Marble developed by Fei Fei Li's startup, World Labs. Ray explains that this platform enables users to generate 3D worlds from simple prompts, marking a shift towards spatial intelligence in AI, which is essential for gaming, robotics, and visual effects. Ray then moves on to discuss TypeScript’s rise in the programming world, which has overtaken JavaScript and Python as the most used language on GitHub due to its compatibility with AI-assisted coding. He continues with news about UbiTech’s Walker S2 humanoid robots, which have begun mass delivery to factories, signifying a major milestone in manufacturing automation and the potential implications for the labor market. Ray finishes with information on the growing trend of running local open-source AI models on personal computers. He emphasizes the privacy advantages of using models like Llama and Mistral locally without relying on cloud providers. In closing, Ray reflects on the episode’s diverse topics and invites listener feedback regarding the content. He expresses gratitude for their support and encourages them to send comments or suggestions for future episodes. Ray ends by wishing everyone a good night and promising to return with more episodes soon. Show Links NASA X-59 Quiet Supersonic Test Flight Phantom Transparent 4K Monitor Fei-Fei Li's World Labs Launches Marble TypeScript's Rise in the AI Era (Hejlsberg Interview) UBTECH's First Large Delivery of Humanoid Workers How to Run Your Own Local Open-Source AI Model The post From NASA's X-59 to Humanoid Workers: The Future Is Getting Weird # 1852 appeared first on Geek News Central.

פרק מספר 505 של רברס עם פלטפורמה - באמפרס מספר 89, שהוקלט ב-13 בנובמבר 2025, רגע אחרי כנס רברסים 2025 [יש וידאו!]: רן, דותן ואלון (והופעת אורח של שלומי נוח!) באולפן הוירטואלי עם סדרה של קצרצרים מרחבי האינטרנט: הבלוגים, ה-GitHub-ים, ה-Claude-ים וה-GPT-ים החדשים מהתקופה האחרונה.

Jack Herrington talks with Will Madden about how Prisma ORM is evolving in v7, including the transition away from Rust toward TypeScript, less magic, and a new Prisma config file for more predictable good DX. They dig into Prisma Postgres, improvements to Prisma Studio, better support for serverless environments, and how JavaScript ORM tools like Prisma as an object relational mapper will fit into future agentic coding workflows powered by LLMs. Links LinkedIn: https://www.linkedin.com/in/willmadden Resources ORM: https://www.prisma.io/blog/orm-6-12-0-esm-compatible-generator-in-preview-and-new-options-for-prisma-config https://www.prisma.io/blog/why-prisma-orm-generates-code-into-node-modules-and-why-it-ll-change https://www.prisma.io/blog/from-rust-to-typescript-a-new-chapter-for-prisma-orm https://www.prisma.io/blog/try-the-new-rust-free-version-of-prisma-orm-early-access https://www.prisma.io/blog/rust-free-prisma-orm-is-ready-for-production Prisma Postgres: prisma.io/postgres 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)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ 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 understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters

In this potluck episode, Wes and Scott answer your questions about paid vs. free SSL, the state of frontend jobs, headless WordPress trade-offs, organizing TypeScript types, and more! Show Notes 00:00 Welcome to Syntax! 00:51 Recapping the GitHub Meetup 05:14 Is there any real benefit to picking a paid SSL over Let's Encrypt? 08:03 Is the pure frontend role disappearing? 11:17 Is the gravy train over for software devs? 20:48 How Scott automates versioning with GitHub Actions changesets Intro to using changesets zero-svelte graffiti 25:16 Brought to you by Sentry.io 25:41 Thoughts on VS Code alternatives and the rise of Zed 33:01 Should I switch to headless WordPress or continue rolling my own PHP templates? 37:33 How do you organize TypeScript types in a frontend project? 40:55 How do I continue to level up as a developer? 45:36 Stay in a comfortable job or embrace new challenges? 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

In this episode of the HTML All The Things Podcast, Mike walks through the new web development tech that's been landing on his radar. From next-gen formatters and bundlers to emerging UI frameworks and terminal-UI toolkits, Mike breaks down what each tool is, why it matters, and where its limitations are today. In this episode Matt and Mike cover: BiomeJS - all-in-one formatter/linter with strong Prettier compatibility Ripple - an experimental TypeScript-first UI framework TanStack Start - a router-first full-stack framework for React/Solid Hono.js - tiny, blazing-fast multi-runtime web framework Rolldown - Rust-powered bundler with major Vite build speed gains Effect - type-safe effects/concurrency runtime for TypeScript OpenTUI - build rich terminal UIs using React/Solid renderers If you want a curated look at early-stage tools shaping how we might build for the web in 2025, Mike's got you covered. Show Notes: https://www.htmlallthethings.com/podcast/new-web-development-tech-thats-on-my-radar Powered by CodeRabbit - AI Code Reviews: https://coderabbit.link/htmlallthethings Use our Scrimba affiliate link (https://scrimba.com/?via=htmlallthethings) for a 20% discount!! Full details in show notes.

In this episode of PodRocket, Jack and Paige dive into the latest GitHub Octoverse report, covering trends like shipping faster with AI, the dominance of TypeScript as the top language, the rise of AI-generated pull requests, and the concerning drop in code review comments. They unpack the growing role of Copilot, the tension between OSS contributions and burnout, and the surge in AI infrastructure projects like Ollama. The discussion also touches on open source governance, the docs gap, prompt injection risks, and whether AI-powered browsers can succeed beyond the dev crowd. Links Resources Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1 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)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ 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 understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters 01:15 – What is GitHub's Octoverse Report? 02:15 – Shipping Faster with AI 03:45 – Copilot's Impact on Code Quality 05:15 – TypeScript Takes the Lead 06:30 – Concerns About AI PR Volume 07:45 – Decline in Code Reviews 09:15 – OSS Maintenance Crisis 11:00 – GitHub Copilot and Funding OSS 12:30 – Where AI Actually Helps Devs 14:00 – Small Models and Running Locally 16:00 – TypeScript vs Python: Stack Implications 18:30 – Language Trends and AI Consolidation 21:00 – Framework and Stack Fragility in AI Era 24:00 – Docs Gap in OSS Projects 26:30 – Open Source Governance and Security Gaps 30:00 – AI Infrastructure Projects Leading GitHub 33:00 – Will AI Browsers Catch On? 35:00 – Prompt Injection and Security Risks 37:00 – Opportunity in OSS Documentation 39:30 – Final Thoughts and Hot Takes Special Guest: Jack Herrington.

This week, we discuss cloud earnings, Siri teaming up with Gemini, and AI bottlenecks. Plus, is cloning your dog weird? Watch the YouTube Live Recording of Episode (https://www.youtube.com/live/1FjknxuDc9Y?si=JH6rSQHErGMQQp9w) 545 (https://www.youtube.com/live/1FjknxuDc9Y?si=JH6rSQHErGMQQp9w) Runner-up Titles Stack the deck Pets and Chickens Blame it on Android They're fungible Are they going to have to introduce a new principle? Managers of rocks The world we live in Marketing wins We're the healthy skeptics Rundown Ex-NFL star QB Brady claims his dog is a clone (https://www.espn.com/nfl/story/_/id/46848973/tom-brady-says-dog-clone-family-previous-pet) Cloud Earnings AI & Cloud Trends for October 2025 (https://www.thecloudcast.net/2025/11/ai-cloud-trends-for-october-2025.html) Alphabet tops $100 billion quarterly revenue for first time, cloud grows 34% (https://www.cnbc.com/amp/2025/10/29/alphabet-google-q3-earnings.html) Google Cloud Q3 revenue surges 34% as backlog hits $155 billion (https://www.constellationr.com/blog-news/insights/google-cloud-q3-revenue-surges-34-backlog-hits-155-billion) Microsoft Azure sees 40% revenue growth in Q1 (https://www.constellationr.com/blog-news/insights/microsoft-azure-sees-40-revenue-growth-q1) Meta stock drops 10% as heightened AI spending overshadows strong results (https://www.cnbc.com/2025/10/30/meta-stock-earnings-ai-spend.html) Amazon revenues rise 13% on strength in cloud computing unit (https://giftarticle.ft.com/giftarticle/actions/redeem/b798e937-c39d-4e40-84a6-aa9210774e49) Clouded Judgement 10.31.25 - Cloud Giants Report Q3 (https://cloudedjudgement.substack.com/p/clouded-judgement-103125-cloud-giants?utm_source=post-email-title&publication_id=56878&post_id=177617088&utm_campaign=email-post-title&isFreemail=true&r=2l9&triedRedirect=true&utm_medium=email) 7m OpenAI work users (https://openai.com/index/1-million-businesses-putting-ai-to-work/) Amazon's culture went the wrong way (https://cote.io/2025/11/01/amazons-culture-went-the-wrong.html) Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1 (https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) What do we think of GitHub saying there are 180m developers in the world? (https://cote.io/2025/10/31/what-do-we-think-of.html) AWS and OpenAI announce multi-year strategic partnership (https://www.aboutamazon.com/news/aws/aws-open-ai-workloads-compute-infrastructure) Amazon stock jumps on $38 billion deal with OpenAI to use hundreds of thousands of Nvidia chips (https://finance.yahoo.com/news/amazon-stock-jumps-on-38-billion-deal-with-openai-to-use-hundreds-of-thousands-of-nvidia-chips-145357373.html) Relevant to your Interests Azure outage: Microsoft still working on fix, says recovery expected in several hours (https://www.cnbc.com/2025/10/29/microsoft-hit-with-azure-365-outage-ahead-of-quarterly-earnings.html) Microsoft takes $3.1 billion hit from OpenAI investment (https://www.cnbc.com/amp/2025/10/29/microsoft-open-ai-investment-earnings.html) Meta Stock Slides After Earnings. (https://www.investors.com/news/technology/meta-stock-q3-2025-earnings-ai-meta-news-zuckerberg/) AWS to Bare Metal Two Years Later: Answering Your Toughest Questions (https://oneuptime.com/blog/post/2025-10-29-aws-to-bare-metal-two-years-later/view) Meta denies torrenting porn to train AI, says downloads were for “personal use” (https://arstechnica.com/tech-policy/2025/10/meta-says-porn-downloads-on-its-ips-were-for-personal-use-not-ai-training/) Shocker! Reversal in AI ROI slide-wisdom: AI does works well (https://cote.io/2025/11/01/shocker-reversal-in-ai-roi.html) SaaS Monopoly | Khushi Lunkad (https://www.linkedin.com/posts/khushilunkad_saas-monopoly-activity-7390752595469914112-UWVw?utm_medium=ios_app&rcm=ACoAAADVjQ8Btsl3lKfl-gEYa6_6hmjCdJyRJyw&utm_source=social_share_send&utm_campaign=copy_link) The State of Developer Experience and Developer Productivity (https://lp.jetbrains.com/devex-productivity-report-full-2025-dataviz/?tab-OneOfTabWrapperBlock-1756889760421-44980=their-top-pain-points-) Why the “Free” Chef Version Could Be Your Most Expensive Mistake | Chef (https://www.chef.io/blog/chef-open-source-software-advice) Nonsense Disney yanks channels from YouTube TV after media giants fail to resolve carriage dispute | CNN Business (https://www.cnn.com/2025/10/30/media/disney-youtube-deal-biz-hnk) Traffic hits record high as commuters rewrite the rush hour - Texas A&M Transportation Institute (https://tti.tamu.edu/2025/10/traffic-hits-record-high-as-commuters-rewrite-the-rush-hour/) Denny's to be acquired and taken private in a deal valued at $620 million (https://apnews.com/article/dennys-investors-deal-private-company-f626f6b8c27f29f698a5c823ba855fc3) Conferences SREDay Amsterdam (https://sreday.com/2025-amsterdam-q4/), November 7th, Coté speaking. Wiz Wizdom Conferences (https://www.wiz.io/wizdom), November 17-19, London DevOpsDayLA at SCALE23x (https://www.socallinuxexpo.org/scale/23x), March 6th, Pasadena, CA Use code: DEVOP for 50% off. CFP open until Dec. 1st. SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Book offer: Use code SDT for $20 off "Digital WTF" by Coté (https://leanpub.com/digitalwtf/c/sdt) Sponsor the show (https://www.softwaredefinedtalk.com/ads): ads@softwaredefinedtalk.com (mailto:ads@softwaredefinedtalk.com) Recommendations Brandon: Liquid Glass Transparency Toggle (https://www.macrumors.com/guide/ios-26-1-features/) Matt: The Other Two (https://www.imdb.com/title/tt8310612) Coté: NØLSON shirts (https://nolson.nl) Photo Credits Header (https://unsplash.com/photos/a-dog-sniffing-a-box-full-of-chickens-wyCOBbCztVw)

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

AI-powered web browsers are hitting the scene fast, but Steve and Leo unpack why these smart assistants could usher in an era of security chaos most users aren't ready for. Brace yourself for the wild risks, real-world scams, and the privacy questions no one else is asking. Secret radios discovered in Chinese-made busses. Edge & Chrome introduce LLM-based "scareware" blocking. A perfect example of what scareware blocking hopes to prevent. Aardvark: OpenAI's new vulnerability scanner for code. Italy to require age verification from 48 specific sites. Russia to require the use of only Russian software within Russia. Russia further clamping down on non-MAX Telegram and WhatsApp messaging. 187 new malicious NPM packages. Could AI help with that? BadCandy malware has infiltrated Australian Cisco routers. Github's 2025 report with the dominance of TypeScript. Windows 11 gets new extra-secure Admin Protection feature. A bunch of interesting feedback and listener thoughts. And why the new AI-driven web browsers may be bringing a whole new world of hurt Show Notes - https://www.grc.com/sn/SN-1050-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to Security Now at https://twit.tv/shows/security-now. You can submit a question to Security Now at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Join Club TWiT for Ad-Free Podcasts! Support what you love and get ad-free shows, a members-only Discord, and behind-the-scenes access. Join today: https://twit.tv/clubtwit Sponsors: bitwarden.com/twit joindeleteme.com/twit promo code TWIT canary.tools/twit - use code: TWIT bigid.com/securitynow threatlocker.com for Security Now

In this episode, Matt and Mike compare JavaScript and Python for building LLM-powered chatbots. They explore how each ecosystem handles tool calling, type safety, performance, and framework support — from TypeScript's tight end-to-end types to Python's dominance in data and ML. They also discuss architecture patterns that mix the best of both worlds, helping teams choose the right stack for scalable, efficient AI projects. Show Notes: https://www.htmlallthethings.com/podcast/javascript-vs-python-which-is-better-for-building-llm-chatbots Powered by CodeRabbit - AI Code Reviews: https://coderabbit.link/htmlallthethings Use our Scrimba affiliate link (https://scrimba.com/?via=htmlallthethings) for a 20% discount!! Full details in show notes.

In this conversation with Malte Ubl, CTO of Vercel (http://x.com/cramforce), we explore how the company is pioneering the infrastructure for AI-powered development through their comprehensive suite of tools including workflows, AI SDK, and the newly announced agent ecosystem. Malte shares insights into Vercel's philosophy of “dogfooding” - never shipping abstractions they haven't battle-tested themselves - which led to extracting their AI SDK from v0 and building production agents that handle everything from anomaly detection to lead qualification.The discussion dives deep into Vercel's new Workflow Development Kit, which brings durable execution patterns to serverless functions, allowing developers to write code that can pause, resume, and wait indefinitely without cost. Malte explains how this enables complex agent orchestration with human-in-the-loop approvals through simple webhook patterns, making it dramatically easier to build reliable AI applications.We explore Vercel's strategic approach to AI agents, including their DevOps agent that automatically investigates production anomalies by querying observability data and analyzing logs - solving the recall-precision problem that plagues traditional alerting systems. Malte candidly discusses where agents excel today (meeting notes, UI changes, lead qualification) versus where they fall short, emphasizing the importance of finding the “sweet spot” by asking employees what they hate most about their jobs.The conversation also covers Vercel's significant investment in Python support, bringing zero-config deployment to Flask and FastAPI applications, and their vision for security in an AI-coded world where developers “cannot be trusted.” Malte shares his perspective on how CTOs must transform their companies for the AI era while staying true to their core competencies, and why maintaining strong IC (individual contributor) career paths is crucial as AI changes the nature of software development.What was launched at Ship AI 2025:AI SDK 6.0 & Agent Architecture* Agent Abstraction Philosophy: AI SDK 6 introduces an agent abstraction where you can “define once, deploy everywhere”. How does this differ from existing agent frameworks like LangChain or AutoGPT? What specific pain points did you observe in production that led to this design?* Human-in-the-Loop at Scale: The tool approval system with needsApproval: true gates actions until human confirmation. How do you envision this working at scale for companies with thousands of agent executions? What's the queue management and escalation strategy?* Type Safety Across Models: AI SDK 6 promises “end-to-end type safety across models and UI”. Given that different LLMs have varying capabilities and output formats, how do you maintain type guarantees when swapping between providers like OpenAI, Anthropic, or Mistral?Workflow Development Kit (WDK)* Durability as Code: The use workflow primitive makes any TypeScript function durable with automatic retries, progress persistence, and observability. What's happening under the hood? Are you using event sourcing, checkpoint/restart, or a different pattern?* Infrastructure Provisioning: Vercel automatically detects when a function is durable and dynamically provisions infrastructure in real-time. What signals are you detecting in the code, and how do you determine the optimal infrastructure configuration (queue sizes, retry policies, timeout values)?Vercel Agent (beta)* Code Review Validation: The Agent reviews code and proposes “validated patches”. What does “validated” mean in this context? Are you running automated tests, static analysis, or something more sophisticated?* AI Investigations: Vercel Agent automatically opens AI investigations when it detects performance or error spikes using real production data. What data sources does it have access to? How does it distinguish between normal variance and actual anomalies?Python Support (For the first time, Vercel now supports Python backends natively.)Marketplace & Agent Ecosystem* Agent Network Effects: The Marketplace now offers agents like CodeRabbit, Corridor, Sourcery, and integrations with Autonoma, Braintrust, Browser Use. How do you ensure these third-party agents can't access sensitive customer data? What's the security model?“An Agent on Every Desk” Program* Vercel launched a new program to help companies identify high-value use cases and build their first production AI agents. It provides consultations, reference templates, and hands-on support to go from idea to deployed agentFull Video EpisodeTimestamps00:00 Introduction and Malte's Background at Google01:16 Vercel's AI Engineering Philosophy and Ship AI Recap03:19 Deep Dive: Workflows vs Agents Architecture09:33 AI SDK Success Story: Staying Low-Level and Humble16:35 Framework Design Principles and Open Source Strategy19:20 Vercel Agent: AI-Powered DevOps and Anomaly Detection27:06 Internal Agent Use Cases: Lead Qualification and Abuse Analysis29:49 Agent on Every Desk Program and Enterprise Adoption32:13 Python Support and Multi-Language Infrastructure39:42 The Future of AI-Native Security and Development Get full access to Latent.Space at www.latent.space/subscribe

In this conversation with Malte Ubl, CTO of Vercel (http://x.com/cramforce), we explore how the company is pioneering the infrastructure for AI-powered development through their comprehensive suite of tools including workflows, AI SDK, and the newly announced agent ecosystem. Malte shares insights into Vercel's philosophy of "dogfooding" - never shipping abstractions they haven't battle-tested themselves - which led to extracting their AI SDK from v0 and building production agents that handle everything from anomaly detection to lead qualification. The discussion dives deep into Vercel's new Workflow Development Kit, which brings durable execution patterns to serverless functions, allowing developers to write code that can pause, resume, and wait indefinitely without cost. Malte explains how this enables complex agent orchestration with human-in-the-loop approvals through simple webhook patterns, making it dramatically easier to build reliable AI applications. We explore Vercel's strategic approach to AI agents, including their DevOps agent that automatically investigates production anomalies by querying observability data and analyzing logs - solving the recall-precision problem that plagues traditional alerting systems. Malte candidly discusses where agents excel today (meeting notes, UI changes, lead qualification) versus where they fall short, emphasizing the importance of finding the "sweet spot" by asking employees what they hate most about their jobs. The conversation also covers Vercel's significant investment in Python support, bringing zero-config deployment to Flask and FastAPI applications, and their vision for security in an AI-coded world where developers "cannot be trusted." Malte shares his perspective on how CTOs must transform their companies for the AI era while staying true to their core competencies, and why maintaining strong IC (individual contributor) career paths is crucial as AI changes the nature of software development. What was launched at Ship AI 2025: AI SDK 6.0 & Agent Architecture Agent Abstraction Philosophy: AI SDK 6 introduces an agent abstraction where you can "define once, deploy everywhere". How does this differ from existing agent frameworks like LangChain or AutoGPT? What specific pain points did you observe in production that led to this design? Human-in-the-Loop at Scale: The tool approval system with needsApproval: true gates actions until human confirmation. How do you envision this working at scale for companies with thousands of agent executions? What's the queue management and escalation strategy? Type Safety Across Models: AI SDK 6 promises "end-to-end type safety across models and UI". Given that different LLMs have varying capabilities and output formats, how do you maintain type guarantees when swapping between providers like OpenAI, Anthropic, or Mistral? Workflow Development Kit (WDK) Durability as Code: The use workflow primitive makes any TypeScript function durable with automatic retries, progress persistence, and observability. What's happening under the hood? Are you using event sourcing, checkpoint/restart, or a different pattern? Infrastructure Provisioning: Vercel automatically detects when a function is durable and dynamically provisions infrastructure in real-time. What signals are you detecting in the code, and how do you determine the optimal infrastructure configuration (queue sizes, retry policies, timeout values)? Vercel Agent (beta) Code Review Validation: The Agent reviews code and proposes "validated patches". What does "validated" mean in this context? Are you running automated tests, static analysis, or something more sophisticated? AI Investigations: Vercel Agent automatically opens AI investigations when it detects performance or error spikes using real production data. What data sources does it have access to? How does it distinguish between normal variance and actual anomalies? Python Support (For the first time, Vercel now supports Python backends natively.) Marketplace & Agent Ecosystem Agent Network Effects: The Marketplace now offers agents like CodeRabbit, Corridor, Sourcery, and integrations with Autonoma, Braintrust, Browser Use. How do you ensure these third-party agents can't access sensitive customer data? What's the security model? "An Agent on Every Desk" Program Vercel launched a new program to help companies identify high-value use cases and build their first production AI agents. It provides consultations, reference templates, and hands-on support to go from idea to deployed agent

Most AI agent frameworks are backend-focused and written in Python, which introduces complexity when building full-stack AI applications with JavaScript or TypeScript frontends. This gap makes it harder for frontend developers to prototype, integrate, and iterate on AI-powered features. Mastra is an open-source TypeScript framework focused on building AI agents and has primitives such as The post Building AI Agents on the Frontend with Sam Bhagwat and Abhi Aiyer appeared first on Software Engineering Daily.

In this episode, we sit down with Paul Klein IV, Founder & CEO of Browserbase, to explore how his team is redefining the foundation of AI-driven browser automation. Browserbase provides the web browser infrastructure for AI agents and apps, and its open-source SDK, Stagehand, lets developers write automations using natural language - adapting seamlessly as websites evolve.Paul shares his belief that browser automation is a critical but underinvested primitive that future AI applications will depend on for years. He traces the journey from the limitations of traditional headless browsers and brittle RPA tools to the emergence of a cleaner, more adaptable framework built for the AI era.We dive into:Stagehand's design philosophy: minimal feature bloat and strong abstractions.Developer-first community: TypeScript and Python support driven by user demand and open-source contributions prioritized through community PRs.Director, Browserbase's new layer for non-technical users: “if v0 was for building websites, Director is for building automations.”How open source investment fuels both innovation and integration, and why Browserbase believes the next billion-dollar company will be built on top of its framework.The evolving relationship between AI agents and the web, touching on Cloudflare, automation ethics, and where the line lies between automation and scraping.Paul also reflects on inspiration from figures like Jeff Lawson, the importance of great abstractions for new developers, and the “moment of magic” when AI begins to work on your behalf.

In this solo-hosted episode, I (Steve Edwards) dive deep into the world of modern monorepos with special guest Anton Stoychev from Yotpo. Anton shares his journey from the early days of PHP and IE6 nightmares to his current work in front-end infrastructure, performance optimization, and developer tooling.We talk about the challenges of managing dependencies, upgrading tools without breaking your codebase, and the evolution of developer experience across teams and companies. Anton also introduces Breakproof, Yotpo's open-source monorepo template designed to make dependency management and tool upgrades painless—even when working with multiple Node.js versions, runtimes like Bun and Deno, and complex CI environments.If you've ever struggled with upgrading Jest, ESLint, or TypeScript in a large monorepo, or you're curious how to isolate dependencies to keep your codebase maintainable over time, this episode is a must-listen.

Dominic Gannaway joins us to talk about Ripple.js, a new TypeScript-first UI framework built with its own templating language and a focus on clarity and reactivity. We explore how Ripple.js handles fine-grained updates through its track and block system, why it avoids global state, and how context plays a key role. Dominic also walks us through the developer experience, from the language server and VS Code integration to syntax highlighting and the Prettier plugin, plus how the framework handles error boundaries, server-side rendering, future plans, and more. Links Twitter: https://x.com/trueadm Github: https://github.com/trueadm LinkedIn: https://www.linkedin.com/in/dominic-gannaway-414b7750 Resources RippleJS GitHub: https://ripplejs.github.io RippleJS website: https://www.ripplejs.com/ 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)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ 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 understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters 00:00 – Intro & What is RippleJS 01:00 – The Origins and Naming of Ripple 02:00 – A New UI Framework Built on TypeScript 03:30 – Creating a Custom Language and Templating System 05:00 – Building Ripple's Tooling and Language Server 06:00 – The Team, Open Source Growth, and Early Feedback 07:00 – From UI Framework to Meta Framework 09:00 – Integrating AI into the Dev Server 10:30 – Handling Controversy and Changing the Status Quo 11:30 – How Ripple Was Built in a Week 13:00 – Redesigning the Reactivity System 16:00 – Why Ripple Doesn't Use Global State 19:00 – Lessons Learned from Other Frameworks 21:00 – Naming Conventions and API Design Decisions 22:30 – Error Boundaries and Async Patterns in Ripple 24:00 – Accessibility and ByteDance Native App Integration 25:00 – The Team's Workflow and Contributor Culture 27:00 – Building TypeScript-First from Scratch 29:00 – Language Server, Source Maps, and VS Code Integration 31:00 – Building in Public and Open Source Collaboration 32:30 – The Future of Frontend Frameworks 34:00 – How Ripple's Ideas Might Influence Others 35:00 – AI, Security, and the Road Ahead 36:00 – Closing Thoughts & How to Get Involved

Ever wondered how source maps actually work? In this episode, Nicolo Ribaudo, Babel maintainer and TC39 delegate, breaks down how source maps connect your JavaScript, TypeScript, and CSS back to the original code — making debugging, stack traces, and observability smoother in Chrome dev tools. We dive into how source maps help in both development and production with minified code, explore tools like Webpack, Rollup, Next.js, and Svelte, and share when you should turn off source maps to avoid confusion. Links Website: https://nicr.dev LinkedIn: https://www.linkedin.com/in/nicol%C3%B2-ribaudo-bb94b4187 BlueSky: https://bsky.app/profile/nicr.dev Github: https://github.com/nicolo-ribaudo Resources Squiggleconf talk: https://squiggleconf.com/2025/sessions#source-maps-how-does-the-magic-work Slide deck: https://docs.google.com/presentation/d/1lyor5xgv821I4kUWJIwrrmXBjzC_qiqIqcZxve1ybw0 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)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabet.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ 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 understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters 00:00 Intro – Welcome to PodRocket + Introducing Nicolo Ribaudo 00:45 What Are Source Maps and Why They Matter for Debugging 01:20 From Babel to TC39 – Nicolo's Path to Source Maps 02:00 Source Maps Beyond JavaScript: CSS, C, and WebAssembly 03:00 The Core Idea – Mapping Compiled Code Back to Source 04:00 How Source Maps Work Under the Hood (Encoded JSON) 05:10 File Size and Performance – Why It Doesn't Matter in Production 06:00 Why Source Maps Are Useful Even Without Minification 07:00 Sentry and Error Monitoring – How Source Maps Are Used in Production 08:10 Two Worlds: Local Debugging vs. Remote Error Analysis 09:00 You're Probably Using Source Maps Without Realizing It 10:00 Why Standardization Was Needed After 15+ Years of Chaos 11:00 TC39 and the Creation of the Official Source Maps Standard 12:00 Coordinating Browsers, Tools, and Vendors Under One Spec 13:00 How Chrome, Firefox, and WebKit Implement Source Maps Differently 14:00 Why the Source Maps Working Group Moves Faster Than Other Standards 15:00 A Small, Focused Group of DevTools Engineers 16:00 How Build Tools and Bundlers Feed Into the Ecosystem 17:00 Making It Easier for Tool Authors to Generate Source Maps 18:00 How Frameworks Like Next.js and Vite Handle Source Maps for You 19:00 Common Pitfalls When Chaining Build Tools 20:00 Debugging Wrong or Broken Source Maps in Browsers 21:00 Upcoming Feature: Scopes for Variables and Functions 22:00 How Scopes Improve the Live Debugging Experience 23:00 Experimental Implementations and How to Try Them 24:00 Where to Find the TC39 Source Maps Group + Get Involved 25:00 Nicolo's Links – GitHub, BlueSky, and Talks Online 25:30 Closing Thoughts

Show DescriptionDave and Chris discuss the release of Safari in iOS26, the aesthetics of Liquid Glass in CSS, the importance of material design, and the role of TypeScript in modern web development. The conversation also touches on when to consider rebuilding a tech stack, the significance of user experience, and how to know when to choose a new tech stack. Listen on WebsiteLinks Apple has a private CSS property to add Liquid Glass effects to web content Syntax - Web Development Podcast Theo - t3․gg - YouTube Gina Trapani Foursight Omakub — An Omakase Developer Setup for Ubuntu 24.04+ by DHH

Traditional package management systems for JavaScript have faced several inefficiencies related to dependency storage, resolution, and project performance. pnpm is a fast, disk-efficient package manager for JavaScript and TypeScript projects, serving as an alternative to npm and Yarn. Due to its efficiency and reliability, pnpm is increasingly popular for managing monorepos and large-scale applications. Zoltan The post pnpm with Zoltan Kochan appeared first on Software Engineering Daily.

Modern web development faces several challenges, particularly when building scalable, maintainable, and high-performance applications. As applications grow, managing complex user interfaces, and ensuring efficient data handling and modular code structures, becomes increasingly difficult. Angular is a TypeScript-based web framework developed by Google. It's component-driven and designed for building single-page applications with a strong emphasis on The post Angular with Jessica Janiuk appeared first on Software Engineering Daily.