CoRecursive: Coding Stories - Tech Talk: Software as a Reflection of Values With Bryan Cantrill

Episode Date: December 18, 2018

Which operating system is the best? Which programming language is the best? What text editor? Bryan Cantrill, CTO of Joyent says that is the wrong question. Languages, operating systems and communities have to make trade offs and they do that based on their values. So the right language is the one who's values align with you and your projects goals. This simple idea carries a lot of weight and I think has the potential to lift up technical discussions to a higher level of discourse. You will find it to be a helpful frame next time you need to make a technical decision. Bryan is also pretty excited about how the values of the rust community align with his values for system software. Also we cover Oberon, Clean and Simula 4, none of which I've never heard of and how IBM System/370 's Global Trace Facility doesn't hold a candle to Dtrace. Webpage for this episode Show Links: Software Values Slides The Design and Implementation of the FreeBSD Operating System Microsoft should buy github All Bryan's Talks Slack Channel for Site

Welcome to Code Recursive, where we bring you discussions with thought leaders in the world of software development. I am Adam, your host. I really value those other alternatives. I think they're extremely important in every domain in software. I think that when you make one of those idiosyncratic decisions, you are almost certainly making it for more deeply held reasons than someone who is making a safer decision. If you're deploying OpenBSD into production, there's a good reason for that. If you're using Rust, if you're using one of these things

that isn't the default choice, to me there's a greater likelihood that you've been more thoughtful about that decision, more thoughtful about the values that you have for this job, for that decision. That was Brian Cantrell, CTO of Joint. He thinks that we need to be aware of what values programming languages and open source communities have and how those values either complement or conflict with our own.

That sounds a little vague, but it's really not. Brian just wants us to think carefully about trade-offs, but I'll let him explain that. If you haven't subscribed to the podcast yet, I recommend you do so, so that new episodes will be delivered to you automatically. I've also set up a Slack channel for the podcast if you want to chat about this episode or just hang out with myself and fellow listeners, You'll find a link on the website. So Brian, I saw you give a talk where you had this super interesting idea that I hadn't heard before, that programming languages, software systems have values.

So what did you mean by that? Well, I think everything has values, right? I mean, I think that we don't really talk about it because sometimes it's so implicit. But we do the things that we do because of what we think is important. And we think different things are important at different times. And that's what causes us, in part, to make different decisions.

And I think that programming languages often have a very opinionated idea of their values, of choosing among things that are positive, but emphasizing some things more than others. And I think that's very important that programming languages do that. We talk about the right tool for the job often. What we often implicitly mean by that is finding the values of a programming language or system that match the values of the engineer and the problem at hand. And to make that more specific, I mean, you know, kind of a classic value is around performance. How important is performance relative to, say, expressiveness, or relative to, say, the speed of development, or ease of use? And these things are often intention.

And there are jobs where you're going to want to pick something that is going to be the highest performing thing at all costs. And there are jobs where you'd want to pick the thing that's going to allow someone who doesn't have previous experience in the domain to actually be able to implement successfully. And those are very unlikely to be the same thing. And so I started to get very explicit about this in terms of values and the values that platforms have and how we select among them, in part because I was trying to figure out several years ago what went wrong with respect to the Joyent and Node.js relationship. So I'm the CTO of Joyent.

Joyent was the company behind Node.js. So we hired Ryan Dahl way back in the day, 2009. Part of the reason I came to join it was because of the big bet on Node.js. And the Node.js experience, there are parts of it that were really great, but ultimately it ended somewhat in disappointment because, and trying to understand why that was,

like why did we have this kind of amicable, or sometimes not so amicable, divorce effectively with Node? Sometimes coming out of a bad breakup can be very healthy in terms of being introspective and trying to figure out where things went wrong. With respect to Node, I really think that where things went wrong for us was with our values. I think that our values were not Node's values. And Node's values really are JavaScript values. That's the other kind of realization for me. Even though I kind of had visions of Node diverging a bit from JavaScript's values and becoming dynamic server-side programming. But really, at the end of the day,

Node really is JavaScript's values. And there are great things about JavaScript's values, absolutely. But they were a poor match for our values at Joy-In. So what are JavaScript's values? JavaScript's values are allowing, really, every person on the planet to write software. It's around growth. It is around allowing everybody to develop software.

It is very broad and then understandably pretty thin. Um, because it's, it's not designed, um, to, it's not designed around rigor as a first principle. Um, I mean, it's to say that it is, it is type unsafe, um, is almost putting it too gently. I mean, it is so easy. I remember in one of your earlier episodes, your interview with Jim Blandy, he talked about his own incredulousness at the fact that you can have a typo that crashes a program. And it really is frustrating. There are times it just feels like,

boy, JavaScript, you don't have to give me this much leeway. You could actually just let me know that I'm accessing this property over here that I'm not accessing in any other way elsewhere in this program. But that would cut against JavaScript's core value of allowing for highly dynamic software. And I've been known to say in the past, and certainly I believe it, that JavaScript is the failed state of programming languages, which sounds overly pejorative. But there is no central authority in JavaScript.

I mean, yes, there's ECMAScript and so on, but no one is going to tell you that you've misspelled your variable name. And that gives you tremendous freedom, but also tremendous peril. And it makes it such that you are allowed to write many different styles of programming in JavaScript. And it's all about JavaScript accommodating your existing idioms,

your existing way of thinking. And that, in turn, is all about JavaScript growing as much as it possibly can, being used as broadly as it possibly can. Which is great. But it's not the way I want to live the rest of my life.

And in particular, it was really frustrating when that did come into tension around things like rigor, around debuggability, around observability, around safety, where we would advocate. When I say we, I mean not just we at Joyent, but we who believed strongly in, say, rigor, would be advocating one path. And those that were trying to get the language in as many hands as possible would be advocating a different, mutually contradictory path without really understanding where the other was coming from. And especially with something like rigor, no one is going to say, hey, by the way, I want to have like a sloppy language where it's really easy to get stuff wrong. And it's not like people don't believe in writing correct software. It's just that when you actually need to make a

decision where you have to choose between supporting correct software or a construct that will make it easier to write correct software and a construct that will make it easier to write correct software and a construct that will make it easier for more people to write in this language, JavaScript is going to choose the latter every single time. So you had this falling out with JavaScript. So at the opposite end of the anybody can do whatever they want, the failed state model seems like Go, where it's like you will format your code this way. It is funny, isn't it, that Go is at the opposite end, where Go then makes a bunch of decisions

for you that do feel like it's infringing the own way of expressing yourself. So yes, it's like how your code is going to be formatted. On the one hand, I like consistent style. Consistent style is important. And there's lots of reasons why a consistent style is important. On the other hand, mandating a consistent style seems it's too, it's too much. Or mandating one style is to me too much. And there are lots of things like that, which are kind of strange, autocratic decisions in Go that aren't necessarily well socialized. And often there are reasonable reasons

to not want to make that particular decision. And they kind of permeate things. So it's like, you know, if JavaScript is a failed state, Go is kind of a strangely autocratic one. And in one talk I likened, you know, going from JavaScript to Go is like going from Somalia to Turkmenistan. And actually, it's funny, someone on the internet who apparently is Turkmen and knows both Go and JavaScript got a hold of this and said that this was the most apt analogy he'd ever heard for Go. Because it does kind of capture the strangeness of some of the decisions that Go has made.

Not to take anything away from it, I mean, I think there are some people that are actually really comforted with those decisions having been made. And I mean, there's lots of things of Go that are fine or good. But it felt somewhat lateral for me from JavaScript, albeit totally differently. But it's kind of a lateral move. And again, I think that, you know, those decisions that Go makes, I think, and maybe I'm falling into this trap myself, I don't mean to be pejorative about the decisions that Go has made or the decisions that JavaScript has made, because for the values of those languages, they are the right decisions and they make sense for the community that chooses those values. And one shouldn't malign those values because that makes sense for certain jobs or certain people or certain communities at certain times. I just would stop short of saying that they make sense for all communities or all people at all times.

And for me personally, I would say both of those left me looking for something else. What values were you looking for? I'm really a C programmer at the end of the day, or I have been historically. I'm a systems programmer. I've done OS kernel development for my entire career. I like low-level systems development. I like being that layer that's close to the machine. I like abstracting the machine.

I think that there's, I haven't gotten over my kind of fixation with providing that lowest level abstraction and the total magic involved in that. And for software that's at that layer, you really have to pick performance above everything else. For those abstractions that are going to be closest to the machine, they have to yield the maximal performance of the machine. Anything that you do in that layer is machine capacity that you are taking away from the software that you're going to run. So has to be highly performing, and it has to be highly reliable.

We really expect our operating systems to work all the time, as we should. We've got a very high level of expectation for our operating systems. I grew up in an era in the 80s and 90s when operating systems were kind of garbage, honestly. I mean, the two operating systems that you had to choose from if you had a personal computer were DOS slash Windows and macOS. macOS 9, which is not – both of these operating systems didn't really use – they were not modern in the regard that they were not actually using the memory protection that the microprocessors had support for. And so as a result, an errant application

could crash the operating system. Which fortunately, we don't live in that era anymore. We don't live in an era where people have to reboot their desktop a couple times a day or where they'll run a strange program which will crash their machine. I mean, yes, it happens, but it happens nowhere near as frequently as it did happen.

But the boot was fast, though. True, true. Especially now, if you go back and actually run those, I mean, honestly, to even call them operating systems is almost an exaggeration because they provide so little. They are almost what we would call an executive. But they run now, I mean, they were relatively quick on ancient hardware.

I mean, you run them, God only knows how fast DOS would boot on a Skylake, you know. Once you actually got past the bias, I mean, the irony is that we still run firmware that dates from that DOS era. When you actually do, I mean, it's almost embarrassing that if you do boot a SkyWake system, it will take as long or longer to boot

than a similar server machine from decades ago because the firmware itself is still so knuckleheaded. But in terms of the operating system from a reliability perspective, we really do expect it to be absolutely reliable all the time. So those to me are my values. My values are I want highest performance. I want total robustness. And historically, C has been the language that provides that.

C has shared those values. And even C++ has made the wrong choices for the operating system kernel and generally for embedded development. For that lowest layer of software that runs on the hardware, we have generally not used C++. We have used strictly C. So I was kind of hoping that, not that I was ever going to write an operating system kernel in Node.js, but I did hope in 2010 that Node.js would allow us to write

better, faster, upstack system software. And it wasn't wrong in that it was a big leap forward. It was much lighter than running Java, for example. But it ultimately did leave us lacking. And the point that I found myself at not too long ago was like, all right, well, what's next? Because it's not going to be Node for me. It is not going to be, I'd already kind of decided

that it wasn't going to be Go for a variety of reasons. It was certainly not going to be Python. Again, not to malign Python. Python's great and is very important in many domains, but not in the domain that I'm in. What's it going to be?

And there wasn't a whole lot out there with, of course, the notable exception of Rust. I keep on thinking about this, writing an operating system in Node.js. What would you call it? Undefined? Oh, God. The thing is to even do that is almost an exaggeration. Because if you're writing an operating system

in a dynamic managed language, the operating system itself is that runtime that you can't see when you're writing your program. Because that's the thing that is actually doing the scheduling, is actually doing the garbage collecting, is doing the just-in-time compilation. So that's what your operating system becomes. So there wouldn't be a node operating system. What you're actually saying is you want to run V8 as an operating system. And even that would be

nightmarish for many although actually having said that in the 90s and I was at Sun in the 90s and early 2000s Java

was such a, obviously as you can imagine was such a big thing at Sun that we wanted to not only make Java operating systems, but Java-based microprocessors. And it's like, that's insane. I mean, I can understand the enthusiasm of the era, but to dope bytecode into silicon is to totally miss the point of bytecode. Makes absolutely no sense.

And those things all, I mean, they all did not succeed. Be great to have a book on all of these kind of failed experiments. Because, I mean, they do fail for somewhat interesting reasons. I mean, each failure is a little bit different. But they ultimately fail because they're trying to push something, namely Java or this high-level language, into a spot that it really does not want to be. It's not designed for, it doesn't add much value.

Yeah, I don't know a lot about firmware, but I know the people who work on it, memory allocation is very important. I don't know about a GC running on some little piece of firmware. Well, you definitely wouldn't want to have a GC. I think that when you're writing that lowest level of software, you just need to manage everything very explicitly. And to a certain degree, it's a simpler world

because it's not a distributed system. It's not sloppy. It's kind of like you've got, it's orderly in that you have a, you know what memory is mapped what it can do and what it can't do and when it can do it and when it can't do it. So when you're the operating system, you are responsible for the illusion that is memory. For memory is ultimately an illusion. Yes, it is sitting on capacitors and DIMMs, but the operating system is providing that key abstraction that allows you to actually allocate memory. And as a result, because it is the one providing that key abstraction that allows you to actually allocate memory. And as a result, because it is the one providing that abstraction, it simply cannot allocate memory dynamically

whenever it wants to. And we've got many contexts in the operating system in which you cannot allocate memory. We've got contexts in the operating system where you cannot block. And you can't block because, by the way, you're in the scheduler code actually dealing with the mechanics of blocking.

You can't obviously block in that code path because you are the software responsible for the abstraction that is to block and to yield or what have you. So in those worlds, and firmware is kind of an extreme of that where the firmware is not running software generally above it. It's not a full operating system, but it is certainly interacting directly with hardware beneath it. And as a result, it can't make arbitrary references.

It needs to be arbitrary memory references. It operates in a constrained environment, and it needs a programming language that's going to be able to abide by those constraints, which these dynamic languages aren't designed to do. I need to take it as a personal mission to learn more about, well, just about operating systems, like how they actually function.

I know I took a class on operating systems, but I feel like that was a long time ago. And yeah, there's a lot there and we kind of gloss over it, I think, day to day. You don't gloss over it, but I do. I mean, there's a mind-numbing amount there. And one of the challenges with operating systems or system software in general is it can be very hard to even see what's there.

And one of the technologies I worked on earlier in my career is something called D-Trace that allows you to dynamically instrument the system to see what it's actually doing. And even today, we use D-Trace all the time to understand what the system is doing because seemingly simple abstractions are wildly complicated. And that seems to be true all the way down. You know, there's that expression turtles all the way down. And what that is, is meant to mean is that you are standing on abstraction, that's standing on abstraction, that's standing on abstraction, that's standing on abstraction. And, you know from um when you want to actually observe all that that can be a real challenge um because you want to turn the system inside out so you can actually see what it's doing

but it is absolutely stunning how much a simple operations at so you for example if you want to open a file you know how complicated is it to open a file? It is basically of unbounded complexity to open a file. Something like DTrace allows you to actually, as a user of an operating system, follow that code flow through the whole operating system. One of the reasons we actually developed DTrace, among other things, we wanted to understand the system ourselves.

But when I took my OS course in college and TA'd it for a couple of years, I envisioned D-Trace being used as a pedagogical tool to actually teach operating systems. And it's been fun to see that get picked up, and particularly in the FreeBSD community. And the latest FreeBSD books really use DTrace a lot as a teaching tool to learn how FreeBSD is implemented. So if you're interested in operating systems, I would encourage you to check that out. George Neville Neal's latest on that, the design implementation of FreeBSD.

And where you can actually understand yourself what this thing is actually doing and appreciate its just nearly unbounded complexity. Because it seems like anything simple is much more complicated than you think it could possibly be. Yeah, I'm going to check that out. I remember Joel Spolsky uh he had this article before talking about like somebody painting a road where they would like put the

can down and then they would paint a line and then they would walk back to the can and dip the brush and how like they they slow down right because the the can is getting further and further away and he his point was that like software is rife with this where people just don't understand um they're just calling like paint line they don't understand. They're just calling paint line. They don't realize that they're walking back to the can every time. And I think that that's endemic. I think we would not want it to be any other way. I think that it's imperative that we build and utilize abstraction.

We need those abstractions. So you actually don't want someone who's opening a file to be burdened with the outrageous complexity of opening a file. of thousands of times a second or what have you. So you need to have enough reverence for the abstraction to not abuse it. And that's a tall order where we say, hey, you don't need to know how this works. But oh, by the way, you might need to know how it works when everything goes sideways. And we may have to turn this thing inside out so you can figure out why your software is not performing as well as you think it should be. That's a huge challenge and one that I think we're still grappling with. Do operating systems have values?

Do they fit in the same framework? Oh, absolutely. Absolutely, yes. Yes, perhaps more than anything. But no, operating systems have got very clear values, I think. We work on an operating system, Lumos, which is a Unix-derived operating system that traces its heritage back to OpenSolaris.

A lot of people wonder, why don't you just use Linux like the rest of the world? Or why does FreeBSD exist? Or why does OpenBSD exist? Or why does NetBSD exist? Or why can't the Mac just run Windows or the Windows just run macOS? And I feel that these different systems

actually have a very important place in that they do speak to very slightly different values. And clearly there are values that transcend all of these systems. And clearly all of these systems care about performance. Clearly all of these systems care about reliability and robustness. But the way they reflect that, they're slightly different in each system. And I think those differences should be accentuated that they're slightly different in each system. I think those differences should be accentuated.

I think it's good. I think it's important. It'd be hard to argue that OpenBSD doesn't serve an extremely important purpose, even though it's not run by that many people. OpenBSD is an operating system that picks security above all else. They will put themselves in an arbitrary amount of pain to have a secure system. And that's an important choice to have out there. And that's important because they do represent those values. As a result, they make choices that other operating systems don't make. But often the choices that OpenBSD makes are choices that other operating systems come to later when they realize that actually, while they may not choose security over all else, security actually is more important than

they necessarily realized. So it's important to have these kind of different points out there making different choices. And I don't think we want to live in a homogenous world where there is but one set of choices being made. And that means I don't want to have just one operating system. I don't want to have just one database. I don't want to have just one cloud. I don't want to have just one cloud. I don't want to have just one programming language. And maybe as a result, I am fated to be constantly doing things strangely. I know I was having a discussion with another CTO, and they're using Slack.

And I said, well, we actually don't have this particular problem you're describing because at Joint we use Mattermost. We've got our own Mattermost server. And he's like, do you guys have to do everything differently? Can't you just do one thing like the rest of the world? I'm like, yes, we're able to do it. But that said, I really value those other alternatives. I think they're extremely important in every domain in software. And I think that when you make one of those idiosyncratic decisions,

you are almost certainly making it for more deeply held reasons than someone who is making a safer decision. If you're deploying OpenBSD into production, there's a good reason for that, almost certainly. If you're using Scala where someone else would have used Java, into production, there's a good reason for that. Almost certainly. If you're using Scala where someone else would have used Java or someone else would have used Python, there's probably a good reason that you're using Scala. That's not an ill-considered decision.

If you're using Rust, if you're using one of these things that isn't the default choice, to me there's a greater likelihood that you've been more thoughtful about that decision, more thoughtful about the values that you have for this job, for that decision. You're making what is a choice that maybe is something that other people aren't as familiar with. It can be easy for others to kind of deride

that choice. And I think you've got to stay strong when you are making a choice that is a bit idiosyncratic in that regard. Well, I like that because I'm on a team that does Scala at work and not everybody does and they don't understand.

And it's also a great justification for why you're using Rust instead of C. Yeah, and I think that it's an unfortunate human attribute that when we see something that we don't understand, we often respond to that antagonistically. So I'm sure there are times when if you're, if you're in a group doing Scala and you're in a larger organization that doesn't understand

that the value that it brings, I'm sure there are times when that can feel antagonistic. And, you know, that's where I think kind of understanding these things as values can help you better explain to someone why decisions have been made or why we feel this is the right tool for the job. Because that way, you're not falling into the trap of like, look, Scala is just better than your thing. It's like, well, no, it's actually more nuanced than that. just that for this job, the values of Scala are, we feel, a better fit than the values for what might be a safer alternative. No, that's a great perspective. Because people get blind to the values they don't care about, right? They just don't even consider them. So because it's a better fit for the things I value, then it's just better. Exactly.

And they do that implicitly, which can be very frustrating. And especially when you're choosing between things that are like, everyone agrees that programmer expressiveness is good and robustness is good, but not really understanding that there are times that these things are in tension. And it can be frustrating. So yeah, I'm hoping to get people to think a little bit more about why they might want to choose or not choose certain technologies, in part to encourage people to make more different kinds of choices. I'm just a big believer in heterogeneity of systems and of thought.

So what were the values of Rust that made you go there instead of, like, it sounds like C is your default, but here you are. Yeah, and I would say C is my default. And I think that historically we've done things in kind of, you know, C when it's down stack or when it's really performance critical, Node when it's really performance critical, Node when it's upstack. And the question I had was, boy, Rust, on the surface of it,

Rust has some really compelling values. Rust is highly performing. It's memory safe, which is really interesting. And we can kind of get into how they actually yield that safety. It's really rigorous, but it's also trying to provide programmer expressiveness and allow you to develop software

quickly. That, to me, was really interesting. I wanted to check that out, basically. Would Rust be able to deliver on all these things? And in particular, would Rust be able to yield high-performing artifacts? Because if it doesn't yield high-performing artifacts,

it's not going to be applicable to the things that I would want to use it for. So I finally found something that was the, or had the kind of right time, right fit for, for something to, to merit learning Rust and dove in. I think that, you know, I've been Rust curious for a long time. I've been kind of, you know, reading the blog entries and, you know, listening to kind of experience and had heard, you know, people's experience with it. I think that I was letting myself be a bit too intimidated. I mean, Rust has got this kind of infamous learning curve. I actually don't think the learning curve of Rust is that bad at all. I think that the, and people listening may be concerned, maybe themselves in the situation, I think like, God, I just like and people listening, maybe concerned, maybe the themselves in the situation

that think like, God, I just like, I'd rust. It sounds like it's, it's just magic. Um, it really isn't, I think it does need to be learned. Um, it's not something that you're going to, you know, you don't want to simply download it and start banging away. Like that is not a, that's not going to work well. Um, but if you sit down and I, you know, I is not, that's not going to work well. But if you sit down and, you know, I really recommend you, you've obviously been interviewing Jim Blandy. I think that the Blandy book is terrific. The Rust Programming Language book is terrific.

But by Steve Babnick and Carol Cobine and Community. But you really want to sit down with a book and actually learn it. And with Jim's book, Jim and Jason's book, I did something that I haven't done for a very long time, which is they have this kind of intro chapter that has an example program that they work through. And I sat down and I typed in that example. And it was really valuable. It didn't take that long. And I was able to, the inevitable typos got me

kind of getting a feel for the compiler error messages and so on. And at the end of it, I had something that worked. I'll be at something that I had only copied. I hadn't actually thought of it myself, but it got enough of the brain working on it that it made it much easier to go and actually understand these other elements of Rust. So on the one hand, there are elements of Rust that are definitely novel. I mean, the ownership model is absolutely novel, and it's incredibly important. On the other hand, it is not nearly as arduous as it's made out to be.

To the contrary, I mean, what I see is that in many of these languages where it's super easy to get started, your day one is really fast, and that's great. But then on day 100 or day 300 or day 500, you actually have to wade in to even more complexity as you need to understand the implementation details of, say, the garbage collector to understand why your program isn't performing or why is there this 150 millisecond GC pause. It's like, well, now you need to figure out,

is it the young generation or the old generation? And, you know, which garbage collector are you using? And what's all the nuance of that garbage collector? And do you have an object graph that is large and connected errantly and all this other complexity that you now have to go deal with? In this regard, I think Rust shifts that cognitive load from that 100th day or that 300th day much more towards the first day or the second day, which on the one hand can feel overwhelming, but on the other hand, once you get it,

which doesn't really take long, I don't feel, the artifacts that you're yielding are much higher performing and with much less surprising dynamic behavior. You're not going to have the surprise 150 millisecond GC pause in Rust. You had this list of values when you did this talk. Like approachability, like screw approachability. I say that because you'll be using a programming language for so long. Maybe approachability is fine, but you shouldn't be afraid for your language to have expert-level things.

I think that's right. Yeah, I think that that's exactly right. And I actually love the sweet spot that Russ is trying to hit, which is like, look, we're not going to pick approachability over robustness. We're not going to pick approachability over robustness. We're not going to pick approachability over rigor. But that doesn't mean that we're going to make this as rigorous as it needs to be, and then let's make it as approachable as it can be. So I actually think that Rust,

in part because it's trying to, I think, fight a bit of its reputation, I think it's incredibly approachable. In particular, the compiler's error messages are amazing. And I think that especially when you make kind of early on when you are not dealing with the borrow checker, you'll get these incredibly verbose, helpful error messages out of the compiler.

And it's using ASCII art and colors to highlight exactly where your error is. And you've got to think to yourself, boy, this is like, you are really going out of your way to help me. Like, this is great. And you can just almost wonder if the compiler is like, look, I need you to hold on to those positive vibes because at some point I'm going to give you, you know, cannot move out of borrowed context. And you and I are both going to be shrugging our shoulders, trying to figure out what's going on. I think that Rust tries to make itself as approachable as it can. A term that they use a lot in the Rust community, not the first community to use this,

but they definitely use it a lot, is ergonomics. I like ergonomics. It's different than approachability because it's saying we want to make this construct comfortable. It doesn't mean that we're going to make this construct any less rigorous. And there are lots of ways in which they have and continue to make it ergonomic in ways that new programmers won't even be aware of. I mean, Rust 2018 dropped today. And one of the big changes in Rust recently is something called non-lexical lifetimes. Historically, lifetimes of an object in Rust have been lexical. And one of the big frustrations of Rust is when, or can be, with a borrow checker, a big fight with a borrow checker will happen when

you are done using something. So you are effectively done borrowing it by you looking at your code. But because it is still lexically in scope, the compiler treats it as still being borrowed. And that can be really frustrating because you want to have some way of telling the compiler, like, no, give it back. I'm done with it. I'm not using it anymore. And with non-lexical lifetimes, the compiler's a lot smarter about realizing, like, oh, I get it. Okay, you've actually used that thing for the last time. So now you can give it back. And as a result, the borrow checker just silently does the right thing.

And there is absolutely going to be a new generation of programmers that come to Rust in the next six months to a year, and they're not going to know what the fuss was about, about the borrow checker. They'll just be like, I just don't think this is that bad. It's like, well, it's not that bad in part because the compiler has gotten a lot smarter and it can tell

when ownership can transfer back because it can tell when you're done with something. So I think that's going to be a big positive change to the language. Yeah, that's awesome. I thought, I saw you on this panel and somebody was asking you, hey, why doesn't Rust have a GC? And I felt like he kind of missed the point that maybe what they're shooting towards is kind of like a static compile time GC. And right now that is. And as a result, it's the compiler trying to figure out at compile time some of these dynamic attributes.

And it does an amazing job. And that is getting better. And then as a result, you can totally reason about the performance of the system. Folks that deliver high-performing software in GC languages do exactly this. The irony is the person asking that question is Cliff Kleck, a very accomplished software engineer. Cliff would tell you, oh, I can write absolutely high-performing software

in a GC language. Okay, Cliff, how do you do it? He would talk to you about how you do it. It is all of the things that cognitively you have to do for Rust. He'll be like, oh, I'm going to pre-allocate my map. I'm going to hold on to this. I'm going to do all these kind of implicit things that basically don't generate large amounts of garbage for the GC to collect.

But he's been able to do that because he's implemented the VM a couple of times. Rust allows effectively anybody to get to those kinds of results, albeit with slightly higher cognitive overhead when you're developing in it. But again, I think it's ways that are actually intuitive. Once you understand what Rust is trying to do, the intuition around it grows really quickly. And as a C programmer, one of the things that's funny about C is that you can feel the underlying assembly

that the C wants to write. With Rust, I can feel the underlying C. I can feel what it's trying to do. Constructs like the parameterization of lifetimes makes total sense when you understand what it's trying to do. As a result, I have not really had... Yes, I had some early fights with the bar checker. There are going to be a couple of things that are going to drive you to the brink of tears early on.

But once you break through that, it becomes actually, I think, a lot simpler to write software because there are so many things that you don't have to worry about. And then the artifact is high-performing. I mean, that's the thing that's really very impressive is that I found my rust, my naive rust, was outperforming

my carefully written C. That's a big statement, really. Yeah, and it's for a bunch of reasons that are, I mean, every time I say this, people get upset that I'm making an overgeneralization. So I'm not saying, clearly, it is not the case that every Rust program is going to outperform every C program, or, it is not the case that every Rust program is going to outperform every C program, or even that for the same task, a Rust program is going to outperform

a C program. What I found, though, is that it is easier to deliver very high-performing software in Rust than it is in C for a variety of reasons, but not least the fact that the strength of the ownership model allows Rust to be truly composable. So you can use much more powerful data structures. And in particular, the reason my particular program was faster for Rust than it was for C is because the default balanced binary tree implementation for Rust is not a red-black tree or an ABL tree, but it's a B-tree.

And a B-tree is a much more sophisticated data structure historically used in databases. But the Rust observation is, one, a B-tree actually makes sense in an all-memory system because the memory hierarchy is so spread out. And two, the composability of Rust actually allows for a B-tree to be implemented. A B-tree is so spread out. And two, the composability of Rust actually allows for a B-tree to be implemented. A B-tree is gnarly.

It is hard to implement a B-tree in a way that's composable, in a way that doesn't allocate auxiliary memory, which is the reason we've always used AVL trees in the kernel. But to be able to use a B-tree instead, and it's delivering a

higher-performing artifact is pretty compelling. So on the one hand, yes, B-trees are higher-performing than AVL trees. On the other hand, I could not practically use a B-tree for my C implementation. And not only can I for my Rust implementation, it's the only choice to make, because it's the balanced

binary tree for the default collections. Unless you say something more controversial, we'll just call this one, Naive Rust is faster than C. That'll be the podcast name. That'd be great. It'd certainly get some attention. You know what's funny? I had a blog entry on this.

I discovered that my Rust is up forming my C, and I had pledged to go investigate it more deeply. Then I had a follow-up blog entry where I investigated it pretty deeply with an extremely long disclaimer about how I was not trying to make gross comparisons, how I was really making a specific comparison. Still, people are like, God, how can this guy make such a ridiculous statement?

I'm like, I'm really not. I'm like, can you not read the eight paragraphs of disclaimer? How much more disclaimer do you want me to provide? But I think despite the disclaimer, one has to acknowledge that yes, it was easier to develop a higher-performing artifact at Rust for this particular problem. I think I had this guest, Stephanie Wyrick, who works on Haskell, and she was saying something to the effect,

when you give the compiler more information, in theory it can do more optimizations. So Rust just knows more, I assume, is one of the advantages. I think that's an advantage that they are not even fully appreciating yet. In terms of the Rust compiler folks, I appreciate that those and that's an advantage that they are not even fully appreciating yet. I mean, in terms of like the Rust compiler folks appreciate that those advantages are possible, but they have not yet begun to really deliver on that stuff. That is true. In fact, actually, when I first looked at it, I'm like, oh, okay,

this is because Rust is able to actually do true memory disambiguation. So one of the problems you have in C is that the second you call any external function in a file, C has no idea what that function is touching and not touching. This is called memory disambiguation, to disambiguate what memory is referring to what. And because C is fundamentally unsafe in its construct, it can't reasonably, I mean, compilers have tried to do memory disambiguation,

but it's really hard to do because the language doesn't help you at all. Rust is able to do that really cleanly and crisply. And I think it can yield even much better performance than they're getting now by leveraging that more deeply because it's my understanding

that they're not doing a whole lot of what they could potentially be doing in the future and I think this is a domain where there's going to be a lot of really interesting work and as a result, you're just going to see your extant Rust code getting faster and faster

over time as the compiler gets smarter and smarter. And smarter and smarter in a way that is not really in tension with Rust's other goals. One of the problems with C is that there are certain levels of optimization that the compiler can't reasonably apply because they actually will result in a slower artifact in a bunch of other cases. And I say this not as a compiler optimization person, so cut me some slack, but my intuition is that there will be fewer cases like that with Rust. There will be more cases of unequivocal optimization

that can be had because the compiler just knows so much more about what is going on because you the programmer have agreed to this grand bargain where you're going to work with the compiler to generate a higher performing artifact which is a terrific bargain. Yeah. The thing, first of all, I also know nothing about compilers. So before I state anything, the problem is sometimes I think compilers get sufficiently smart. Your model is going to break down that you were talking about before. Do you understand the C it's going to write?

That will change if it's able to do smarter things, right? And this is where C can get too smart for its own good, where it can do, say, memory disambiguation that then makes a system that was safe becomes unsafe because the system was implicitly relying on the compiler's inability to perform that optimization. And we've actually got a lot of code like that in the operating system kernel.

So yeah, that is an example where the optimization breaks the model and yields an artifact that doesn't... And if you look at... It's always interesting to take a C compiler and look at its minus 0.5 optimizations. And those almost certainly have warnings associated with them

about their limited applicability where they can result in slower code if they're used more broadly. Yeah, I'm thinking of a specific example that I'm going to get totally wrong. But somebody on Stack Overflow talking about this Haskell Fibonacci program that was running much faster than the C program.

And then when it was looked into in depth, the Haskell compiler had just realized that the Fibonacci was only evaluated once and had just compiled time and calculated it, right? Right. That's great. And yeah, I mean, that's the kind of freedom that Rust is afforded by

the programmer having shifted that cognitive load is that we can, in principle, see some of those opportunities. And i i think we're gonna the other thing actually that got that i love about rusk though you know the couple things we just don't talk about frequently enough um i love the all the explicitness around mutability which obviously c has as well in terms of cons and so on but there are so many ways out of it you can can just cast away the cons. So like, what's the point? Whereas in Rust, you can't cast it away, right? If something is mutable or it's not,

and if it's not mutable, like you can't mutate it. You can't just magically make it mutable. If it's mutable, they can only have one owner and so on. But that is going to afford, I think, a lot of opportunity that you read hasn't already, a lot of opportunity for optimization as well, because it knows that there's going to be no store to this because it's not mutable. And that in turn allows values to be cached and so on.

And I think there's just going to be a lot of opportunity. Rust is already performing really well. And because those values are so crisp in the community, I think we're going to see it perform even better over time. And no null pointers. That too. Yeah, and it's funny because that is probably a bigger deal. That is the big deal with Rust. That's huge and it's great. I think especially if you're coming from C++, that is a huge win. It is a huge win. I think especially if you're coming from C++, that is a huge win.

It is a huge win. I don't mean to minimize the memory safety. From my perspective, I'm able to write safe C from a memory access perspective. So the safety is great. I'll definitely take it. It's nice. But it's not as big of a win. But I think for most people, it's actually the bigger win. For me, actually, the safety that we don't talk about as much with Rust is integer safety and overflow safety. So Rust is persnickety about overflow, which is actually great. It's one of these things where the Rust compiler will be giving you a hard time about something. You're like, oh, come on, Rust. Just lighten up already.

And then you look at it, you're like, actually, there is actual potential overflow here. So, okay, thank you, Rust. And there are lots of points around sign extension safety, around overflow safety, that rust um which are i mean i can write memory safe c i say that with with pretty high confidence um although it's much easier in rust for sure and i would prefer rust because writing memory safe c does induce cognitive load. Writing integer safe C is actually really hard.

And the kind of the worst bugs that I have had in my production code have been because of overflow that can then be exploited. So the overflow, the

integer unsafety then tacks into the memory unsafety in that the malicious code will induce integer overflow that will then allow a guard to be snuck past. And then you leverage the memory unsafety to either corrupt memory or utilize a gadget or what have you, and now you've got an exploit. And so with Rust, it's the integer safety plus the memory safety that yield that more secure artifact. Something we haven't spoken about here at all, but it's another huge factor in Rust. And for any internet-facing code, I would absolutely write it Rust first

because it makes it so much harder to generate some of these kind of common pathologies. I think that certain... We were talking about programming language values, and there's trade-offs between all of them. But I think sometimes there's things that once they get hit on, once they take off, then they'll become table stakes for future languages. So I think that null, we should just get rid of null. I think we've had a couple languages that don't have null.

No new language should have null, I'm calling it. Yeah, I think you're probably right. I think that in that, if you want that, C is always going to be your answer. And there is going to be, to be clear, there's still going to be a place for C in the universe. And, you know, C having a sentinel value that denotes unmapped memory is, you know, I know it's been called the $8 trillion mistake or whatever. I don't quite buy it. But because you have to have some way of indicating that this points to nothing, that this points to void effectively. And if we weren't dying on null pointers, we'd be dying because we're referencing void. So I mean, to me, it's kind of six and one half dozen the other.

Yeah, but can we just use like, you know, we just use like a sum type. Like we have to. Oh, totally. Yeah, absolutely. And I think that you, I mean, an algebraic type obviously solves that. And I do feel that like, yes, for new languages, we need to be done with sentinel values. There is no reason to have a sentinel value. That should be an algebraic type.

I'm totally with you. And then it's interesting to think, what else could be something that could be new table stakes, right? So this kind of borrow checker, will there be other languages that take this approach? Yes, absolutely, no question in my mind. And to me, as not a PL person,

the whole ownership model, I think is relatively novel with Rust. Because for most languages, they develop something that is kind of putatively novel. And then any PL person would be like, oh, no, no, no, like that was done, like that was that ages ago.

That was, you know, Simula did that or Oberon did that or Modula 4 did that. Some language, some unverifiable claim. And actually, I did the, when working on D-Trace back in the day, D-Trace actually did advance the state of the art in terms of dynamic instrumentation of systems. And knowing that I was going to get some grief

from main framers, I educated myself to a great degree about the tracing facilities that existed on effectively every system I could get my hands on. And indeed, some folks said, well, Detroit's interesting, but actually I had this facility on OS 370 I'm like, what are we talking about, GTF?

Because we're talking about GTF, let's go it's on, GTF is the generic trace facility and it's a tracing facility on the mainframe but it is not what DTrace does, it's not dynamic instrumentation and if you want to throw down over GTF, let's roll and inevitably the claims would kind of disappear It's not dynamic instrumentation. And if you want to like throw down over GTF, let's roll.

And inevitably, like the claims would kind of disappear. So, you know, there's this kind of thing to, to ascribe, like, well, Multics did this, or, you know, Simulink did this, what have you. With the ownership model, I, to me, it does seem that it's pretty novel. Steve, Steve Gladwick informs me that it actually does trace its roots back to clean, which is a language apparently. So there's a language called clean. It's been around since the 80s. So maybe clean is the pioneer of the affine types or the ownership model.

But certainly it has not been used in a broadly used language. Um, in that regard, Rust absolutely represents a, a step forward to the state of the art and there will absolutely be Rust derived and there should be Rust derived languages or Rust inspired languages or languages that have, um, mean one of the things i thought i mean my god can we please get rid of bash um bash is humanity's dirtiest secret right now as far as i'm concerned that the the amount of software load-bearing software that we have written in bash um in part because no programming language, well, it's a new programming language, Bash makes it very, very easy to string together

the output of different Unix commands. It's approachability again. That's total approachability. Approachability wins, but in a horrible way. A horrible way. A horrible way. And, God, there is so much lethal bash out there. I mean, you can almost pull up any bash script

and find subtle bugs in it. And can we please get a Rust ethos coupled with bash approachability in some new language that is wholly designed around executing other programs and stringing their output together rigorously and then handling those failures rigorously. It just feels to me like there's a real place for that. That could be me.

I mean, Excel. I think that there is a large amount of the world that runs on Excel that nobody talks about. That's just another sad fact. Like VB scripts, there's large, I'm sure that there are large hedge funds that are just some Excel book with giant formulas, millions of dollars trading in and out per second tied to some Excel. Oh, I mean, how many people's payroll depends on Excel

in some way, shape, or form? I mean, I'm sure it's very load-bearing and perhaps less load-bearing than it was historically. But that's another example where we could really use a lot more rigor. And I think that we're going to see Rust-inspired language. I think that the big statement that Rust has made is like, hey, you don't have to choose between some of these things. Especially as the ownership model gets fleshed out from the perspective of implementation. Especially as people then wrap their heads around it cognitively. Part of the reason that Rust is a bigger cognitive lift is because it is the first language

to really use this and really have this. You do have to wrap your brain around it, but once you do, it opens up new vistas. So I think there are going to be other languages that adopt a similar model. And as you say, no more null pointers would be great. So preparing for this interview, I went onto YouTube and I watched a whole bunch of your talks. That can be dangerous.

I know, it can totally be dangerous. I'm just going to throw out some questions that have nothing to do with what we're talking about and see how it goes. Sure, absolutely. Should I invest in the stock market in either Oracle or Uber? What would be your preference? Oh boy. preference oh boy uh yeah i i mean okay so look i have been saying for a long time that uber is going to be the poster child of the coming bust um and i think that uber has and i think we're seeing this with just that the business model um there is zero barrier to entry.

There is not much network effect. There is perfect rider competition and perfect driver competition. So I think Uber has really disrupted, obviously, livery, as has Lyft. But it's not clear if they themselves can endure being disrupted by the next wave. And Uber's doing a lot of crazy things that have got nothing to do with that kind of core business. So yeah, I will not be an investor in the Uber IPO, suffice it to say. Now, I will say that I have, and I've learned this about myself many times over,

I am often right on trajectory, and I am often wrong on timing. So for all I know, the Uber IPO will be some barn burner. I thought that Bitcoin was unsafe at any speed in 2009. And if I could only have been like, okay, look, fine, Bitcoin is on safe space. Why don't you just take 100 bucks and put that in the Bitcoin in 2009, which is when I first heard about it. If I had bought $100 of the Bitcoin in 2009, you know, but the thing is, like,

I would have sold it when it was worth $200. I, you know, I would be fooling myself to say that I would have held on until exactly the peak because I don't think cryptocurrency makes sense as a means of exchange or as a store of value. And then you're actually asking about Oracle. I'm including Oracle. My opinions of Oracle, I guess, are well known, but I think that they are on a very dated model and I would say a lot of headwinds for Oracle.

So I'm going to be an investor in neither Uber nor Oracle nor cryptocurrency. I'm not sure what that leaves, I guess. It leaves Amazon. It leaves Amazon. Oh my God, they are so dominant. It almost takes your breath away because they are so at re-invent.

They are still executing with such drive and focus. It's like someone is chasing them. And yet I think they're just putting more and more distance between them and the other infrastructure providers. And I say this speaking as an infrastructure provider that's putatively competing with Amazon. I mean, they are a really tough company to compete against. It's pretty stunning.

And I don't know what the future holds in that regard. I mean, I've been saying that I believe, heart of hearts, I still do believe this, that we are not going to be renting our compute from Jeff Bezos. I believe that not all of us are going to rent all of our compute. But with every re-invent, I doubt that just a little bit. Maybe, you know what, screw it. We all are going to rent our compute from Jeff Bezos. We should say, you know what, give it up. We're going to, compute is going to be re-prioritized. You're not going to be able to buy your own microprocessor. The only person who's going to be able to buy DRAM

is actually Jeff Bezos for the Hive Cloud, which is what you're going to run everything on. And let's just all give up. Have you read the Everything Store book? I haven't. Have you read it? It's super good. He's not to be messed with. You get the perspective, he's like a true poker player that will crush another company.

He is the ultra apex predator of capitalism. He is a super predator. And I think that, in fact, the only thing that gives me true hope and solace for the future is he is of such a voracious appetite that there is, there is no capitalist enterprise that he's going to view as off limits. And as he begins to compete with all of humanity, I think that there's going to be some sort of backlash at some point. Because he, no, it's stunning. I mean, there is just, the ambition seems to know no end. But it's ambition that is, unlike, you know, Elon Musk ambition that, you know, Elon said that

there's a 70% chance he's going to die on Mars, which is a very strange way of phrasing it. The ambition from Bezos seems to be backed by incredible execution. Also, I think they just announced an AWS blockchain thing at reInvent. Yeah, the crypto blockchain one doesn't make sense because it's distributed but only within AWS data center.

I'm not clear if it sounds made up. It sounds April Fool's-y. It does sound April Fool's-y. I mean, God, that would be a great reinvent, wouldn't it? Where they announce all this stuff at the end. They're like, you know what? God, we were actually fucking with you that whole time. I can't believe you guys bought all that stuff.

Like AWS outposts, come on. We're not going to let you run. And the blockchain stuff, you guys you that whole time. I can't believe you guys bought all that stuff. Like AWS Outpost, come on. We're not going to let you run that. And the blockchain stuff, you guys ate that one up. Like there was no detail there. Yeah, maybe they are going to like, they'll prank us. Certainly we would all fall for it. I'm just going to hit you up with random tech questions now.

You bet. Should we be trusting Microsoft now since they're like.NET's open source and all this great stuff? Yeah, it is a newer, different, I would almost say a kinder, gentler Microsoft. It is shocking, especially given where Microsoft was, certainly in the 90s, where it was so, I mean, not just homogenous, but I think so oppressive with respect to other ways of thinking. So proprietary. So devious in so many ways.

I mean, the findings of fact from the Netflix case really merit a reread. There are so many underhanded techniques that Microsoft was engaged in. And yet, here we are, they really have changed, I think, pretty fundamentally. They've always had the cash to go do some really interesting things. And they're kind of making all the right moves. I mean, when Sasha became

the CEO, what, three years ago, I jokingly said that, oh yeah, here's what he needs to do. He needs to open source.NET, he needs to open source Windows, and he needs to buy GitHub. And that was a joke, okay? Like that was a joke. I really want to emphasize that the buying of GitHub especially was meant for humor value. I didn't think that they would actually do it. And people would be like, do you think they would actually buy GitHub? I'm like, I think they should. And wow, they did.

So Microsoft, I think, is kind of getting back to... Microsoft at root is not a monopolist. Microsoft at root is not a monopolist. Microsoft at root is a developer tools company. That is what Gates famously wrote, the basic interpreter on the plane or what have you. Ultimately, they are, I think, they're kind of the base DNA. They understand the way the developer wants to develop software. And they then later incarcerated themselves onto this Windows monopoly.

And Windows was kind of crappy because they're not an OS company. That's not who they are, what they're about. And so Windows was always kind of not very good. It was certainly before they pulled in the DEC VMS folks, it was terrible. And then Windows NT was better, obviously. It became better as time went on and is probably fine now.

But very interesting to see them really embrace Unix, and not in their classic embrace, extend, extinguish, but actually truly embrace it. It's a different company. I would still stop short of really embracing any Microsoft technology myself, but that's really because

of my own bigotry and my own resentment over Bill Gates having robbed me of my childhood by forcing me to use DOS when Unix was actually available. I'm not sure that's his fault, is it? I blame him personally. Look, I think it's great that we're curing tuberculosis and we're kind of opening up schools and I honor the philanthropy, but let us not forget that underneath that, there actually is the Bill Gates that forced us all to run DOS and wrote very snippy letters to anyone copying his basic

interpreter. But actually, that's being unfair because Microsoft really is, I think, changing into a wholly different company and one that is much better positioned for the future. I mean, Satya's just done an incredible job. And I think it will be, business schools will read about Satya's work at Microsoft as one of the great turnarounds, I think. A great cultural turnaround. Really, really very impressive. I think that's all my random questions.

Oh, how about this? GPL, good or bad? You know, it's interesting because we are in a new era for open source in that we are so firmly in the open source era that there is now a desire among those who created these open source artifacts to reproprietorize them. Because the thing about the GPL is that it doesn't say anything about taking the software and running it as a proprietary service,

which is what Amazon is doing. And so people tried to address this with the AGPL, which is really not good news. And in general, they have tried to do this in by asserting rights that the copyright holder doesn't generally have. Like if I'm going to make something open source, I really don't get to tell you how to run it. And you get to kind of run it however you want to run it. And if you want to run it and charge people to use the thing that is the service that results from it, that's going to be what it is. And I don't really have a way of extending you

the right to use this without the right to resell that. I think a cert's rights the copyright holder doesn't have. And I think the big issue right now is not the GPL versus BSD versus the Apache license. bsd versus the apache license unfortunately i think the apache public license is winning out it's a better license the gpl um or i i'm a big fan of the mpl as well but i think in the the real heat now is moving to this kind of nutty trend um around around the Commons license, the Common Source,

where the idea is that we are going to have the, there's some open core, effectively, that everyone can use, but there are proprietary bits that if you want to resell this as a service, you're going to have to pay me.

And I think that it's been misnamed, first of all. But I think that this is going to be a trend that is going to not blossom into something larger, because I think it's so antithetical to open source. I think open source is here to stay. And that means that, yes, Amazon is going to be able to make that software into a proprietary service. And if you don't want Amazon to do that, you shouldn't open source it. I don't think there's going to be a middle ground there. Because it seems like a good idea,

especially when you think about Amazon, right? When you're like, hey, we built this. We should be the ones who can decide, who can charge to run it. I don't know. It is. It is. And this is what the, I mean, I guess it feels right, but it is actually, that's actually perilous. And this is what the Commons clause is trying to do, but it, but it, um, it, it feels like you, you should be able to say that, but if you can say that, then what's to prevent you from saying, Hey, um, okay, so this can be used. Um, you know, uh,

this can be used only in the U S you can't use this in Canada because I, you know, I've decided that, you know, I, I have got something against Canadians or this can be used, you know, in this industry, but it can't be used in that industry. So, you know, I'm going to be, you know, I'm a, I'm a bank and I'm going to open source the software, but you can't use it for financial services. Yeah. It's like, you kind of can't do that. I mean, there's a very good chance that you just like flat out can't do that because that's like saying, here's this book and you can buy this book,

but you can't read it on a train. You can only read it on a plane. It's like, well, it's actually my book. And if you, when I buy the book, I get to read it on a train or on a plane and I can put it next to, on my bookshelf, I can put it next to, on my bookshelf, I can put it next to an author that you disagree with or not. What I can't do is I can't make a, I'm limited in terms of what I can do about a derived work from that book. But if you've given me a license that tells me I can make a derived work from it, I don't understand how they're going to be limited in terms of how that derived work can be used. So I think it's going to be a real challenge. It's tricky because in the cloud world, everything runs in AWS. So it seems like we should be heading

towards more and more proprietary software, just offered by the cloud providers. Right. That is the world that I don't think we want to go towards. And I think that it's going to be very interesting to see how all this shakes out because I don't think we want to be in a reproprietized world.

I think it's happening though, isn't it? It's happening to a degree. It's hard to know how much it's happening because AWS gives us no real insight into what's making what. We don't know how high margin some of these services are. I don't think that there are services based on open source software at AWS

that are throwing off Oracle-like margins. That could be wrong. I don't know. Maybe that's wrong. I think if those services do exist, there's clearly not much barrier to entry for another cloud provider to do that or someone else on AWS to do that. So I got to believe that the economics will ultimately keep everything in check.

And I also think that people don't want to have vendor lock-ins. So one of the things we certainly see is that there was a time when people were building on every AWS service they could find and now

they're restricting themselves to those kind of core infrastructure services because they actually do want to be future-proofed and do want the ability to move on to a different cloud. So yes, S3 and yes, EC2 and EBS, what have you, and ELP,

but not trying to build something that depends on SQS or something that depends on Kinesis or something that depends on Redshift or something that depends on some of these other services. What is their blockchain thing even called? It's called blockchain on AWS, which is not a very distinctive name. Blockchain? Oh, God.

I mean, man, this is turning into Microsoft from the 90s. That was the interview. I feel like I could have had interesting conversations with Brian for the whole afternoon. So hopefully you didn't mind that this episode is a bit long. Usually I don't ask people about random tech news, but let me know what you think. Too long, not long enough? Let me know. I'd like to thank the many people who recommended the show

or the last episode, the little typer on Twitter, on Reddit, or wherever else. Special shout out to Rich seymour on twitter cryo and neefreet on reddit there's also some great discussion about the book happening on the slack channel channel is brand new there are multiple tens of us on there at this point um hey rutvick graph bloodwurst and john are the most active members at the moment but it's been great uh chatting with everybody who's on there until next time