Podcasts about Rob Pike

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

Mat Ryer is back and he brought his impromptu musical abilities with him! We discuss Rob Pike vs thankful AI, Microsoft's GitHub monopoly (and what it means for open source), and Tom Tunguz' 12 predictions for 2026: agent-first design, the rise of vector databases, and are we about to pay more for AI than people?!

Mat Ryer is back and he brought his impromptu musical abilities with him! We discuss Rob Pike vs thankful AI, Microsoft's GitHub monopoly (and what it means for open source), and Tom Tunguz' 12 predictions for 2026: agent-first design, the rise of vector databases, and are we about to pay more for AI than people?!

Episode S12E09 avec Aurélien, Sébastien B., et Xavier.• (00:00:00) : • Baisse du nombre de questions sur StackOverflow (00:01:45) : Vers la fin des forums de Questions Réponses pour les devs suite à l'avancée des IA? (Sources : techzine.eu, 36kr.com et theverge.com) • Et si on faisait tourner Windows, sur Linux? (00:19:46) : Et Loss32 est né. (Sources : theregister.com et loss32.org) • Michelin acquiert 2 entreprises aux USA (00:27:41) : Michelin s'éloigne du pneu pour booster sa croissance. (Sources : lamontagne.fr et boursorama.com) • CES: Huyndai va équiper ses usines des robots Atlas (00:38:19) : Avec le robot Atlas de Boston Dynamics, le robot devient un acteur économique réel. (Sources : bostondynamics.com, numerama.com et 01net.com) • Peppol, un acronyme qui empêche la Belgique de dormir (00:52:21) : Simplification ou outil de contrôle? (Source : levif.be) • Rob Pike dit ses vérités à l'IA (01:13:18) : L'un des pionniers s'inquiète de l'avenir de l'informatique. (Source : developpez.com) Retrouvez toutes nos informations, liens, versions du podcast via notre site Abonnez-vous à notre infolettre afin d'être informé de notre veille technologique de la semaine et de la parution de nos épisodes

After receiving an Al generated email, the programming legend (known for his work on Go, Plan 9, UNIX, & UTF-8) says, "F**k you people. Raping the planet."More from The Lunduke Journal:https://lunduke.com/ This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit lunduke.substack.com/subscribe

This is a recap of the top 10 posts on Hacker News on December 26, 2025. This podcast was generated by wondercraft.ai (00:30): Rob Pike goes nuclear over GenAIOriginal post: https://news.ycombinator.com/item?id=46392115&utm_source=wondercraft_ai(01:50): How uv got so fastOriginal post: https://news.ycombinator.com/item?id=46393992&utm_source=wondercraft_ai(03:11): Package managers keep using Git as a database, it never works outOriginal post: https://news.ycombinator.com/item?id=46391514&utm_source=wondercraft_ai(04:31): Rob Pike Goes Nuclear over GenAIOriginal post: https://news.ycombinator.com/item?id=46389444&utm_source=wondercraft_ai(05:52): FFmpeg has issued a DMCA takedown on GitHubOriginal post: https://news.ycombinator.com/item?id=46394327&utm_source=wondercraft_ai(07:12): Seven Diabetes Patients Die Due to Undisclosed Bug in Abbott's Glucose MonitorsOriginal post: https://news.ycombinator.com/item?id=46388040&utm_source=wondercraft_ai(08:33): My insulin pump controller uses the Linux kernel. It also violates the GPLOriginal post: https://news.ycombinator.com/item?id=46395184&utm_source=wondercraft_ai(09:53): Experts explore new mushroom which causes fairytale-like hallucinationsOriginal post: https://news.ycombinator.com/item?id=46393936&utm_source=wondercraft_ai(11:14): I'm a laptop weirdo and that's why I like my new Framework 13Original post: https://news.ycombinator.com/item?id=46391410&utm_source=wondercraft_ai(12:34): Rob Pike got spammed with an AI slop "act of kindness"Original post: https://news.ycombinator.com/item?id=46394867&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

In this episode of ACM ByteCast, Bruke Kifle hosts Russ Cox, Distinguished Engineer at Google. Previously, he was the Go language technical lead at Google, where he led the development of Go for more than a decade, with a particular focus on improving the security and reliability of using software dependencies. With Jeff Dean, he created Google Code Search, which let developers grep the world's public source code. He also worked for many years on the Plan 9 operating system from Bell Labs and holds degrees from Harvard and MIT. Russ is a member of the ACM Queue Editorial Board. In the interview, Russ details his journey from the Commodore 64 to Bell Labs, where he met Rob Pike (a co-designer of Go) and contributed to Plan 9 working alongside other legendary figures. Russ shares lessons learned while working on Google Code Search (a highly complex C++ program) and how that informed his later approach to the development and evolution of Go. They delve into the role of Go in the AI era and the future of computing. Russ also discusses the open-source community and collaboration around Go, touches on mentorship and leadership, and offers advice for aspiring builders.

In this very special episode of Book Overflow, Dr. Brian Kernighan, the author of "The Practice of Programming" joins us to discuss his experience writing the book! Tune in as he talks about his experience at Bell Labs, what it was like co-authoring the book with Rob Pike, his thoughts on LLMs and the future of programming, and more!

In this inaugural episode of Book Overflow, Carter Morgan and Nathan Toups discuss "The Practice of Programming" by Brian Kernighan and Rob Pike. Written in 1999, Carter and Nathan discuss its timeless advice around style guides, interfaces, and debugging, as well as reflecting on how the software engineering industry has changed in the 25 years since it's been written.

Daniel Stenberg is frustrated with the state of AI tooling for finding security bugs, Brian Birtles is surprised by weird things engineers believe about web dev, Feross Aboukhadijeh details the fallout from a nasty npm prank, Rob Pike shares what he thinks they got right and wrong with Go & Gavin Howard writes up why he believes “all code is tech debt” is all wrong.

Daniel Stenberg is frustrated with the state of AI tooling for finding security bugs, Brian Birtles is surprised by weird things engineers believe about web dev, Feross Aboukhadijeh details the fallout from a nasty npm prank, Rob Pike shares what he thinks they got right and wrong with Go & Gavin Howard writes up why he believes “all code is tech debt” is all wrong.

Daniel Stenberg is frustrated with the state of AI tooling for finding security bugs, Brian Birtles is surprised by weird things engineers believe about web dev, Feross Aboukhadijeh details the fallout from a nasty npm prank, Rob Pike shares what he thinks they got right and wrong with Go & Gavin Howard writes up why he believes “all code is tech debt” is all wrong.

Rob Pike says, “Simplicity is the art of hiding complexity.” If that's true, what is simplicity in the context of writing software in Go? Is it even something we should strive for? Can software be too simple? Ian & Kris discuss with return guest sam boyer.

Rob Pike says, “Simplicity is the art of hiding complexity.” If that's true, what is simplicity in the context of writing software in Go? Is it even something we should strive for? Can software be too simple? Ian & Kris discuss with return guest sam boyer.

This is a recap of the top 10 posts on Hacker News on November 1st, 2023.This podcast was generated by wondercraft.ai(00:46): Cosmopolitan Third EditionOriginal post: https://news.ycombinator.com/item?id=38101613&utm_source=wondercraft_ai(02:34): Improving deep sleep may prevent dementia, study findsOriginal post: https://news.ycombinator.com/item?id=38097184&utm_source=wondercraft_ai(04:26): Rob Pike's Rules of Programming (1989)Original post: https://news.ycombinator.com/item?id=38097031&utm_source=wondercraft_ai(06:21): FCC launches inquiry to increase minimum broadband speed [pdf]Original post: https://news.ycombinator.com/item?id=38103733&utm_source=wondercraft_ai(08:15): Asahi Linux goes from Apple Silicon port project to macOS bug huntersOriginal post: https://news.ycombinator.com/item?id=38101328&utm_source=wondercraft_ai(10:27): My rude-ass carOriginal post: https://news.ycombinator.com/item?id=38102083&utm_source=wondercraft_ai(12:27): How Bear does analytics with CSSOriginal post: https://news.ycombinator.com/item?id=38095699&utm_source=wondercraft_ai(14:23): Why doctors in America earn so muchOriginal post: https://news.ycombinator.com/item?id=38098779&utm_source=wondercraft_ai(16:07): What the Goddamn Hell Is Going on in the Tech Industry?Original post: https://news.ycombinator.com/item?id=38095542&utm_source=wondercraft_ai(18:04): Why ACPI?Original post: https://news.ycombinator.com/item?id=38095276&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

RobChrisRob returned after weeks apart to pretend to be in low earth orbit to talk about VCV Rack and a new NES emulator module for the synthesier rack simulator, we talked about a screen used X-Wing model that sold at auction for $3.1M, we played a game where you guess classic keyboards via their shift keys, a site that listed chairs used in Star Trek, an ultrasonic kidney stone blaster, Hevry Cavill & Highlander, Estimating the Age of the Moon, Making Oxygen on Mars, the new hottest chili pepper, the Asteroid retrieval mission capsule is kinda stuck shut, a Penn & Teller prank from the 80s with Rob Pike & Dennis Ritchie, and finally a whole mess of Halloween spooktober movies including Suitable Flesh, The Conference, The Ritual, Five Nights at Freddies and whatever else we've been keeping track of lately... Join our discord to talk along or the Subreddit where you will find all the links https://discord.gg/YZMTgpyhB https://www.reddit.com/r/TacoZone/

On today's episode, I speak with Rob Pike from Ryzer Mindset. We talk about how the mental side of the game needs to be worked on just as much as the physical side. We also discuss their TAP assessment and various courses to help with player's mental fitness.     #soccer #collegesoccer #highschoolsoccer #soccercoach #soccercoaches #soccerrecruiting #collegesoccerrecruiting #collegesoccerplayer #highschoolsoccerplayer #ncaa #d1 #d2 #d3 #naia #njcaa #juco #collegerecruiting #soccerlife #clubsoccer #socceracademy #menssoccer #womenssoccer #boyssoccer #girlssoccer   See all our interviews. Check out college soccer ID camp listings. Get valuable free college recruiting resources, all at https://discovercollegesoccer.com/   Join the Discover College Soccer Study Table! Get all the resources you need to manage the college recruiting process! https://discovercollegesoccer.com/studytable --- DON'T FORGET TO SUBSCRIBE! Be sure you subscribe so you can stay up-to-date with our latest videos. --- Follow us here: TWITTER - https://twitter.com/Discover_CS FACEBOOK - https://www.facebook.com/DiscoverCollegeSoccer INSTAGRAM - https://www.instagram.com/discover_cs/ TIKTOK - https://www.tiktok.com/@discover_cs

Array Cast - August 18, 2023 Show NotesThanks to Bob Therriault, Conor Hoekstra, Marshall Lochbaum and Adám Brudzewsky for gathering these links:[01] 00:01:15 Adám's Leet code playlist https://www.youtube.com/watch?v=MUNPk6_ro4o&list=PLYKQVqyrAEj_6ZSDwha9PeftgKKHeDJ7- Jot Dot Times - APL News Aggregator https://apl.news/[02] 00:03:08 Rob Pike https://en.wikipedia.org/wiki/Rob_Pike Talks 2007-20016 https://www.youtube.com/playlist?list=PL3NQHgGj2vtsJkK6ZyTzogNUTqe4nFSWd Go Time podcast #100 - Creating Go https://changelog.com/gotime/100 Ken Thompson https://en.wikipedia.org/wiki/Ken_Thompson Robert Griesemer https://en.wikipedia.org/wiki/Robert_Griesemer Go Programming Language https://en.wikipedia.org/wiki/Go_(programming_language) The Go Programming Language and environment https://www.youtube.com/watch?v=YXV7sa4oM4I Ivy Programming Language https://pkg.go.dev/robpike.io/ivy https://aplwiki.com/wiki/Ivy[03] 00:05:50 UTF-8 https://en.wikipedia.org/wiki/UTF-8[04] 00:07:27 2741 terminal https://en.wikipedia.org/wiki/IBM_2741 TryAPL https://tryapl.org/[05] 00:08:40 Stephen Wolfram https://en.wikipedia.org/wiki/Stephen_Wolfram Mathematica Programming Language https://en.wikipedia.org/wiki/Wolfram_Mathematica Lisp Programming Language https://en.wikipedia.org/wiki/Lisp_programming_language[06] 00:11:09 Plan 9 https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs Bell Labs https://en.wikipedia.org/wiki/Bell_labs[07] 00:12:10 https://en.wikipedia.org/wiki/Google[08] 00:17:20 Russ Cox Advent of Code videos https://www.youtube.com/playlist?list=PLrwpzH1_9ufMLOB6BAdzO08Qx-9jHGfGg[09] 00:18:45 J programming Language https://www.jsoftware.com/#/ Raul Miller episode on the ArrayCast https://www.arraycast.com/episodes/episode59-raul-miller Transcendental functions https://en.wikipedia.org/wiki/Transcendental_function[10] 00:28:35 q Programming Language https://code.kx.com/q/learn/ https://apl.wiki/q Joel Kaplan episode on ArrayCast https://www.arraycast.com/episodes/episode27-joel-kaplan[11] 00:31:21 Ken Iverson https://en.wikipedia.org/wiki/Kenneth_E._Iverson Stop Writing Dead Programs Jack Rusher https://www.youtube.com/watch?v=8Ab3ArE8W3s[12] 00:35:00 Leading axis agreement https://aplwiki.com/wiki/Leading_axis_theory[13] 00:38:15 Arthur Whitney https://en.wikipedia.org/wiki/Arthur_Whitney_(computer_scientist)[14] 00:45:15 Nested Array Theory https://aplwiki.com/wiki/Nested_array[15] 00:50:00 APL wiki https://aplwiki.com/wiki/ Dyalog documentation https://www.dyalog.com/documentation_182.htm#CORE APLwiki documentation for Take https://aplwiki.com/wiki/Take[16] 00:52:09 BQN Programming Language specification https://mlochbaum.github.io/BQN/spec/index.html IBM specification APL2 https://www.ibm.com/downloads/cas/ZOKMYKOY Go Programming Language specification https://go.dev/ref/spec[17] 00:53:25 Rank operator https://aplwiki.com/wiki/Rank_(operator)[18] 00:58:23 Right tack function https://aplwiki.com/wiki/Identity Combinators https://en.wikipedia.org/wiki/Combinatory_logic[19] 01:02:25 John Scholes Game of Life https://www.youtube.com/watch?v=a9xAKttWgP4 Simplicity is Complicated https://www.youtube.com/watch?v=rFejpH_tAHM[20] 01:10:40 Contact AT ArrayCast DOT Com

Leveraging OpenZFS to Build Your Own Storage Appliance, Install OpenBSD as a VM, Set up your own CalDAV and CardDAV servers on OpenBSD, display basic computer information using DMI table decoder, Gpart CheatSheet, Rob Pike on the Origin of Unix Dot File Names, and more NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) and the BSDNow Patreon (https://www.patreon.com/bsdnow) Headlines OpenZFS – Leveraging OpenZFS to Build Your Own Storage Appliance (https://klarasystems.com/articles/openzfs-leveraging-openzfs-to-build-your-own-storage-appliance/) Install OpenBSD as a VM (https://byte-sized.de/linux-unix/openbsd-als-vm-installieren/#english) News Roundup Set up your own CalDAV and CardDAV servers on OpenBSD (https://dataswamp.org/~solene/2023-04-23-calendar-and-contacts-with-radicale.html) How to display basic computer information using DMI table decoder (https://sleeplessbeastie.eu/2023/03/31/how-to-display-basic-computer-information-using-dmi-table-decoder/) Gpart CheatSheet - wiping drives, partitioning, & formating (https://forums.FreeBSD.org/threads/gpart-cheatsheet-wiping-drives-partitioning-formating.45411) Rob Pike on the Origin of Unix Dot File Names (http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html) Beastie Bits Hackerstations Mike McQuaid's clean, ergonomic setup in Edinburgh, Scotland (https://hackerstations.com/setups/mike_mcquaid/) Daniel Stenberg and the home of curl in Stockholm, Sweden (https://hackerstations.com/setups/daniel_stenberg/) viogpu(4), a VirtIO GPU driver, added to -current (http://undeadly.org/cgi?action=article;sid=20230421124221) OpenBGPD 8.0 released (http://undeadly.org/cgi?action=article;sid=20230505054214) cron(8) now supports random ranges with steps (http://undeadly.org/cgi?action=article;sid=20230507122935) malloc leak detection available in -current (http://undeadly.org/cgi?action=article;sid=20230417074903) vmd(8) moves to a multi-process model (https://www.undeadly.org/cgi?action=article;sid=20230430051250) Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv)

The 20th Annual Southern California Linux Expo (SCALE) runs Thursday through Sunday at the Pasadena Convention Center in Pasadena, Ca., featuring keynotes from notables such as Ken Thompson, the creator of Unix, said Ilan Rabinovich, one of the co-founders and conference chair for the conference on this week's edition of The New Stack Makers.  "Honestly, most of the speakers we've had, you know, we got at SCALE in the early days, we just, we, we emailed them and said: 'Would you come to speak at the event?' We ran a call for proposals, and some of them came in as submissions, but a lot of it was just cold outreach. I don't know if that succeeded, because that's the state of where the community was at the time and there wasn't as much demand or just because or out of sheer dumb luck. I assure you, it wasn't skill or any sort of network that we like, we just, you know, we just we managed to, we managed to do that. And that's continued through today. When we do our call for papers, we get hundreds and hundreds of submissions, and that makes it really hard to choose from."  Rethinking Web Application Firewalls  Thompson, who turned 80 on February 4 (Happy Birthday, Mr. Thompson), created Unix at Bell Labs. He worked with people like Robert Griesemer and Rob Pike on developing the Go programming language and other projects over the years, including Plan 9, UTF-8, and more. Rabinovich is pretty humble about the keynote speakers that the conference attracts. He and the conference organizers scoured the Internet and found Thompson's email, who said he'd love to join them. That's how they attracted Lawrence Lessig, the creator of the Creative Commons license, who spoke at SCALE12x in 2014 about the legal sides of open source, content sharing, and free software. "I wish I could say, we have this very deep network of connections," Rabinovich said. "It's just, these folks are surprisingly approachable, despite, you know, even after years and years of doing amazing work." SCALE is the largest community-run open-source and free software conference in North America, with roots befitting an event that started with a group of college students wanting to share their learnings about Linux. Rabinovitch was one of those college students attending UCSB, the University of California, Santa Barbara. "A lot of the history of SCALE comes from the LA area back when open source was still relatively new and Linux was still fairly hard to get up and running," Rabinovitch said. "There were LUGS (Linux User Groups) on every corner. I think we had like 25 LUGS in the LA area at one point. And so so there was a vibrant open source community.' Los Angeles's freeways and traffic made it difficult to get the open source community together. So they started LUGFest. They held the day-long event at a Nortel building until the telco went belly up. So, as open source people tend to do, they decided to scale, so to speak, the community gatherings. And so SCALE came to be – led by students like Rabinovitch. The conference started with a healthy community of 200 to 250 people. By the pandemic, 3,500 people were attending. For more about SCALE, listen to the full episode of The New Stack Makers wherever you get your podcasts.

Open Source in Enterprise Environments, Your Comprehensive Guide to rc(8): FreeBSD Services and Automation, How Rob Pike got hired by Dennis Richie, what FreeBSD machines rubenerd uses, new debugbreak command, 7 sudo myths debunked NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) and the BSDNow Patreon (https://www.patreon.com/bsdnow) Headlines Open Source in Enterprise Environments - Where Are We Now and What Is Our Way Forward? (https://bsdly.blogspot.com/2022/09/open-source-in-enterprise-environments.html) Your Comprehensive Guide to rc(8): FreeBSD Services and Automation (https://klarasystems.com/articles/rc8-freebsd-services-and-automation/) News Roundup How Rob Pike got hired by Dennis Richie (https://minnie.tuhs.org/pipermail/tuhs/2022-September/026506.html) Cartron asks what FreeBSD machines I use (https://rubenerd.com/cartron-asks-what-freebsd-machines-i-use/) My new debugbreak command (https://nullprogram.com/blog/2022/07/31/) 7 sudo myths debunked (https://opensource.com/article/22/8/debunk-sudo-myths) Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Andy - sharing and acls (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/478/feedback/Andy%20-%20sharing%20and%20acls.md) Reptilicus Rex - boot environments (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/478/feedback/Reptilicus%20Rex%20-%20boot%20environments.md) i3luefire - byhve issue (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/478/feedback/i3luefire%20-%20byhve%20issue.md) *** Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) ***

We cover reinventing your role and refocusing your eng team in the face of the unknown with Maher Saba, Head of Remote Presence and Engineering @ Meta! He discusses his leadership history from IBM to Microsoft to Meta and how he took on IC roles to gain credibility as an eng leader. We also cover how to productively channel & embrace emotions to drive improvement, frameworks for motivating eng orgs, how to incorporate personal feedback into your product, how the pandemic offered opportunities to pivot into the unknown, refocusing eng teams after challenges/periods of uncertainty, and more!ABOUT MAHER SABAMaher Saba is the Head of Remote Presence and Engineering at Meta and is responsible for creating rich social, real-time video and audio experiences that connect people while they're physically apart. Saba has held numerous Engineering leadership roles at Meta, and during his time at the company he launched Video on Newsfeed, Facebook Live, Facebook Watch, Messenger Rooms and Live Audio Rooms. Before Meta, Saba worked at IBM and Microsoft as a developer and software engineering lead, eventually becoming a Distinguished Engineer at Microsoft. Saba has a Bachelor of Science in Electrical Engineering from Purdue University and holds a Master of Science in Computer Science from The University of Texas at Austin.“He goes, ‘Have you ever written an endpoint?' I said, ‘I'm actually curious to know what an endpoint is.' And he goes, ‘Have you written anything in Ruby?' I'm like, ‘No, I've never seen the language before.' He goes, ‘How about Go Language?' I'm like, Rob Pike just came up with Go Language. Nobody knows it.' And he's like, ‘So, you know nothing.' I'm like, ‘I know nothing. I just wanna be in a place where either I sink or swim and the best way for me to know this is to jump with both feet into the deep end.'”- Maher Saba   Our in-person conference ELC Annual returns 10/27-28!Learn from 60+ of the best engineering leaders in the industry / Critical insights on leadership, career and technology / Plus tons of experiences optimized for deep conversations & meaningful connections - all to help you build your support network!Don't miss out on being part of the biggest celebration of engineering leadership of the year!Grab your ticket HERE: sfelc.com/annual2022SHOW NOTES:Maher Saba's transition from Microsoft to Meta (01:54)Why Maher restarted as an IC to gain credibility before moving back into eng management (7:08)Embrace emotions in order to gain focus & drive improvement (12:14)How Maher refocused his work at the start of the pandemic & what it's like jumping into the unknown (16:48)Frameworks for motivating eng teams to focus on execution (22:28)Maher's favorite experiences from his team's show-and-tell sessions (26:59)Incorporating feedback into your product from personal sources – like your mother! (28:29)Post-pandemic challenges & how to address them (31:27)How to refocus eng teams after periods of uncertainty (36:16)Do's and don'ts for inspiring teams to be part of a turnaround (39:35)Why Maher is excited for the unknowns surrounding the metaverse (42:00)Rapid fire questions (43:51)LINKS AND RESOURCESThe Swerve - Stephen Greenblatt's book on how the discovery of an Ancient Greek poem changed the course of human thought and shaped the world as we know it today.

Tom is losing his mind. Chunga has been bugging him to do a new Super Nerd Spotlight episode of The Hacks. Tom has been insisting that the two of them have done one of these recently.  Much to Chunga's delight, Tom is wrong! For today's episode, they've decided to focus on a group of men that Tom calls "The Origin Guys". They're a small group of dudes, who are largely credited with creating modern computing as we know it. Tom and Chunga will look all the way back to the 1960s and '70s and talk about guys like Dennis Ritchie, Rob Pike, Ken Thompson, and many more! It'll be fun to take at how far we've come from the first day until now!  Believe it or not, it's a really short period of time, and most of these guys are still alive and well!  Can they still be credited for the way we're using computers today?  Listen now to find out! Check out the brand new Idem Project! Learn more about Salt!

For more information, visit https://elevationchurch.com.au/mandurah/

In this third part of my conservation with Lakshmi, we focus on how to learn a programming language, a library, or a framework and how to take it to the next level after you learned the basics. References LISP - https://en.wikipedia.org/wiki/Lisp_(programming_language) John McCarthy - https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist) Communicating sequential processes - https://en.wikipedia.org/wiki/Communicating_sequential_processes Go Proverbs with Rob Pike - https://www.youtube.com/watch?v=PAAkCSZUG1c Go Proverbs - https://go-proverbs.github.io/ ESPN Cric Info - https://www.espncricinfo.com/ Elm Lang - https://elm-lang.org/ Elm Architecture - https://guide.elm-lang.org/architecture/ Ruby on Rails Doctrine - https://rubyonrails.org/doctrine Conceptual Compression - https://youtu.be/zKyv-IGvgGE?t=1046 My GitHub Repository - https://github.com/tamizhvendan

Array Cast - May 13, 2022 Show Notes[01] 00:01:25 https://code.jsoftware.com/wiki/System/Forums[02] 00:02:10 https://www.arraycast.com/episodes/episode26-stevan-apter[03] 00:02:28 Joel Kaplan video https://www.youtube.com/watch?v=Ni0Kj3Xjk1k&t=1s[04] 00:03:10 https://www.morganstanley.com/[05] 00:03:15 https://aplwiki.com/wiki/Arthur_Whitney[06] 00:03:25 https://www.1010data.com/[07] 00:10:20 APL-DI https://dl.acm.org/doi/10.1145/800136.804492[08] 00:12:10 https://en.wikipedia.org/wiki/Fred_Brooks[09] 00:12:36 https://en.wikipedia.org/wiki/David_E._Shaw[10] 00:15:25 https://en.wikipedia.org/wiki/Jeff_Bezos[11] 00:17:00 https://en.wikipedia.org/wiki/Digital_Equipment_Corporation[12] 00:18:15 https://en.wikipedia.org/wiki/IBM_5100[13] 00:18:55 https://en.wikipedia.org/wiki/Bill_Gates[14] 00:18:55 Gates APL Interpreter https://americanhistory.si.edu/comphist/gates.htm#tc30[15] 00:23:11 https://aplwiki.com/wiki/Bob_Bernecky[16] 00:26:15 https://mathworld.wolfram.com/NearestNeighborProblem.html[17] 00:29:26 Generalisation of the Axis operator apl.wiki/Rank (operator)[18] 00:30:50 https://en.wikipedia.org/wiki/QWERTY[19] 00:31:37 https://aplwiki.com/wiki/A[20] 00:34:00 https://aplwiki.com/wiki/K[21] 00:34:17 APL machine https://aplwiki.com/wiki/APL_Machine[22] 00:35:07 Analogic https://www.analogic.com/?locale=en[23] 00:37:07 Aaron Hsu video https://www.youtube.com/watch?v=2FMBf6A2eAA[24] 00:41:19 http://www.nsl.com/[25] 00:43:45 https://en.wikipedia.org/wiki/Muhammad_ibn_Musa_al-Khwarizmi[26] 00:43:52 https://en.wikipedia.org/wiki/Gottfried_Wilhelm_Leibniz#Symbolic_thought[27] 00:52:30 https://www.ubs.com/ca/en.html[28] 00:54:20 https://en.wikipedia.org/wiki/Pete_Muller_(businessman_and_singer-songwriter)[29] 00:56:30 https://www.dyalog.com/[30] 00:57:10 https://shakti.com/[31] 01:00:35 https://en.wikipedia.org/wiki/Steve_Jobs[32] 01:01:30 https://www.jsoftware.com/#/README[33] 01:04:09 https://aplwiki.com/wiki/Ken_Iverson[34] 01:08:30 Steven's blog post https://www.5jt.com/all-that-jazz-the-librarian-s-song[35] 01:12:18 https://en.wikipedia.org/wiki/Alan_Perlis[36] 01:13:33 https://en.wikipedia.org/wiki/Benoit_Mandelbrot[37] 01:14:15 Society of Quantitative Analysts https://www.sqa-us.org/[38] 01:14:47 https://en.wikipedia.org/wiki/Shmuel_Winograd https://encyclopediaofmath.org/wiki/Winograd_Fourier_transform_algorithm[39] 01:14:41 Yorktown Heights: https://en.wikipedia.org/wiki/Thomas_J._Watson_Research_Center[40] 01:14:52 John Cocke https://www.youtube.com/watch?v=eYwd30iWVvw https://en.wikipedia.org/wiki/John_Cocke_(computer_scientist)[41] 01:15:25 https://en.wikipedia.org/wiki/Leon_Cooper[42] 01:16:19 https://en.wikipedia.org/wiki/Philip_Wolfe_(mathematician) https://en.wikipedia.org/wiki/Quadratic_programming https://pages.cs.wisc.edu/~brecht/cs838docs/wolfe-qp.pdf[43] 01:16:41 https://en.wikipedia.org/wiki/Sharpe_ratio[44] 01:18:54 https://en.wikipedia.org/wiki/Alan_Kay[45] 01:18:58 https://en.wikipedia.org/wiki/Alexander_Stepanov[46] 01:20:09 https://en.wikipedia.org/wiki/Rob_Pike[47] 01:22:05 https://www.reddit.com/r/apljk/[48] 01:22:30 https://en.wikipedia.org/wiki/Lisp_(programming_language)[49] 01:24:43 Conor's videos https://www.youtube.com/channel/UC1kBxkk2bcG78YBX7LMl9pQ[50] 01:25:13 Rodrigo's videos https://www.youtube.com/channel/UCd_24S_cYacw6zrvws43AWg[51] 001:25:01 "Easy to Learn - Worth Mastering" https://dyalog.tv/APLSeeds22/?v=o-0xk96_BNw[52] 01:25:55 https://aplwiki.com/wiki/Outer_Product[53] 01:26:55 BQN https://mlochbaum.github.io/BQN/[54] 01:27:25 https://aplwiki.com/wiki/Inner_Product[55] 01:29:55 Ripple shuffle expression https://tryapl.org/?clear&q=%7B%E2%8D%B5%5B%E2%8D%8B%E2%8D%922%7C%E2%8D%B3%E2%89%A2%E2%8D%B5%5D%7D%27ABCDEabcde%27&run

The Go Programming Language Go is an open-source programming language with influences from Limbo, C, APL, Modular, Oberon, Pascal, Alex, Erlang, and most importantly, C. While relatively young compared to many languages, there are over 365,000 repositories of Go projects on Github alone. There are a few reason it gained popularity so quickly: it's fast and efficient in the right hands, simple to pick up, doesn't have some of the baggage of some more mature languages, and the name Ken Thompson. The seamless way we can make calls from Go into C and the fact that Ken Thompson was one of the parties responsible for C, makes it seem in part like a modern web enabled language that can stretch between the tasks C is still used for all the way to playing fart sounds in an app. And it didn't hurt that co-author Rob Pike had whelped write books, co-created UTF-8, and was part of the distributed operating system Plan 9  team at Bell Labs and had worked on the Limbo programming language there.  And Robert Griesemer was another co-author. He'd begun his career studying under Niklaus Wirth, the greater of Pascal, Modula, and Oberon. So it's no surprise that he'd go on to write compilers and design languages. Before go, he'd worked on the V8 JavaScript engine at Google and a compiler for the Java HotSpot Virtual Machine. So our intrepid heroes assembled (pun intended) at Google in 2009. But why? Friends don't let friends write in C. Thompson had done something amazing for the world with C. But that was going on 50 years ago. And others had picked up the mantle with C++. But there were shortcomings the team wanted to address. And so Go has the ability to concatenate string variables without using a preprocessor, has many similarities to languages like BASIC from the Limbo influences, but the most impressive feature about this programming language is its support for concurrent execution. And probably the best garbage collection facility I've ever seen.  The first version of the language wasn't released to the public and wouldn't be for a few years. The initial compiler was written in C but over time they got to where it can be self-hosted, which is to say that Go is compiled in Go.  Go is a compiled language that can run on a command line, in a browser, on the server, or even be used to compile itself. Go compiles fast and has no global variables to clutter memory. This simplicity makes it easy to read through Go code line by line without consulting any parsing tools or syntax charts. Let's look at a quick Hello World: // A basic Go program that demonstrates "Hello World!"
package main
import "fmt"
func main() {
    fmt.Println("Hello World!")
} The output would be a simple Hello World! Fairly straight forward but the power gets into more of the scripting structures - especially given that a micro service is just a lot of little functional scripts. The language itself has no connection to any other functional programming languages and does not include support for object orientation or reflection. The language consists of two parts: a parser (which processes an input file) and a bytecode interpreter, which translates all source code into machine code. Consequently, Go programs tend to compile quickly and run very efficiently because they are mainly independent of the runtime environment and can execute directly on the hardware without being interpreted by some sort of virtual machine first. Additionally, there is no need for a separate interpreter during execution since everything runs natively. The libraries and sources built using the Go programming language provide developers with a straightforward, safe, and extensibility system to build on. We have things like Go Kit, GORM, cli, Vegeta, fuzzy, Authboss, Image, Time, gg, and mgo. These can basically provide pre-built functions and APIs to hook into any old type of service or give a number of things for free. Go was well designed from the outset and while it's evolved over the years, it hasn't changed as much as many other languages. with the latest release being Go 1.17. 1.1 came just a couple of months after the initial release to increase how much memory could be used on 64 bit chips by about 10-fold, add detection for race conditions, added the uint for 64 bit integers. Oh and fixed a couple of issues in the compiler. 1.2 also came in 2013 and tweaked how slicing of arrays worked in a really elegant way (almost ruby-like) and allowed developers to call the runtime scheduler for non-inline calls. And added a thread limit, like the ulimit a bash would have, for 10,000 threads. And they doubled the grouting minimum size of the stack.  Then the changes got smaller. This happens as every language gets more popular. The more people use it, the more havoc the developers cause when they make breaking changes. Bigger changes are contiguous models of grouting stacks in 1.3, the addition of internal packages in 1.4, a redesigned garbage collector in 1.5 when Go was moved away from C and implemented solely in Go and assembler. And 17 releases later, it's more popular than ever. While C remains the most popular language today, Go is hovering in the top 10. Imagine, one day saying let's build a better language for concurrent programming. And then viola; hundreds of thousands of people are using it. 

技術顧問の和田卓人さんと、内部DSL、2010年代のプログラミング言語について話しました。 Show Notes: Put chubby models on a diet with concerns メタプログラミングRuby 第2版 InternalDslStyle 普通のやつらの上を行け（「ハッカーと画家」に収録されているエッセイの1つ） Annotation（Java） Decorators（Python） Cross-cutting concern Aspect-oriented programming Robert Griesemer, Rob Pike, Ken Thompson（Go言語の作者たち） Law of Demeter Structural type system Nominal type system Bundle Side Optimization in Future JavaScript - JSConf JP 2021 Rome Toolchain

Oxide and Friends Twitter Space: October 18th, 2021Dijkstra's TweetstormWe've been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it's not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for October 18th, 2021.In addition to Bryan Cantrill and Adam Leventhal, speakers on October 18th included Edwin Peer, Dan Cross, Ryan Zezeski, Tom Lyon, Aaron Goldman, Simeon Miteff, MattSci, Nate, raycar5, night, and Drew Vogel. (Did we miss your name and/or get it wrong? Drop a PR!)Some of the topics we hit on, in the order that we hit them:Dijkstra's 1975 “How do we tell truths that might hurt?” EWD 498 tweet > PL/1 > belongs more to the problem set than to the solution setThe use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offenceAPL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums - [@3:08](https://youtu.be/D-Uzo7M-ioQ?t=188) Languages affect the way you think It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. - [@4:33](https://youtu.be/D-Uzo7M-ioQ?t=273) Adam's Perl story - The Camel Book, not to be confused with OCaml - “You needed books to learn how to do things” - CGI - [@9:04](https://youtu.be/D-Uzo7M-ioQ?t=544) Adam meets Larry Wall - [@11:59](https://youtu.be/D-Uzo7M-ioQ?t=719) Meeting Dennis Ritchie - “We were very excited; too excited some would say…” - [@15:04](https://youtu.be/D-Uzo7M-ioQ?t=904) Effects of learning languages, goals of a language, impediments to learning - Roger Hui of APL and J fame, RIP. - Accessible as a language value - Microsoft Pascal, Turbo Pascal - Scratch - LabVIEW - [@25:31](https://youtu.be/D-Uzo7M-ioQ?t=1531) Nate's experience - Languages have different audiences - [@27:18](https://youtu.be/D-Uzo7M-ioQ?t=1638) Human languages - The Esperanto con-lang - Tonal langages - Learning new and different programming languages - [@37:06](https://youtu.be/D-Uzo7M-ioQ?t=2226) Adam's early JavaScript (tweet) - circa 1996 - [@44:10](https://youtu.be/D-Uzo7M-ioQ?t=2650) Learning from books, sitting down and learning by typing out examples - How do you learn to program in a language? - Zed Shaw on learning programming through spaced repetition blog - Rigid advice on how to learn - ALGOL 68, planned successor to ALGOL 60 - ALGOL 60, was, according to Tony Hoare, “An improvment on nearly all of its successors” - [@50:41](https://youtu.be/D-Uzo7M-ioQ?t=3041) Where does Rust belong in the progression of languages someone learns? Rust is what happens when you've got 25 years of experience with C++, and you remove most of the rough edges and make it safer? - “Everyone needs to learn enough C, to appreciate what it is and what it isn't” - [@52:45](https://youtu.be/D-Uzo7M-ioQ?t=3165) “I wish I had learned Rust instead of C++” - [@53:35](https://youtu.be/D-Uzo7M-ioQ?t=3215) Adam: Brown revisits intro curriculum, teaching Scheme, ML, then Java - Adam learning Rust back in 2015 (tweet) “First Rust Program Pain (So you can avoid it…)” Tom: There's a tension in learning between the people who hate magic and want to know how everything works in great detail, versus the people who just want to see something useful done. It's hard to satisfy both. - [@1:00:02](https://youtu.be/D-Uzo7M-ioQ?t=3602) Bryan coming to Rust - “Learn Rust with entirely too many linked lists” guide - Rob Pike interview Its concurrency is rooted in CSP, but evolved through a series of languages done at Bell Labs in the 1980s and 1990s, such as Newsqueak, Alef, and Limbo. - [@1:03:01](https://youtu.be/D-Uzo7M-ioQ?t=3781) Debugging Erlang processes. Ryan on runtime v. language - Tuning runtimes. Go and Rust - [@1:06:42](https://youtu.be/D-Uzo7M-ioQ?t=4002) Rust is its own build system - Bryan's 2018 “Falling in love with Rust” post - Lisp macros, Clean, Logo, Scratch - [@1:11:27](https://youtu.be/D-Uzo7M-ioQ?t=4287) The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. - [@1:12:09](https://youtu.be/D-Uzo7M-ioQ?t=4329) Oxide bringup updates - I2C Inter-Integrated Circuit - SPI Serial Peripheral Interface - iCE40If we got something wrong or missed something, please file a PR! Our next Twitter space will likely be on Monday at 5p Pacific Time; stay tuned to our Twitter feeds for details. We'd love to have you join us, as we always love to hear from new speakers!

Oxide and Friends Twitter Space: September 6th, 2021Put the OS back in OSDIWe've been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it's not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for September 6th, 2021.In addition to Bryan Cantrill and Adam Leventhal, speakers on September 6th included Dan Cross, Josh Clulow, Tom Lyon, Simeon Miteff, Daniel Maslowski, Matt Campbell and Moritz. (Did we miss your name and/or get it wrong? Drop a PR!)Some of the topics we hit on, in the order that we hit them: Adam's tweets on recording Twitter Spaces. Tweet on recovering a recording! [@4:57](https://youtu.be/PVJfqjJJCkg?t=297) Timothy Roscoe's Keynote  Screenshots teasing his slides Conf video Complicated relationship with academia and industry  [@8:09](https://youtu.be/PVJfqjJJCkg?t=489) Adam's MS graphics experience Bryan's USENIX 2016 keynote ~1hr: A Wardrobe for the Emperor – Stitching Practical Bias into Systems Software Research Conferences as the publishing vector for CS research [@13:47](https://youtu.be/PVJfqjJJCkg?t=827) What a modern OS does > … accreted and not designed. > They were not designed, they congealed. [@17:10](https://youtu.be/PVJfqjJJCkg?t=1030) Rob Pike's 2000 “Systems Software Research is Irrelevant” paperThe value of incremental improvements [@21:47](https://youtu.be/PVJfqjJJCkg?t=1307) Building on extant working components and interfaces  Opaque, proprietary hardware AMD Platform Security Processor > Artifacts of the OS implementation tend to have outsized impact > on overall system performance [@26:27](https://youtu.be/PVJfqjJJCkg?t=1587) Performance is not the only axis of a system Security, malleability, convenience, reliability [@31:12](https://youtu.be/PVJfqjJJCkg?t=1872) Specialization  HarmonyOS, Fuchsia Different chips performing different tasks Firmware everywhere Intel Optane Intel 8051 [@37:02](https://youtu.be/PVJfqjJJCkg?t=2222) Open hardware and firmware ARM Cortex-M0 > That's why we land at incrementalism, we ossify at some boundary. > And it's very hard to change things on either side without moving in lockstep. Tom: The PC architecture was a great thing, but now the OS vendors have abdicated any knowledge of the hardware. Give us UEFI and we don't care what happens beneath that.Should ARM have UEFI? (or something like it) [@45:29](https://youtu.be/PVJfqjJJCkg?t=2729) Developing hardware is still challenging, but has never been easier than today (especially low-speed)  Tom's tweet about parallels with homebrew computing in the 70's Precursor and Xous [@50:58](https://youtu.be/PVJfqjJJCkg?t=3058) Where will new systems development fit in with our existing (working) systems?  Low-speed is an opportunity area RISC-V for peripherals [@56:37](https://youtu.be/PVJfqjJJCkg?t=3397) Backwards compatibility seems to be more important than marginal gains:  Shingled magnetic recording offered

第 6 期：Go 语言的编译器 主持：杨文，欧长坤 嘉宾：史斌 本期摘要：这是 Go 夜聊的第六期节目，这期我们有幸请到了目前在 Go 语言仓库贡献排行榜上前全球前五十的贡献者——史斌，并和他一起聊了聊编译器相关的技术和相关行业的一些未来。Go 语言的编译器有什么特点？还有哪些可以改进的空间？从事芯片和编译技术相关的工作又有哪些挑战？ 时间线 00:00 开场 01:00 接触 Go 语言的起因 03:31 Go 语言在芯片行业的现状 04:57 成为中国 Go 语言贡献者排名第一的经历 12:30 加入 Go 团队的 GitHub 组织 19:11 Go 语言中国贡献者俱乐部的成立过程 21:57 Go 语言在芯片行业的困境 26:26 基于 SSA 的 Go 编译器 32:02 现阶段编译器的改进空间 35:10 基于寄存器的调用规约 38:24 gccgo 和 gollvm 42:19 编译技术和行业的未来 47:30 推荐 50:05 尾声 相关链接 乘法指令生成错误 寄存器索引 LOAD/STORE Go 1 Benchmark Go 团队在 GitHub 的组织 前 Go 团队成员 Brad Fitzpartrick Go 团队成员 Cherry Zhang Go 语言贡献者李保坤 Go 语言贡献者蒙卓 Go 语言中国贡献者俱乐部 史斌在 GopherChina 2020 上关于 Go 编译器的演讲 Erlang CSP 顺序进程通信 Rob Pike Ken Thompson SSA 静态单赋值形式 IR 中间语言 Intrinsic 内建函数 阵列编程与向量化 循环优化 Go 语言增加循环优化的讨论 Issue 24240 指令流水 GCC LLVM 调用规约 gccgo gollvm TinyGo Proebsting 定律 Moore 定律 书籍:《史记》 书籍:《战国策》 书籍:《不拘一格》 播客: 从零道一 书籍:《Ray Tracing Gems II》

It's time to say goodbye to the GPL, a new OCI Runtime for FreeBSD Jails, A bit of Xenix history, On Updating QEMU's bsd-user fork, FreeBSD 13 on a 12 year old laptop, and more. NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) Headlines It's time to say goodbye to the GPL (https://martin.kleppmann.com/2021/04/14/goodbye-gpl.html) The trigger for this post is the reinstating of Richard Stallman, a very problematic character, to the board of the Free Software Foundation (FSF). I am appalled by this move, and join others in the call for his removal. This occasion has caused me to reevaluate the position of the FSF in computing. It is the steward of the GNU project (a part of Linux distributions, loosely speaking), and of a family of software licenses centred around the GNU General Public License (GPL). These efforts are unfortunately tainted by Stallman’s behaviour. However, this is not what I actually want to talk about today. runj: a new OCI Runtime for FreeBSD Jails (https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-for-freebsd-jails/) Today, I open-sourced runj, a new experimental, proof-of-concept OCI-compatible runtime for FreeBSD jails. For the past 6.5 years I’ve been working on Linux containers, but never really had much experience with FreeBSD jails. runj (pronounced “run jay”) is a vehicle for me to learn more about FreeBSD in general and jails in particular. With my position on the Technical Oversight Board of the Open Containers Initiative, I’m also interested in understanding how the OCI runtime specification can be adapted to other operating systems like FreeBSD. News Roundup A Bit of Xenix History (http://seefigure1.com/2014/04/15/xenixtime.html) From 1986 to 1989, I worked in the Xenix1 group at Microsoft. It was my first job out of school, and I was the most junior person on the team. I was hopelessly naive, inexperienced, generally clueless, and borderline incompetent, but my coworkers were kind, supportive and enormously forgiving – just a lovely bunch of folks. On Updating QEMU's bsd-user fork (https://bsdimp.blogspot.com/2021/05/on-updating-qemus-bsd-user-fork.html) FreeBSD 13 on a 12 year old laptop (http://box.matto.nl/freebsd-13-on-a-12-year-old-laptop.html) My old (2009) HP laptop now runs FreeBSD 13.0-RELEASE. Beastie Bits Registration is now open for the June 2021 #FreeBSD Developers Summit (https://twitter.com/i/web/status/1387797859479732227) 6.0RC1 images available (https://www.dragonflydigest.com/2021/04/22/25663.html) Lexical File Names in Plan 9 or Getting Dot-Dot Right (https://plan9.io/sys/doc/lexnames.pdf) The history of UTF-8 as told by Rob Pike (http://doc.cat-v.org/bell_labs/utf-8_history) Initial Support for the riscv64 Architecture (http://undeadly.org/cgi?action=article;sid=20210423090342) *** ###Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Hamza - Congrats on 400 (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/402/feedback/Hamza%20-%20Congrats%20on%20400) Renato - DTS and ContainerD (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/402/feedback/Renato%20-%20DTS%20and%20ContainerD) Rob - Music (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/402/feedback/Rob%20-%20Music) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) ***

第 1 期：参加 GopherCon 2020 杨文, 欧长坤 本期摘要：这是 Go 夜聊的第一期节目，我们选择了一个跟全球 Golang 语言开发者都有关系的话题，就是刚刚结束的 GopherCon。在疫情的影响下，原本计划在 6 月份举办的大会如今推迟到了 11 月，由原本的线下也更改为了线上。那么参加这种大会有什么特别之处？参加这个大会会有哪些潜在的收益？从大会里又有那些有关 Golang 语言的相关“小道”消息？ 时间线 00:45 GopherCon 的介绍和起源 04:08 参会的费用、形式及日程安排 08:40 在全球范围内进行线上大会的交流工具 10:54 大会的赞助商和他们的潜在动机 17:42 参加 GopherCon 大会的原因 19:33 除了 GopherCon 之外的其他参会经历 23:31 各式各样的 GopherCon 和 Meetup 29:00 Go 语言编译器和运行时的领头人 Austin Clements 36:05 运行时异步抢占的设计由来 39:21 有关添加泛型支持的各类小道消息 42:10 值回票价的 QA 环节和 Go 运行时未来的发展方向 54:05 其他的一些参会环节 58:54 推荐环节

Carmen and Jon talk with Rob Pike and Robert Griesemer (the creators of Go) about its origins, growth, influence, and future. This an epic episode that dives deep into the history and details of the how’s and why’s of Go, and the choices they’ve made along the way in creating this awesome programing language.

Carmen and Jon talk with Rob Pike and Robert Griesemer (the creators of Go) about its origins, growth, influence, and future. This an epic episode that dives deep into the history and details of the how’s and why’s of Go, and the choices they’ve made along the way in creating this awesome programing language.

Carmen and Jon talk with Rob Pike and Robert Griesemer (the creators of Go) about its origins, growth, influence, and future. This an epic episode that dives deep into the history and details of the how’s and why’s of Go, and the choices they’ve made along the way in creating this awesome programing language.

Languages used for IT infrastructure don’t have expiration dates. COBOL’s been around for 60 years—and isn’t going anywhere anytime soon. We maintain billions of lines of classic code for mainframes. But we’re also building new infrastructures for the cloud in languages like Go. COBOL was a giant leap for computers to make industries more efficient. Chris Short describes how learning COBOL was seen as a safe long-term bet. Sixty years later, there are billions of lines of COBOL code that can’t easily be replaced—and few specialists who know the language. Ritika Trikha explains that something must change: Either more people must learn COBOL, or the industries that rely on it have to update their codebase. Both choices are difficult. But the future isn’t being written in COBOL. Today’s IT infrastructure is built in the cloud—and a lot of it is written in Go. Carmen Hernández Andoh shares how Go’s designers wanted a language more suited for the cloud. And Kelsey Hightower points out that languages are typically hyper-focused for one task. But they’re increasingly open and flexible. You can learn more about COBOL or Go, or any of the languages we’re covering this season, by heading over to redhat.com/CommandLineHeroes. We're passing along a correction that Carmen Hernández Andoh shared on Twitter: she misspoke about Rob Pike inventing ASCII. Bob Bremer is considered the main creator of ASCII. Follow along with the episode transcript

Martin Thompson on Arrested DevOps, Dr. Carola Lilienthal on Legacy Code Rocks, Jeff Gothelf on Agile Atelier, Safi Bahcall on Coaching For Leaders, and Mike Burrows on A Geek Leader.  I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting August 19, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. MARTIN THOMPSON ON ARRESTED DEVOPS The Arrested DevOps podcast featured Martin Thompson with host Jessica Kerr. Martin and Jessica talked about the parallels between optimizing the performance of software systems and doing the same for human systems. Using ideas from queuing theory, they discussed the notion of adding small amounts of slack to a system to make it drastically more responsive. Martin connected Amdahl’s Law to the more general Universal Scalability Law, which is more comprehensive because it takes into account coherence cost, which is the time needed to reach agreement between parties working together. He added that Brook’s Law from The Mythical Man Month is the Universal Scalability Law by a different name. They talked about the difference between parallelism and concurrency. Parallelism, Martin says, is doing multiple things at the same time. Concurrency means dealing with multiple things at the same time, a definition Martin says he stole from Rob Pike. He further decomposed the universal scalability law into its parameters. One parameter represents whether you can subdivide the work (the contention penalty) and the other represents the time to reach agreement (the coherence penalty). If your team can reach agreement faster, they can get better throughput because they can have more parallelism with less concurrency. They got into a discussion of the importance of feedback in information theory. Sending information and not confirming reception is a naïve approach and this has been understood for a long time and yet software is still built that ignores this. Two phase commit is an example. If you study the two phase commit protocol in any detail, Martin says, you realize it is fundamentally broken, yet corporations don’t want to say that. They talked about how to design distributed applications in the presence of partial failures. Martin says to make your communications idempotent, give each message a sequence number, and use this sequence number to identify and ignore replayed messages. According to Martin, designing your systems this way is just good hygiene and professionalism. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/protocols-and-sympathy-with-martin-thompson/id773888088?i=1000444947737 Website link: https://www.arresteddevops.com/protocols/ DR. CAROLA LILIENTHAL ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featuring Dr. Carola Lilienthal with hosts Andrea Goulet and Scott Ford. They talked about Domain-Driven Design. Carola said her company read Eric Evans’ book and immediately took to it. Talking to users, writing software in the user's domain, and using a common vocabulary fit with what they were already doing so they adopted it easily. They talked about Carola’s modularity maturity index. It consists of three areas of sustainability: 1) modularity, 2) hierarchy, and 3) pattern consistency.  Andrea brought up the fact that larger codebases aren’t necessarily more difficult to change as Carola found in her research. Carola says that, based on the three hundred systems she’s studied, systems under a million lines of code are often in a worse state than larger systems. Around a million lines of code, she says, something happens: either people start structuring the system and putting in guard rails that keep the product maintainable or the system doesn’t grow any more. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sustainable-software-architecture-dr-carola-lilienthal/id1146634772?i=1000443349633 Website link: http://legacycoderocks.libsyn.com/sustainable-software-architecture-with-dr-carola-lilienthal JEFF GOTHELF ON AGILE ATELIER The Agile Atelier podcast featured Jeff Gothelf with host Rahul Bhattacharya. Rahul and Jeff talked about the intersection of Agile, Lean, and Design Thinking to find commonalities. They examined customer-centricity, measuring success, continuous testing, and the importance of having a hypothesis. Jeff had been working as a designer on waterfall projects for the first decade of his career and, on a good day, only saw 50% of his work get implemented. Ten years into his career, Jeff got exposed to Agile software development and it forced him to revisit his design process and his process for doing product development as a whole. Because Jeff was in a leadership position and had a boss that understood the new methodology, Jeff got the chance to run process experiments to learn what the best collaboration model was for him and his team. This became the basis of his book, Lean UX. Rahul asked Jeff how he would define Design Thinking. Jeff described Design Thinking as applying the designer’s toolkit to solve business problems. This includes empathizing with customers, brainstorming ideas, prototyping, testing ideas with customers, and iterating.  Rahul asked if there is a specific situation in which to apply Design Thinking. Jeff says that he has yet to find a client or an industry where customer-centricity, continuous learning, risk mitigation, experimentation, and iteration don’t make sense. Even when working with people at GE who make locomotives and working with organizations that make room-sized air conditioning units that sit on top of skyscrapers, Jeff was able to successfully introduce them to ideas like talking to customers, identifying risks, and continuously improving their product. Rahul asked how the principles of Design Thinking fit with the Agile principles. Jeff says that everybody thinks that Agile is its own thing, Design Thinking is its own thing, Lean Manufacturing and Lean Startup are their own thing. The tactical execution of those methodologies might be different, but at their core, Jeff says these methods all share the same principles.  They are all customer-centric. They all measure success as an outcome, as a change in customer behavior. They all focus on testing your ideas quickly and moving off of bad ideas quickly. And they all focus on continuously improving and iterating the thing you are making as you continue to invest in it. They then got into a discussion about the importance of measuring the impact on the user of the product you are building. Jeff says that, unfortunately, shipping the thing is still one of the major definitions of success for most organizations. But in a world of continuous software when you can push a software update five times a minute like Amazon does, delivering the thing is a non-event and it should be a non-event. We shouldn’t celebrate it. What we should celebrate is the change in customer behavior that tells us that we’ve delivered value. These are things like showing up at the website, engaging with the app, buying the product, telling your friends, whatever it is we care about for our product. This line of thought led to the quote above. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-11-intersection-agile-lean-design-thinking/id1459098259?i=1000445718430 Website link: https://rahul-bhattacharya.com/2019/07/30/episode-11-the-intersection-of-agile-lean-and-design-thinking-with-jeff-gothelf/ SAFI BAHCALL ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Safi Bahcall (author of the book Loonshots) with host Dave Stachowiak. They talked about what science has to say about the best ways to nurture new ideas. They started out with a discussion of children’s books and Safi’s first example of a loonshot was Dr. Seuss. He had just been rejected by every publisher he took his first story to when he ran into a friend in the street. This friend asked Dr. Seuss about what he had under his arm and when he found out it was a manuscript for a children’s story that Dr. Seuss was taking home to burn, the friend revealed that he had just taken a job at a publisher across the street and asked Dr. Seuss if he would like to come into the publisher’s office. The Cat In The Hat was born. Safi used the story of the moon landing as an illustration of the difference between a moonshot and a loonshot. A moonshot was Kennedy’s speech announcing that the United States would put a man on the moon by the end of the decade. A loonshot was forty years earlier when Robert Goddard suggested getting to the moon with liquid-fueled jet propulsion and was ridiculed by many, including the New York Times. The reason it is important to understand the difference is because Goddard’s ideas, though neglected by the Americans, were embraced by Nazi Germany. German scientists used Goddard’s ideas to build jet engines and planes that flew 100 mph faster than any Allied plane. The mistake of neglecting Goddard’s ideas was fatal. Companies often ask Safi how they can innovate and create new products while continuing to keep their original product or service competitive. He thinks about these situations using three metaphors: the ice cube, garden hoe, and heart. He starts by thinking about the artists who create new product ideas and soldiers to execute on turning those ideas into real products in the marketplace. The ice cube is a rigid phase that suits the soldiers and a melted ice cube is a fluid phase that suits the artists. Understanding the problem starts with the ‘beautiful baby’ problem. The artist sees their new idea as a beautiful baby. The soldiers look at the same thing and see a shriveled up raisin. They’re both right. The garden hoe comes from understanding that the failure point in most innovation is rarely in the supply of new ideas, it is in the transfer between artists and soldiers. Great leaders are those who think of themselves as gardeners managing the transfer between the artists and soldiers. The heart is about loving your artists and soldiers equally. When we lionize the artists as the media often do, we demotivate the soldiers. I liked what Safi had to say about the problem with following the standard advice about active listening. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/418-the-way-to-nurture-new-ideas-with-safi-bahcall/id458827716?i=1000443895174 Website link: https://coachingforleaders.com/podcast/nurture-new-ideas-safi-bahcall/ MIKE BURROWS ON A GEEK LEADER The A Geek Leader podcast featured Mike Burrows with host John Rouda. Mike talked about his career leading up to the writing of AgendaShift. He described the goal of AgendaShift as trying to introduce agility not by prescribing a set of practices or rolling out a framework but by getting agreement on outcomes and working out different ways of achieving them in an hypothesis-driven way. He then mentioned his newer book that he was working on at the time the podcast aired and has just come out this month, Right to Left. Right to Left is about working backwards from outcomes. John asked what the shift was that led to this outcome-focused approach. Mike said that while working in the government digital space in the UK, he witnessed rapid change. Instead of one supplier creating documentation for a new system, a second supplier building it, and a third supplier supporting it, and the whole thing being an expensive mess that disappoints its end users, he says they now have a system where projects will be halted if they are not serious about engaging with users, doing user research, understanding needs, and working iteratively to deliver evolving services. He says that if it can happen in the government space, it can happen anywhere. John asked about what a new manager coming from an individual contributor role would need to learn for dealing with the people side of managing projects. Mike recommended tempering any temptation to micro-manage. On his first day taking over a management position at UBS, he had people lining up at his desk looking to be micro-managed because that is how his predecessor worked. He told them that if this is how it is going to work, it is going to make him miserable and it is going to make them miserable and he encouraged them to self-organize. Mike’s second recommendation is to learn to value and respect people who come from other disciplines than technology, as he says in the above quote. John asked Mike to describe AgendaShift. Mike says that the best two words that describe it come from Daniel Mezick: it is an engagement model. Much like Daniel’s OpenSpace Agility, AgendaShift describes how change agents can engage with their organizations. In the Lean/Agile space, pushing Agile on people is self-defeating and creates more problems than it solves. Instead, facilitate outcomes that the people of the organization can agree on and start solving problems. AgendaShift starts with discovery. There are workshop tools to creating a high-level plan. Then they use an assessment tool for identifying opportunities to increase transparency, get workloads under control, or to engage better with customers. They identify obstacles and the outcomes hiding behind those obstacles. They use a “clean language”-based game to model a landscape of obstacles and outcomes and get people to think about the journey, their priorities, and what the key landmarks along the way will be. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/agl-081-agendashift-with-mike-burrows/id1043194456?i=1000424584602 Website link:https://www.ageekleader.com/agl-081-agendashift-with-mike-burrows/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Imre Nagi saat ini bekerja di Traveloka sebagai Data Engineer dan sudah bekerja di Traveloka sejak Januari 2018. Sebelum meniti karir di Traveloka, Imre sempat mengecap serunya bekerja di Silicon Valley saat menjadi intern di eBay sebagai Software Engineer dan pernah juga menjadi intern di 2013 di CERN, Switzerland selama 3 bulan. Dibalik kisah yang sangat menarik, terutama bagaimana Imre akhirnya bisa masuk ke salah satu universitas keren, Carnegie Mellon dan juga mendapatkan kesempatan intern di eBay adalah proses yang “berdarah-darah”. Ia sempat mengalami penolakan dari lima universitas dan penolakan lebih dari 15 perusahaan untuk pekerjaan intern. Namun berbekal kegigihan, bahkan Imre sempat mendapat tawaran intern dari Tesla sebelum memutuskan untuk bergabung dengan eBay. Sosok yang mengidolai Rob Pike pembuat bahasa pemrograman Go juga sempat dimentori oleh Didiet Noor saat bekerja di Ice House sebagai mobile engineer dan juga Doni Hanafi saat bekerja di Bride Story . Tips belajar menjadi data engineer: * Belajar fundamental seperti MapReduce * Pelajari tentang Hadoop Info lebih lanjut, silakan kunjungi ceritanyadeveloper.com/imre-nagi

In this episode Aaron Patterson joins our own developer advocate Jonan Scheffler to discuss his experiences as an open source developer within GitHub, and explains how he manages to balance his work as a member of the Ruby and Rails core teams with his other responsibilities. Aaron is the only member of both the Ruby and Rails core teams, and he's been working with Rails since 2005 when his friends attended the No Fluff Just Stuff (NFJS) Pacific Northwest Software Symposium and heard Dave Thomas speak.(1) In discussing his path to becoming a Ruby developer, Aaron walks through his time working with Perl and Java, covering language regular expression engines (PCRE, Oniguruma, POSIX), the joy he felt in finding Ruby, and how falling in love with Ruby eventually forced him to become a C programmer. Later in the episode Aaron offers some advice to aspiring open source developers and discusses the future of Ruby, along with some features he would like to see around deep freezing data structures(2) and concurrency/parallelism(3). If you’d like to learn more about Ruby development and how you can contribute, please visit https://bugs.ruby-lang.org. Links from this episode Dave Thomas "Ruby on Rails" talk abstract from NFJS PNW Software Symposium Vaidehi Joshi explains frozen hashes in Ruby Rob Pike explains concurrency and parallelism at Waza 2012:

Panel: Lucas Reis Justin Bennett Special Guests: Alexey Ivanov and Andy Barnov In this episode, the panelists talk with Alexey Ivanov and Andy Barnov. They all discuss Alexey’s article titled: “Optimizing React Virtual DOM.” Listen to today’s episode to hear all the details about this article, the guests’ backgrounds and much, much more! Show Topics: 0:32 – Panel: Thanks for joining us and talking about this article. 0:52 – Guest: Thanks for having us on your podcast! The guest talks about his community of developers and the offices are in San Francisco, Russia and other places. He talks about how the company helps their customers and how they can scale. Some of their companies are Groupon and Ebay. 2:39 – Alexey. 3:09 – Panel: The article is here. What is JSX how does it boil down to? It’s all supposed to help people and help them understand. 3:45 – Alexey: It’s about how to structure your state, etc. 4:15 – Panel: This keeps things small. He said when I have one idea I write a song and when I have 2 ideas I write 2 songs. If you try to put too many ideas into one post it maybe won’t go too far. 4:48 – Alexey. 5:50 – Panel. 5:56 – Panel: That’s a topic for another episode. The article is interesting in that the large percentage don’t think about rendering performance, so it’s a needed piece of content. Let’s talk about – what is the React Virtual DOM? 6:32 – Alexey goes into detail with his answer to the panelist’s question. 8:50 – Panel: What I like about this article is that you go through a good progression: here is the JSX that you would write and here is the trans piled function is. And you show the virtual DOM pre-presentation is. I think that is a helpful thing. Let’s talk about that. How does React change to those things when it’s rendering? 9:50 – Alexey. 12:58 – Panel: Okay to recap...when you are rendering an element you write some JSX and the first thing (component) that will map over to the type property is for the Virtual DOM object? And then all of that is compared – when does that happen, the comparison? 13:28 – Alexey: You have React and you create... 15:20 – Panel: So it’s both React and set state these are the only 2 things that triggered state or is there anything else out there? 15:31 – Alexey. 15:47 – Panel: Interesting. You talked about the imperative way we did it before – and it’s much simpler to say what you want, but a question is that is there any world case where it does not work well? What are the trade-offs? Have you ever encountered one? 16:34 – Alexey: If you have changes in the browse, implementations...it’s simplest and easiest way. You just need to have some little changes... 17:53 – Panel: If it’s basic then you don’t have to do manual updates. 18:03 – Alexey. Alexey: To make it work you need competence in your bundle. 18:36 – Panel: I’ve heard – haven’t worked with – when we have these projects that are really web time based, hundreds of elements in real time on a screen, on a Virtual DOM it’s too slow. You have to be precise. They had performance issues, I’m sure 98.99% of the applications probably perform better with the Virtual DOM.  19:46 – Alexey. 21:38 – Panel: That is to reduce the amount of state changes so you are reducing the amount of time it renders – right? 21:50 – Alexey. 22:03 – FRESH BOOKS! 23:11 – Panel: We talked about how type is the first thing that is checked. It does equal comparison to compare these types. What was really interesting is that class components are the same thing but not so. Is it always going to re-render for those components? 24:24 – Alexey: We have to talk about 2 things about this first. In my article... 27:49 – Panel: That is a beneficial tool too to control your rendering. You talked about tools to show updates and we will include the link to the article in the links, also I would read it and check out that particular function. It’s cool to see HOW it’s actually rendering. 28:29 – Panel: Apparently sometimes things help us in principle cause we need performance. We need to open the tools and understand what is happening? Is it really a bottleneck like I think it is? One of those Twitter things I saw a few months ago... 30:52 – Alexey: Yes, do what makes sense to you at the time. 32:08 – Panel: We talked about render performance and the pure component and not creating functions...you have a big quote in your article... I have a big question for me: You have a component, and there is a child / parent component. I am curious about that pattern – will it re-render every time? Tell us your thoughts, please. 33:16 – Alexey. 34:11 – Panel: My only issue with the render props is not a performance issue it’s more of an architectural issue. Sometimes we want things to be interjected. I want to have access to this or that. Sometimes we want to access those on a life cycle. The higher the component makes it easier to add a... That’s my only complaint about render comps. 35:35 – Alexey. 36:00 – Panel: Like composing consumers? 36:06 – Alexey: What we are talking about is... 37:00 – Panel: I agree. There are some interesting cases with that pattern when you have a lot of those chained together – function, function, etc. – there are some components that will help you compose... 37:34 – Panel: It’s like callback hell all over again. Everything is a tradeoff somewhere. After the tree it looks clean with render props. I like it even with the drawbacks. 38:25 – Panel: You spent some time talking about lists of children and how you (if one of the children are removed) then it ends up re rendering all the children cause it’s comparing their positions. You mentioned key is one way to deal with that. Let’s talk about keys. When people use keys they are using an array of an index. It seems like it defeats the purpose of it – is that right? 39:20 – Alexey: Yes, you are right.  40:19 – Panel: I think that continually and it’s a smaller known thing but people want this key error to go away and they just shove something in there. To some extent it’s good to know if your tool requires something it’s good to know WHY it requires that. 40:52 – Panel: Last question. Is that the person to program and be a web developer and they are learning React. This is the tool and they are learning how to use React for an app then when we are throwing articles at them. If they are learning React and these articles are at them I think it’s a cognitive overload. What are your thoughts / advice? 42:07 – Guest: How beginner should you be before you learn React? Ideally you should be aware of JavaScript, right? Sometimes people do this to catch up to something shiny. This is just my 2 cents.  43:03 – Alexey. 44:49 – Panel: When you are going to hire someone to do something or choose a framework always try to do a little bit of work without it. Try to build an application w/o React, and then React is introduced to you, you will only see the benefits that they are brining. One thing that happens inside the React world is that people don’t write an application... Start with the basic building blocks – that makes sense to me. 46:05 – Panel: Let’s go to picks! 46:13 – Advertisement – Get A Coder Job! Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub React: The Virtual DOM Elixir and Phoenix Bootcamp Alexey Ivanov’s Twitter Andy Barnov’s Twitter Rob Pike’s YouTube Video Understanding Comics Understanding Comics – Book Get A Coder Job Charles Max Wood’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Lucas Check your room for sound Andy Go Programming Language Alexey Understanding comics Justin The Complete Elixir and Phoenix Bootcamp

Panel: Lucas Reis Justin Bennett Special Guests: Alexey Ivanov and Andy Barnov In this episode, the panelists talk with Alexey Ivanov and Andy Barnov. They all discuss Alexey’s article titled: “Optimizing React Virtual DOM.” Listen to today’s episode to hear all the details about this article, the guests’ backgrounds and much, much more! Show Topics: 0:32 – Panel: Thanks for joining us and talking about this article. 0:52 – Guest: Thanks for having us on your podcast! The guest talks about his community of developers and the offices are in San Francisco, Russia and other places. He talks about how the company helps their customers and how they can scale. Some of their companies are Groupon and Ebay. 2:39 – Alexey. 3:09 – Panel: The article is here. What is JSX how does it boil down to? It’s all supposed to help people and help them understand. 3:45 – Alexey: It’s about how to structure your state, etc. 4:15 – Panel: This keeps things small. He said when I have one idea I write a song and when I have 2 ideas I write 2 songs. If you try to put too many ideas into one post it maybe won’t go too far. 4:48 – Alexey. 5:50 – Panel. 5:56 – Panel: That’s a topic for another episode. The article is interesting in that the large percentage don’t think about rendering performance, so it’s a needed piece of content. Let’s talk about – what is the React Virtual DOM? 6:32 – Alexey goes into detail with his answer to the panelist’s question. 8:50 – Panel: What I like about this article is that you go through a good progression: here is the JSX that you would write and here is the trans piled function is. And you show the virtual DOM pre-presentation is. I think that is a helpful thing. Let’s talk about that. How does React change to those things when it’s rendering? 9:50 – Alexey. 12:58 – Panel: Okay to recap...when you are rendering an element you write some JSX and the first thing (component) that will map over to the type property is for the Virtual DOM object? And then all of that is compared – when does that happen, the comparison? 13:28 – Alexey: You have React and you create... 15:20 – Panel: So it’s both React and set state these are the only 2 things that triggered state or is there anything else out there? 15:31 – Alexey. 15:47 – Panel: Interesting. You talked about the imperative way we did it before – and it’s much simpler to say what you want, but a question is that is there any world case where it does not work well? What are the trade-offs? Have you ever encountered one? 16:34 – Alexey: If you have changes in the browse, implementations...it’s simplest and easiest way. You just need to have some little changes... 17:53 – Panel: If it’s basic then you don’t have to do manual updates. 18:03 – Alexey. Alexey: To make it work you need competence in your bundle. 18:36 – Panel: I’ve heard – haven’t worked with – when we have these projects that are really web time based, hundreds of elements in real time on a screen, on a Virtual DOM it’s too slow. You have to be precise. They had performance issues, I’m sure 98.99% of the applications probably perform better with the Virtual DOM.  19:46 – Alexey. 21:38 – Panel: That is to reduce the amount of state changes so you are reducing the amount of time it renders – right? 21:50 – Alexey. 22:03 – FRESH BOOKS! 23:11 – Panel: We talked about how type is the first thing that is checked. It does equal comparison to compare these types. What was really interesting is that class components are the same thing but not so. Is it always going to re-render for those components? 24:24 – Alexey: We have to talk about 2 things about this first. In my article... 27:49 – Panel: That is a beneficial tool too to control your rendering. You talked about tools to show updates and we will include the link to the article in the links, also I would read it and check out that particular function. It’s cool to see HOW it’s actually rendering. 28:29 – Panel: Apparently sometimes things help us in principle cause we need performance. We need to open the tools and understand what is happening? Is it really a bottleneck like I think it is? One of those Twitter things I saw a few months ago... 30:52 – Alexey: Yes, do what makes sense to you at the time. 32:08 – Panel: We talked about render performance and the pure component and not creating functions...you have a big quote in your article... I have a big question for me: You have a component, and there is a child / parent component. I am curious about that pattern – will it re-render every time? Tell us your thoughts, please. 33:16 – Alexey. 34:11 – Panel: My only issue with the render props is not a performance issue it’s more of an architectural issue. Sometimes we want things to be interjected. I want to have access to this or that. Sometimes we want to access those on a life cycle. The higher the component makes it easier to add a... That’s my only complaint about render comps. 35:35 – Alexey. 36:00 – Panel: Like composing consumers? 36:06 – Alexey: What we are talking about is... 37:00 – Panel: I agree. There are some interesting cases with that pattern when you have a lot of those chained together – function, function, etc. – there are some components that will help you compose... 37:34 – Panel: It’s like callback hell all over again. Everything is a tradeoff somewhere. After the tree it looks clean with render props. I like it even with the drawbacks. 38:25 – Panel: You spent some time talking about lists of children and how you (if one of the children are removed) then it ends up re rendering all the children cause it’s comparing their positions. You mentioned key is one way to deal with that. Let’s talk about keys. When people use keys they are using an array of an index. It seems like it defeats the purpose of it – is that right? 39:20 – Alexey: Yes, you are right.  40:19 – Panel: I think that continually and it’s a smaller known thing but people want this key error to go away and they just shove something in there. To some extent it’s good to know if your tool requires something it’s good to know WHY it requires that. 40:52 – Panel: Last question. Is that the person to program and be a web developer and they are learning React. This is the tool and they are learning how to use React for an app then when we are throwing articles at them. If they are learning React and these articles are at them I think it’s a cognitive overload. What are your thoughts / advice? 42:07 – Guest: How beginner should you be before you learn React? Ideally you should be aware of JavaScript, right? Sometimes people do this to catch up to something shiny. This is just my 2 cents.  43:03 – Alexey. 44:49 – Panel: When you are going to hire someone to do something or choose a framework always try to do a little bit of work without it. Try to build an application w/o React, and then React is introduced to you, you will only see the benefits that they are brining. One thing that happens inside the React world is that people don’t write an application... Start with the basic building blocks – that makes sense to me. 46:05 – Panel: Let’s go to picks! 46:13 – Advertisement – Get A Coder Job! Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub React: The Virtual DOM Elixir and Phoenix Bootcamp Alexey Ivanov’s Twitter Andy Barnov’s Twitter Rob Pike’s YouTube Video Understanding Comics Understanding Comics – Book Get A Coder Job Charles Max Wood’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Lucas Check your room for sound Andy Go Programming Language Alexey Understanding comics Justin The Complete Elixir and Phoenix Bootcamp

Go är ett populärt språk. Mikrotjänster är ett populärt koncept. Men det är inte helt vanligt att kombinationen diskuteras. Fredrik pratar med Erik Lupander på Callista om Eriks erfarenheter av att skriva mikrotjänster i Go och sammanfoga dem med andra tjänster och Java-baserade miljöer. Vi går igenom hur och varför Erik valde Go, hur det är att skriva mikrotjänster i språket, hur Gos filosofier passar och vad som eventuellt saknas eller är styrkor jämfört med ett oftare använt språk som Java. Spoiler: det är inte svårt att infoga en tjänst skriven i Go i en mikrotjänstmiljö som i övrigt är Javabaserad. Länkar Erik Lupander Callista Go Mikrotjänster Eriks bloggserie om Go och mikrotjänster Spring boot Node.js Amazon AWS-prislistor Spring cloud Netflix öppna stack Magnus Larsson och hans bloggserie Netflix Eureka Docker swarm Kretsbrytare Hystrix Kubernetes Openshift Polymorfism Composition over inheritance Duck typing Rob Pike, Ken Thompson och Robert Griesemer - Gos skapare Websphere Intellij IDEA Visual studio code Goland - Intellij:s IDE för Go Atom Make Gradle gofmt Cockroachdb Spanner CAP-teoremet Mongodb Gatling Rabbitmq Viper Generics i Java DRY-principen - don't repeat yourself Gos inbyggda testramverk Mockito Junit Goconvey BDD - beteendedriven utveckling Jasmine Interceptorer Aspektorienterad programmering Go kit Kite Workspaces i Go Semantic versioning Opencv Hibernate Referensintegritet Goroutines Channels Under utveckling är en podd av och för utvecklare, skapad i soliga (nåja) Göteborg av oss som jobbar på TimeEdit. Vi vill väldigt gärna höra dina åsikter om det vi pratar om! Vi finns på Twitter som uupodden och på Facebook som Under utveckling. Gillar du podden får du mer än gärna betygsätta oss i iTunes!

Tobias, Kristoffer och Fredrik snackar om Tobias kanske stressigaste veckor någonsin, allt tack vare (?) Androids NDK och Googles väldigt … grundliga hantering av appar med säkerhetshål. Det är svårt att utveckla saker för flera plattformar och man får helt andra problem när man inte kan välja att helt förlita sig på en enda plattform. Men, inte ens Google och Apple själva kan begränsa sig till att bara släppa appar på sina egna plattformar, så borde inte till och med de tjäna på lösa problemen ännu bättre? Sist lite tips om vilka av LLVMs sanerare man bör använda och när. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @iskrig och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Länkar Lagrad julmust Conan - pakethanterare för C++. Vi snackade med en av utvecklarna i avsnitt 198 Cmake Android NDK - låter dig skriva delar av din Android-app i språk kompilerade för plattformen, som C++ libpng ABI - application binary interface Boost libunwind Rob Pike om kodgenereringen i Go-kompilatorn LLVM-IR - IR är intermediärreprersentation, ett steg mellan språket man skrivit och binärkod för en specifik plattform ARC-processorn Super FX-chippet LLVM developer meeting 2017 LLVM har typesanerare på gång Addressaneraren i LLVM Trådsaneraren Whitesource Xray, inbyggt i Artifactory Titlar Vi hade någonting planerat Precis lika organiserat som vanligt Båda Tobias är här Välvilligt inställd till julmust En skön dold dependency Bad malloc Nu måste vi skeppa appen om tre dagar Backtracen är helt bisarr NDK:t är så fucked up Otroligt stressiga två veckor Ett sådant lapptäcke Vi kan sluta använda Googles ***** NDK Annars blir man knäpp på ett annat sätt En tvåplattformsvärld En varningsklocka när de forkar GCC Allt om min klustertruck Jag har tappat kontakten med statisk analys Många lager av ögon Då kan ju hela korthuset falla

RR 321: Visual Studio Code Ruby Plugin with Penn Lv This episode of Ruby Rogues features panelists Dave Kimura, Brian Hogan, and Charles Max Wood. Two special guests join the panel today: Eric Barry and Penn Lv. Tune in and learn more about Visual Studio Code’s Ruby Plug-in! [00:01:55] Introduction to Eric Barry Eric turned over Teach Me To Code to Charles, which helped build relationships for Charles that built the Ruby Rogues podcast. Eric is a software engineer who has been working in programming since 1998. He works for Skipio and has been a Ruby on Rails developer for nine years. [00:03:15] Introduction to Penn Lv Penn is a software engineer for Redim. He works on the Ruby extension for Visual Studio Code. This extension deals with enhanced Ruby language support. [4:00] What goes into building a language plug-in/language setup for VS code, what do you have to do in order to make that work in the electron set-up? Usually when you try to build an extension for VS code it is just a NodeJS application. It has nothing to do with electrons; it is just a Node application. Everything is run in a separate process. Just about how to build an extension for VS code. The first category is formatters, or colorization. For both of those you can write plain JavaScript. There are two categories that are difficult: first is de-buggers. The VS code is a set of common UI for de-bugging. Which is language diagnostic. Write an extension and hook up language debug. The second is a language server to write language experience. VS code has a concept called language server protocol. Need to write an extension that follows protocol and tells the VS code about semantic information about your program. [00:06:25] – In order to get some of the nice features for the language you have a Ruby process running somewhere that you talk to in order to do some of the syntax checking? Yes, have to run that in a stand-alone process. It analyzes Ruby, but it can’t run that in Node JS process. [00:06:52] So what’s the goal? What makes the VS code team write a Ruby program? Ruby for VS Code was his ticket to the VS code team. Penn wrote for himself. It is his hobby project. [00:07:32] How many contributors are on the project? Who works with you? It is a community project. There are probably in between 50 to 100 contributors. [00:08:33] What’s your process of knowing what to allow and what not to allow to modify it? How do you know what PRS to accept and how do you stay on top of it? It is challenging to know what to allow. Penn claims to still not be a professional Rubyist. The first step is to run test cases. His way of reviewing code is by downloading the code. He looks into every piece of the code, learns it, and plays around it. If it works, he adds it. [00:10:23] How main PRs do you regularly get and how much time does it take to keep that maintained? Every weekend he goes through everything. He will have maybe five to six VS code extensions and check them thoroughly. [00:13:30] Indentation when blogging in VS code Two months ago he finished a feature dealing with auto indentation. The option for this is called editor.autoindent. Indentation gets adjusted automatically while you type. [00:18:10] Recommendations for plug-ins Charles recommends Emacs key bindings and Penn recommends the VS code extension Vim. [00:21:49] Do you do most of your work in TypeScript? Yes. At the very beginning they were using JavaScript. They were one of the first adopters of TypeScript and are now all TypeScript. [00:22:50] How much of a commitment would it be to add TypeScript to an existing project? The setup of TypeScript is not easy. If you are using a NodeJS application and they have TypeScript or typing support there is no specific thing that needs to be done to make it happen. In VS code there is a feature called automatic type acquisition. If creating a new project that uses an express package, which already has a typing file for it. VS code provides you with auto complete. Also don’t need to worry about typescript file if you are not going to create a library. Can do TypeScript gradually. [00:26:16] What do you see that’s left to do in the Ruby plug-in? A language server is the missing part. [00:27:35] Is that currently being done in other editors? No one does that right now. RubyMine has the best support currently. [00:28:13] Does your work translate to Atom as well? Atom has basic support for Ruby but it is just about colorization, indentation, and formatters. Everyone is waiting for a language server for Ruby. [00:31:38] If you have multiple languages or modes that you have to handle within the same file how do you set up VS code to handle that? Users cannot customize that. A language support extension has to handle that. [00:34:50] What is the font that you use in VS code? Source code pro [00:35:08] If people want to give this a try, what are the best ways to do that? First go to code.visualstudio.com. Then, install VS code. At the welcome page instructions will show you how to use the command palate, give you an interactive playground, and show the best place to get familiar with everything. The welcome page also has links: one is VS tips and tricks, which are shared by the community. There is a Youtube channel, which shows how to make VS Code productive. [00:36:32] If someone is working on an esoteric language and there is no support in there language in VS code yet. Where would you recommend they start? There is a docs session on the website that tells you how to write extensions for VS Code. Penn thinks if you build a debugger it is most difficult. There needs to be an understanding of real debuggers. Look at some of existing debugger, understand how they read source code, get an understanding from there. [00:38:22] Was there an extension that you used as a model while writing the Ruby extension for VS code that you recommend people look at? First looked at Python. Then switched to PHP, which is pretty similar to the Ruby extension. The protocol is very similar. That’s how he learned to make the Ruby extension. [00:40:58] If people want to contribute, is there a GitHub they can go look at? The organization name is Ruby IDE and GitHub name is vscode-ruby. There is a Wiki Page on how to setup and explain concepts behind everything. [00:41:22] How long did it take you to get the plug-in till it was publicly useable? A couple of hours. He was at his girlfriend’s parent’s house bored, got a job with VS code because of it. [00:44:40] What’s your biggest sales pitch for VS code? Compared to some of competitors, VS code is fast. The best part of VS code is that it is open source. Everything is on GitHub, including issues and user feedback. Users know every issue that is being worked out. All information is open to users. Can file an issue and they will respond immediately. [00:47:00] Are there plug-ins for other languages? There is an elm plug-in. Picks Dave: Azure’s cognitive services Brian: OmniFocus Eric: Hugo Netlify Code Sponsor Charles: Building stairs Upwork Penn: The Text Editor Sam by Rob Pike Ruby Weekly

RR 321: Visual Studio Code Ruby Plugin with Penn Lv This episode of Ruby Rogues features panelists Dave Kimura, Brian Hogan, and Charles Max Wood. Two special guests join the panel today: Eric Barry and Penn Lv. Tune in and learn more about Visual Studio Code’s Ruby Plug-in! [00:01:55] Introduction to Eric Barry Eric turned over Teach Me To Code to Charles, which helped build relationships for Charles that built the Ruby Rogues podcast. Eric is a software engineer who has been working in programming since 1998. He works for Skipio and has been a Ruby on Rails developer for nine years. [00:03:15] Introduction to Penn Lv Penn is a software engineer for Redim. He works on the Ruby extension for Visual Studio Code. This extension deals with enhanced Ruby language support. [4:00] What goes into building a language plug-in/language setup for VS code, what do you have to do in order to make that work in the electron set-up? Usually when you try to build an extension for VS code it is just a NodeJS application. It has nothing to do with electrons; it is just a Node application. Everything is run in a separate process. Just about how to build an extension for VS code. The first category is formatters, or colorization. For both of those you can write plain JavaScript. There are two categories that are difficult: first is de-buggers. The VS code is a set of common UI for de-bugging. Which is language diagnostic. Write an extension and hook up language debug. The second is a language server to write language experience. VS code has a concept called language server protocol. Need to write an extension that follows protocol and tells the VS code about semantic information about your program. [00:06:25] – In order to get some of the nice features for the language you have a Ruby process running somewhere that you talk to in order to do some of the syntax checking? Yes, have to run that in a stand-alone process. It analyzes Ruby, but it can’t run that in Node JS process. [00:06:52] So what’s the goal? What makes the VS code team write a Ruby program? Ruby for VS Code was his ticket to the VS code team. Penn wrote for himself. It is his hobby project. [00:07:32] How many contributors are on the project? Who works with you? It is a community project. There are probably in between 50 to 100 contributors. [00:08:33] What’s your process of knowing what to allow and what not to allow to modify it? How do you know what PRS to accept and how do you stay on top of it? It is challenging to know what to allow. Penn claims to still not be a professional Rubyist. The first step is to run test cases. His way of reviewing code is by downloading the code. He looks into every piece of the code, learns it, and plays around it. If it works, he adds it. [00:10:23] How main PRs do you regularly get and how much time does it take to keep that maintained? Every weekend he goes through everything. He will have maybe five to six VS code extensions and check them thoroughly. [00:13:30] Indentation when blogging in VS code Two months ago he finished a feature dealing with auto indentation. The option for this is called editor.autoindent. Indentation gets adjusted automatically while you type. [00:18:10] Recommendations for plug-ins Charles recommends Emacs key bindings and Penn recommends the VS code extension Vim. [00:21:49] Do you do most of your work in TypeScript? Yes. At the very beginning they were using JavaScript. They were one of the first adopters of TypeScript and are now all TypeScript. [00:22:50] How much of a commitment would it be to add TypeScript to an existing project? The setup of TypeScript is not easy. If you are using a NodeJS application and they have TypeScript or typing support there is no specific thing that needs to be done to make it happen. In VS code there is a feature called automatic type acquisition. If creating a new project that uses an express package, which already has a typing file for it. VS code provides you with auto complete. Also don’t need to worry about typescript file if you are not going to create a library. Can do TypeScript gradually. [00:26:16] What do you see that’s left to do in the Ruby plug-in? A language server is the missing part. [00:27:35] Is that currently being done in other editors? No one does that right now. RubyMine has the best support currently. [00:28:13] Does your work translate to Atom as well? Atom has basic support for Ruby but it is just about colorization, indentation, and formatters. Everyone is waiting for a language server for Ruby. [00:31:38] If you have multiple languages or modes that you have to handle within the same file how do you set up VS code to handle that? Users cannot customize that. A language support extension has to handle that. [00:34:50] What is the font that you use in VS code? Source code pro [00:35:08] If people want to give this a try, what are the best ways to do that? First go to code.visualstudio.com. Then, install VS code. At the welcome page instructions will show you how to use the command palate, give you an interactive playground, and show the best place to get familiar with everything. The welcome page also has links: one is VS tips and tricks, which are shared by the community. There is a Youtube channel, which shows how to make VS Code productive. [00:36:32] If someone is working on an esoteric language and there is no support in there language in VS code yet. Where would you recommend they start? There is a docs session on the website that tells you how to write extensions for VS Code. Penn thinks if you build a debugger it is most difficult. There needs to be an understanding of real debuggers. Look at some of existing debugger, understand how they read source code, get an understanding from there. [00:38:22] Was there an extension that you used as a model while writing the Ruby extension for VS code that you recommend people look at? First looked at Python. Then switched to PHP, which is pretty similar to the Ruby extension. The protocol is very similar. That’s how he learned to make the Ruby extension. [00:40:58] If people want to contribute, is there a GitHub they can go look at? The organization name is Ruby IDE and GitHub name is vscode-ruby. There is a Wiki Page on how to setup and explain concepts behind everything. [00:41:22] How long did it take you to get the plug-in till it was publicly useable? A couple of hours. He was at his girlfriend’s parent’s house bored, got a job with VS code because of it. [00:44:40] What’s your biggest sales pitch for VS code? Compared to some of competitors, VS code is fast. The best part of VS code is that it is open source. Everything is on GitHub, including issues and user feedback. Users know every issue that is being worked out. All information is open to users. Can file an issue and they will respond immediately. [00:47:00] Are there plug-ins for other languages? There is an elm plug-in. Picks Dave: Azure’s cognitive services Brian: OmniFocus Eric: Hugo Netlify Code Sponsor Charles: Building stairs Upwork Penn: The Text Editor Sam by Rob Pike Ruby Weekly

RR 321: Visual Studio Code Ruby Plugin with Penn Lv This episode of Ruby Rogues features panelists Dave Kimura, Brian Hogan, and Charles Max Wood. Two special guests join the panel today: Eric Barry and Penn Lv. Tune in and learn more about Visual Studio Code’s Ruby Plug-in! [00:01:55] Introduction to Eric Barry Eric turned over Teach Me To Code to Charles, which helped build relationships for Charles that built the Ruby Rogues podcast. Eric is a software engineer who has been working in programming since 1998. He works for Skipio and has been a Ruby on Rails developer for nine years. [00:03:15] Introduction to Penn Lv Penn is a software engineer for Redim. He works on the Ruby extension for Visual Studio Code. This extension deals with enhanced Ruby language support. [4:00] What goes into building a language plug-in/language setup for VS code, what do you have to do in order to make that work in the electron set-up? Usually when you try to build an extension for VS code it is just a NodeJS application. It has nothing to do with electrons; it is just a Node application. Everything is run in a separate process. Just about how to build an extension for VS code. The first category is formatters, or colorization. For both of those you can write plain JavaScript. There are two categories that are difficult: first is de-buggers. The VS code is a set of common UI for de-bugging. Which is language diagnostic. Write an extension and hook up language debug. The second is a language server to write language experience. VS code has a concept called language server protocol. Need to write an extension that follows protocol and tells the VS code about semantic information about your program. [00:06:25] – In order to get some of the nice features for the language you have a Ruby process running somewhere that you talk to in order to do some of the syntax checking? Yes, have to run that in a stand-alone process. It analyzes Ruby, but it can’t run that in Node JS process. [00:06:52] So what’s the goal? What makes the VS code team write a Ruby program? Ruby for VS Code was his ticket to the VS code team. Penn wrote for himself. It is his hobby project. [00:07:32] How many contributors are on the project? Who works with you? It is a community project. There are probably in between 50 to 100 contributors. [00:08:33] What’s your process of knowing what to allow and what not to allow to modify it? How do you know what PRS to accept and how do you stay on top of it? It is challenging to know what to allow. Penn claims to still not be a professional Rubyist. The first step is to run test cases. His way of reviewing code is by downloading the code. He looks into every piece of the code, learns it, and plays around it. If it works, he adds it. [00:10:23] How main PRs do you regularly get and how much time does it take to keep that maintained? Every weekend he goes through everything. He will have maybe five to six VS code extensions and check them thoroughly. [00:13:30] Indentation when blogging in VS code Two months ago he finished a feature dealing with auto indentation. The option for this is called editor.autoindent. Indentation gets adjusted automatically while you type. [00:18:10] Recommendations for plug-ins Charles recommends Emacs key bindings and Penn recommends the VS code extension Vim. [00:21:49] Do you do most of your work in TypeScript? Yes. At the very beginning they were using JavaScript. They were one of the first adopters of TypeScript and are now all TypeScript. [00:22:50] How much of a commitment would it be to add TypeScript to an existing project? The setup of TypeScript is not easy. If you are using a NodeJS application and they have TypeScript or typing support there is no specific thing that needs to be done to make it happen. In VS code there is a feature called automatic type acquisition. If creating a new project that uses an express package, which already has a typing file for it. VS code provides you with auto complete. Also don’t need to worry about typescript file if you are not going to create a library. Can do TypeScript gradually. [00:26:16] What do you see that’s left to do in the Ruby plug-in? A language server is the missing part. [00:27:35] Is that currently being done in other editors? No one does that right now. RubyMine has the best support currently. [00:28:13] Does your work translate to Atom as well? Atom has basic support for Ruby but it is just about colorization, indentation, and formatters. Everyone is waiting for a language server for Ruby. [00:31:38] If you have multiple languages or modes that you have to handle within the same file how do you set up VS code to handle that? Users cannot customize that. A language support extension has to handle that. [00:34:50] What is the font that you use in VS code? Source code pro [00:35:08] If people want to give this a try, what are the best ways to do that? First go to code.visualstudio.com. Then, install VS code. At the welcome page instructions will show you how to use the command palate, give you an interactive playground, and show the best place to get familiar with everything. The welcome page also has links: one is VS tips and tricks, which are shared by the community. There is a Youtube channel, which shows how to make VS Code productive. [00:36:32] If someone is working on an esoteric language and there is no support in there language in VS code yet. Where would you recommend they start? There is a docs session on the website that tells you how to write extensions for VS Code. Penn thinks if you build a debugger it is most difficult. There needs to be an understanding of real debuggers. Look at some of existing debugger, understand how they read source code, get an understanding from there. [00:38:22] Was there an extension that you used as a model while writing the Ruby extension for VS code that you recommend people look at? First looked at Python. Then switched to PHP, which is pretty similar to the Ruby extension. The protocol is very similar. That’s how he learned to make the Ruby extension. [00:40:58] If people want to contribute, is there a GitHub they can go look at? The organization name is Ruby IDE and GitHub name is vscode-ruby. There is a Wiki Page on how to setup and explain concepts behind everything. [00:41:22] How long did it take you to get the plug-in till it was publicly useable? A couple of hours. He was at his girlfriend’s parent’s house bored, got a job with VS code because of it. [00:44:40] What’s your biggest sales pitch for VS code? Compared to some of competitors, VS code is fast. The best part of VS code is that it is open source. Everything is on GitHub, including issues and user feedback. Users know every issue that is being worked out. All information is open to users. Can file an issue and they will respond immediately. [00:47:00] Are there plug-ins for other languages? There is an elm plug-in. Picks Dave: Azure’s cognitive services Brian: OmniFocus Eric: Hugo Netlify Code Sponsor Charles: Building stairs Upwork Penn: The Text Editor Sam by Rob Pike Ruby Weekly

Is your operating system hosed? That might be related to Rails! We also chat about the trend towards compiled languages. RailsConf Shirts- Please only order if you will be at RailsConf to pick up! The pre-show The listen gem breaks my laptop Interpreted Language LLVM Cambrian Explosion Crystal Rob Pike on Googlers Rob Pike on the programmer prerequisites Thank you to our sponsor this week, SparkPost

Today on the show, we are going to be chatting with Michael Dexter about a variety of topics, but of course including bhyve! That plus This episode was brought to you by Headlines NetBSD Introduction (https://bsdmag.org/netbsd_intr/) We start off today's episode with a great new NetBSD article! Siju Oommen George has written an article for BSDMag, which provides a great overview of NetBSD's beginnings and what it is today. Of course you can't start an article about NetBSD without mentioning where the name came from: “The four founders of the NetBSD project, Chris Demetriou, Theo de Raadt, Adam Glass, and Charles Hannum, felt that a more open development model would benefit the project: one centered on portable, clean and correct code. They aimed to produce a unified, multi-platform, production-quality, BSD-based operating system. The name “NetBSD” was suggested by de Raadt, based on the importance and growth of networks, such as the Internet at that time, the distributed and collaborative nature of its development.” From there NetBSD has expanded, and keeping in line with its motto “Of course it runs NetBSD” it has grown to over 57 hardware platforms, including “IA-32, Alpha, PowerPC,SPARC, Raspberry pi 2, SPARC64 and Zaurus” From there topics such as pkgsrc, SMP, embedded and of course virtualization are all covered, which gives the reader a good overview of what to expect in the modern NetBSD today. Lastly, in addition to mentioning some of the vendors using NetBSD in a variety of ways, including Point-Of-Sale systems, routers and thin-clients, you may not have known about the research teams which deploy NetBSD: NASA Lewis Research Center – Satellite Networks and Architectures Branch use NetBSD almost exclusively in their investigation of TCP for use in satellite networks. KAME project – A research group for implementing IPv6, IPsec and other recent TCP/IP related technologies into BSD UNIX kernels, under BSD license. NEC Europe Ltd. established the Network Laboratories in Heidelberg, Germany in 1997, as NEC's third research facility in Europe. The Heidelberg labs focus on software-oriented research and development for the next generation Internet. SAMS-II Project – Space Acceleration Measurement System II. NASA will be measuring the microgravity environment on the International Space Station using a distributed system, consisting of NetBSD.“ My condolences, you're now the maintainer of a popular open source project (https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) A presentation from a Wordpress conference, about what it is like to be the maintainer of a popular open source project The presentation covers the basics: Open Source is more than just the license, it is about community and involvement The difference between Maintainers and Contributors It covers some of the reasons people do not open up their code, and other common problems people run into: “I'm embarrassed by my code” (Hint: so is everyone else, post it anyway, it is the best way to learn) “I'm discouraged that I can't finish releases on time” “I'm overwhelmed by the PR backlog” “I'm frustrated when issues turn into flamewars” “I'm overcommitted on my open source involvement” “I feel all alone” Each of those points is met with advice and possible solutions So, there you have it. Open up your code, or join an existing project and help maintain it *** FreeBSD Committer Allan Jude Discusses the Advantages of FreeBSD and His Role in Keeping Millions of Servers Running (http://www.hostingadvice.com/blog/freebsd-project-under-the-hood/) An interesting twist on our normal news-stories today, we have an article featuring our very own Allan Jude, talking about why FreeBSD and the advantages of working on an open-source project. “When Allan started his own company hosting websites for video streaming, FreeBSD was the only operating system he had previously used with other hosts. Based on his experience and comfort with it, he trusted the system with the future of his budding business.A decade later, the former-SysAdmin went to a conference focused on the open-source operating system, where he ran into some of the folks on its documentation team. “They inspired me,” he told our team in a recent chat. He began writing documentation but soon wanted to contribute improvements beyond the docs.Today, Allan sits as a FreeBSD Project Committer. It's rare that you get to chat with someone involved with a massive-scale open-source project like this — rare and awesome.” From there Allan goes into some of the reasons “Why” FreeBSD, starting with Code Organization being well-maintained and documented: “The FreeBSD Project functions like an extremely well-organized world all its own. Allan explained the environment: “There's a documentation page that explains how the file system's laid out and everything has a place and it always goes in that place.”” + In addition, Allan gives us some insight into his work to bring Boot-Environments to the loader, and other reasons why FreeBSD “just makes sense” + In summary Allan wraps it up quite nicely: “An important take-away is that you don't have to be a major developer with tons of experience to make a difference in the project,” Allan said — and the difference that devs like Allan are making is incredible. If you too want to submit the commit that contributes to the project relied on by millions of web servers, there are plenty of ways to get involved! We're especially talking to SysAdmins here, as Allan noted that they are the main users of FreeBSD. “Having more SysAdmins involved in the actual build of the system means we can offer the tools they're looking for — designed the way a SysAdmin would want them designed, not necessarily the way a developer would think makes the most sense” A guide to saving electricity and time with poudriere and bhyve (http://justinholcomb.me/blog/2016/07/03/poudriere-in-bhyve-and-bare-metal.html) “This article goes over running poudriere to built packages for a Raspberry Pi with the interesting twist of running it both as a bhyve guest and then switching to running on bare metal via Fiber Channel via ctld by sharing the same ZFS volume.” “Firstly, poudriere can build packages for different architectures such as ARM. This can save hours of build time compared to building ports from said ARM device.” “Secondly, let's say a person has an always-on device (NAS) running FreeBSD. To save power, this device has a CPU with a low clock-rate and low core count. This low clock-rate and core count is great for saving power but terrible for processor intensive application such as poudriere. Let's say a person also has another physical server with fast processors and a high CPU count but draws nearly twice the power and a fan noise to match.” “To get the best of both worlds, the goal is to build the packages on the fast physical server, power it down, and then start the same ZFS volume in a bhyve environment to serve packages from the always-on device.” The tutorial walks through setting up ‘ahost', the always on machine, ‘fhost' the fast but noisy build machine, and a raspberry pi It also includes creating a zvol, configuring iSCSI over fibre channel and exporting the zvol, booting an iSCSI volume in bhyve, plus installing and setting up poudriere This it configures booting over fibre channel, and cross-building armv6 (raspberry pi) packages on the fast build machine Then the fast machine is shut down, and the zvol is booted in bhyve on the NAS Everything you need to know to make a hybrid physical/virtual machine The same setup could also work to run the same bhyve VM from either ahost or fhost bhyve does not yet support live migration, but when it does, having common network storage like the zvol will be an important part of that *** Interview - Michael Dexter - editor@callfortesting.org (mailto:editor@callfortesting.org) / @michaeldexter (https://twitter.com/michaeldexter) The RoloDexter *** iXSystems Children's Minnesota Star Studio Chooses iXsystems' TrueNAS Storage (https://www.youtube.com/watch?v=FFbdQ_05e-0) *** News Roundup FreeBSD Foundation June 2016 Update (https://www.freebsdfoundation.org/wp-content/uploads/2016/06/FreeBSD-Foundation-June-2016-Update.pdf) The FreeBSD Foundation's June newsletter is out Make sure you submit the FreeBSD Community Survey (https://www.surveymonkey.com/r/freebsd2016) by July 7th: In addition to the opening message from the executive director of the foundation, the update includes details to sponsored work on the FreeBSD VM system, reports from a number of conferences the Foundation attended, including BSDCan The results of the foundation's yearly board meeting People the foundation recognized for their contributions to FreeBSD at BSDCan And an introduction to their new “Getting Started with FreeBSD” project *** [How-To] Building the FreeBSD OS from scratch (http://www.all-nettools.com/forum/showthread.php?34422-Building-the-FreeBSD-OS-from-scratch) A tutorial over at the All-NetTools.com forums that walks through building FreeBSD from scratch I am not sure why anyone would want to build Xorg from source, but you can It covers everything in quite a bit of detail, from the installation process through adding Xorg and a window manager from source It also includes tweaking some device node permissions for easier operation as a non-root user, and configuring the firewall *** Window Systems Should Be Transparent (http://doc.cat-v.org/bell_labs/transparent_wsys/) + Rob Pike of AT&T Labs writes about why Window Systems should be transparent This is an old paper (undated, but I think from the late 80s), but may contain some timeless insights “UNIX window systems are unsatisfactory. Because they are cumbersome and complicated, they are unsuitable companions for an operating system that is appreciated for its technical elegance” “A good interface should clarify the view, not obscure it” “Mux is one window system that is popular and therefore worth studying as an example of good design. (It is not commercially important because it runs only on obsolete hardware.) This paper uses mux as a case study to illustrate some principles that can help keep a user interface simple, comfortable, and unobtrusive. When designing their products, the purveyors of commercial window systems should keep these principles in mind.” There are not many commercial window systems anymore, but “open source” was not really a big thing when this paper was written *** Roger Faulkner, of Solaris fame passed away (http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/12877) “RIP Roger Faulkner: creator of the One and True /proc, slayer of the M-to-N threading model -- and the godfather of post-AT&T Unix” @bcantrill: Another great Roger Faulkner story (https://twitter.com/bcantrill/status/750442169807171584) The story of how pgrep -w saved a monitor -- if not a life (https://news.ycombinator.com/item?id=4306515) @bcantrill: With Roger Faulkner, Tim led an engineering coup inside Sun that saved Solaris circa 2.5 (https://twitter.com/bcantrill/status/750442169807171584) *** Beastie Bits: Developer Ed Maste is requesting information from those who are users of libvgl. (https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084843.html) HEADS UP: DragonFly 4.5 world reneeds rebuilding (http://lists.dragonflybsd.org/pipermail/users/2016-June/249748.html) Chris Buechler is leaving the pfSense project, the entire community thanks you for your many years of service (https://blog.pfsense.org/?p=2095) GhostBSD 10.3-BETA1 now available (http://ghostbsd.org/10.3_BETA1) DragonFlyBSD adds nvmectl (http://lists.dragonflybsd.org/pipermail/commits/2016-June/500671.html) OPNsense 16.1.18 released (https://opnsense.org/opnsense-16-1-18-released/) bhyve_graphics hit CURRENT (https://svnweb.freebsd.org/base?view=revision&revision=302332) BUG Update FreeBSD Central Twitter account looking for a new owner (https://twitter.com/freebsdcentral/status/750053703420350465) NYCBUG meeting : Meet the Smallest BSDs: RetroBSD and LiteBSD, Brian Callahan (http://lists.nycbug.org/pipermail/talk/2016-July/016732.html) NYCBUG install fest @ HOPE (http://lists.nycbug.org/pipermail/talk/2016-June/016694.html) SemiBUG is looking for presentations for September and beyond (http://lists.nycbug.org/pipermail/semibug/2016-June/000107.html) Caleb Cooper is giving a talk on Crytpo at KnoxBUG on July 26th (http://knoxbug.org/content/2016-07-26) Feedback/Questions Leif - ZFS xfer (http://pastebin.com/vvASr64P) Zach - Python3 (http://pastebin.com/SznQHq7n) Dave - Versioning (http://pastebin.com/qkpjKEr0) David - Encrypted Disk Images (http://pastebin.com/yr7BUmv2) Eli - TLF in all the wrong places (http://pastebin.com/xby81NvC) ***

Multithreading is not the only approach we use to deal with concurrency. Single-purpose processes is our next frontier. Processes, that don't have shared state. To coordinate, they pass messages to each other. We can build complex concurrent systems using simple principles of CSP or Actors model. We break down programs into independent processes, each performing some specific job, talking to each other. How they talk to each is the point of contention here. That's where the differences between CSP and Actors arise. Host: Andrey Salomatin http://twitter.com/flpvsk Guests: - Aaron Schlesinger http://arschles.com/ - Jörgen Brandt http://www.joergen-brandt.de/ Sources: - CSP - “Communicating Sequential Processes” orignial paper by C. A. R. Hoare http://www.usingcsp.com/cspbook.pdf - Go - “Go in 5 minutes” screencast by Aaron https://www.youtube.com/channel/UC2GHqYE3fVJMncbrRd8AqcA - “Effective Go” https://golang.org/doc/effective_go.html - “Go Concurrency Patterns” talk by Rob Pike https://talks.golang.org/2012/concurrency.slide#1 - net.Context documentation: https://godoc.org/golang.org/x/net/context - WebSockets documentation: https://godoc.org/golang.org/x/net/websocket - Actors - “A Universal Modular Actor Formalism for Artificial Intelligence” original paper by Carl Hewitt; Peter Bishop; Richard Steiger http://worrydream.com/refs/Hewitt-ActorModel.pdf - Erlang - “Learn You Some Erlang for great good!” by Fred Hébert http://learnyousomeerlang.com/ - “Programming Erlang” by Joe Armstrong http://amzn.to/1UnfJpB Projects to check out: - Go - Docker https://github.com/docker/docker - “Awesome Go” – a curated list of awesome Go frameworks, libraries and software https://github.com/avelino/awesome-go - Parallelism - Cuneiform http://www.cuneiform-lang.org/ Music: Mid-Air! @mid_air ---------- PS: Links to Amazon are referral. You can use them to support the show.

02:36 - Software Development and Reality Construction by Christiane Floyd Hermeneutics 05:42 - Peter Naur: Programming as Theory Building   07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren 13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas 14:32 - ng-book 2 16:09 - Paper Reading Group Adrian Colyer's Blog We hear you like papers by Ines Sombra (Slides) 19:58 - Mindset: The New Psychology of Success by Carol Dweck 20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell 22:01 - Ruby Rogues Book Club Books Episodes Ruby Rogues Episode #23: Book Club: Smalltalk Best Practice Patterns with Kent Beck Ruby Rogues Episode #87: Practical Object-Oriented Design in Ruby with Sandi Metz Ruby Rogues Episode #68: Book Club: Growing Object Oriented Software Guided by Tests with Steve Freeman and Nat Pryce Ruby Rogues Episode #97: Patterns of Enterprise Application Architecture with Martin Fowler Ruby Rogues Episode #178: Book Club: Refactoring Ruby with Martin Fowler 22:43 - Books to Learn When You’re Learning to Become a Software Developer Peopleware: Productive Projects and Teams by Tom DeMarco The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Software Project Survival Guide by Steve McConnell Code Complete: A Practical Handbook of Software Construction by Steve McConnell     The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt The Practice of Programming by Brian W. Kernighan and Rob Pike 33:07 - Technical Programming Books Programming Perl: Unmatched power for text processing and scripting by Tom Christiansen (The Camel Book) Unix Power Tools by Shelley Powers Ruby Cookbook by Lucas Carlson Programming Ruby: The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt Agile Web Development with Rails 4 (Facets of Ruby) by Sam Ruby    SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by John Viescas The Art of SQL by Stephane Faroult PostgreSQL: Up and Running: A Practical Introduction to the Advanced Open Source Database by Regina O. Obe SQL Pocket Guide by Jonathan Gennick SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin Why's (Poignant) Guide to Ruby       Why The Lucky Stiff 41:17 - Pramming and Business Books The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull In The Plex: How Google Thinks, Works, and Shapes Our Lives by Steven Levy The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim    So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler Soft Skills: The software developer's life manual by John Sonmez The Rails Freelancing Handbook by Mike Gunderloy The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online by Violet Blue Doxing Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam Picks Mark Manson: The Most Important Question of Your Life (Jessica) Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline) The Noun Project (Avdi) Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi) CES (Chuck) Bill Buxton: Avoiding the Big Crash (Jessica)

02:36 - Software Development and Reality Construction by Christiane Floyd Hermeneutics 05:42 - Peter Naur: Programming as Theory Building   07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren 13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas 14:32 - ng-book 2 16:09 - Paper Reading Group Adrian Colyer's Blog We hear you like papers by Ines Sombra (Slides) 19:58 - Mindset: The New Psychology of Success by Carol Dweck 20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell 22:01 - Ruby Rogues Book Club Books Episodes Ruby Rogues Episode #23: Book Club: Smalltalk Best Practice Patterns with Kent Beck Ruby Rogues Episode #87: Practical Object-Oriented Design in Ruby with Sandi Metz Ruby Rogues Episode #68: Book Club: Growing Object Oriented Software Guided by Tests with Steve Freeman and Nat Pryce Ruby Rogues Episode #97: Patterns of Enterprise Application Architecture with Martin Fowler Ruby Rogues Episode #178: Book Club: Refactoring Ruby with Martin Fowler 22:43 - Books to Learn When You’re Learning to Become a Software Developer Peopleware: Productive Projects and Teams by Tom DeMarco The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Software Project Survival Guide by Steve McConnell Code Complete: A Practical Handbook of Software Construction by Steve McConnell     The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt The Practice of Programming by Brian W. Kernighan and Rob Pike 33:07 - Technical Programming Books Programming Perl: Unmatched power for text processing and scripting by Tom Christiansen (The Camel Book) Unix Power Tools by Shelley Powers Ruby Cookbook by Lucas Carlson Programming Ruby: The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt Agile Web Development with Rails 4 (Facets of Ruby) by Sam Ruby    SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by John Viescas The Art of SQL by Stephane Faroult PostgreSQL: Up and Running: A Practical Introduction to the Advanced Open Source Database by Regina O. Obe SQL Pocket Guide by Jonathan Gennick SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin Why's (Poignant) Guide to Ruby       Why The Lucky Stiff 41:17 - Pramming and Business Books The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull In The Plex: How Google Thinks, Works, and Shapes Our Lives by Steven Levy The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim    So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler Soft Skills: The software developer's life manual by John Sonmez The Rails Freelancing Handbook by Mike Gunderloy The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online by Violet Blue Doxing Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam Picks Mark Manson: The Most Important Question of Your Life (Jessica) Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline) The Noun Project (Avdi) Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi) CES (Chuck) Bill Buxton: Avoiding the Big Crash (Jessica)

02:36 - Software Development and Reality Construction by Christiane Floyd Hermeneutics 05:42 - Peter Naur: Programming as Theory Building   07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren 13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas 14:32 - ng-book 2 16:09 - Paper Reading Group Adrian Colyer's Blog We hear you like papers by Ines Sombra (Slides) 19:58 - Mindset: The New Psychology of Success by Carol Dweck 20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell 22:01 - Ruby Rogues Book Club Books Episodes Ruby Rogues Episode #23: Book Club: Smalltalk Best Practice Patterns with Kent Beck Ruby Rogues Episode #87: Practical Object-Oriented Design in Ruby with Sandi Metz Ruby Rogues Episode #68: Book Club: Growing Object Oriented Software Guided by Tests with Steve Freeman and Nat Pryce Ruby Rogues Episode #97: Patterns of Enterprise Application Architecture with Martin Fowler Ruby Rogues Episode #178: Book Club: Refactoring Ruby with Martin Fowler 22:43 - Books to Learn When You’re Learning to Become a Software Developer Peopleware: Productive Projects and Teams by Tom DeMarco The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Software Project Survival Guide by Steve McConnell Code Complete: A Practical Handbook of Software Construction by Steve McConnell     The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt The Practice of Programming by Brian W. Kernighan and Rob Pike 33:07 - Technical Programming Books Programming Perl: Unmatched power for text processing and scripting by Tom Christiansen (The Camel Book) Unix Power Tools by Shelley Powers Ruby Cookbook by Lucas Carlson Programming Ruby: The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt Agile Web Development with Rails 4 (Facets of Ruby) by Sam Ruby    SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by John Viescas The Art of SQL by Stephane Faroult PostgreSQL: Up and Running: A Practical Introduction to the Advanced Open Source Database by Regina O. Obe SQL Pocket Guide by Jonathan Gennick SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin Why's (Poignant) Guide to Ruby       Why The Lucky Stiff 41:17 - Pramming and Business Books The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull In The Plex: How Google Thinks, Works, and Shapes Our Lives by Steven Levy The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim    So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler Soft Skills: The software developer's life manual by John Sonmez The Rails Freelancing Handbook by Mike Gunderloy The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online by Violet Blue Doxing Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam Picks Mark Manson: The Most Important Question of Your Life (Jessica) Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline) The Noun Project (Avdi) Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi) CES (Chuck) Bill Buxton: Avoiding the Big Crash (Jessica)

高手用烂语言也能写出好软件吗？ Objective-C──Mac 和 iOS 软件的指定开发语言──语法奇怪（吴涛有详细举例），苹果的另一专属语言 AppleScript 也相当难用，但 Mac 和 iOS 的商业成功让人捏着鼻子学 Objective-C。 和 Objective-C 相比，谷歌力推的 Go 更像是一种未来可行的全功能语言。 程序员喜欢解决「通用型问题」（generic problem），而 Objective-C 擅长的恰恰不是通用型问题。 相关链接 JavaScript 是什么？ NeXT Objective-C Xamarin.iOS (旧名MonoTouch) Titanium Unity MacRuby 「垃圾回收」机制 函数式编程 C# ASP.NET 《大教堂与市集》 Common Language Runtime AppCode (Objective-C 的第三方 IDE) PhoneGap (Cordova) Ken Thompson Rob Pike Space Monkey Brent Simmons: Surviving UI Programming Sapir-Whorf Hypothesis 人物简介 李如一：字节社创始人。 Rio: Apple4us 程序员。 吴涛：Type is Beautiful 程序员。

本期由 Terry Tai 主持，邀请到了 Workor网 的两位创始人: 一位是前 Biu网 的创始人韩吉云，还有前果壳网 team leader 刘连响，来和他们一起聊聊他们的创业故事以及背后的一些技术选型。 Show Notes: workor 视觉中国 果壳网 Django Lua Biu v2ex Medium Michael Bleigh The Lean Startup GoToMeeting join.me WebRTC Sqwiggle LiveMinute Google Hangouts mixpanel Zendesk Olark 漫咖啡 Backbone.js node.js Flask mongoDB PostgreSQL Pusher Go Rob Pike Linus Plan 9 beego python-cn Sinatra Tornado web.py Quixote Skala Preview Stilly 当我谈跑步时，我谈些什么 远程工作之个人效率篇 Special Guests: 刘连响 and 韩吉云.

This episode is part of our remastered greatest hits collection and features Rob Pike and Andrew Gerrand talking about the history and latest updates to the Go programming language.

This episode is part of our remastered greatest hits collection and features Rob Pike and Andrew Gerrand talking about the history and latest updates to the Go programming language.

Rob Pike discusses possible reasons why new computer languages keep appearing and why they led Google engineers to define yet another language, Go. (April 28, 2010)