02:52 - David Herman Introduction

03:50 - The Rust Programming Language

06:31 - “Systems Programming Without Fear”

07:38 - High vs Low-level Programming Languages

11:44 - Stack vs Heap Memory 

16:52 - The Core of Rust

24:23 - Segmentation Fault (Seg Faults)

27:51 - How much should programmers care about programming languages? 

32:43 - Concurrency and Multithreaded Programming

35:06 - Rust vs Go

37:58 - servo

40:27 - asm.js

42:19 - Cool Apps Built with Rust

45:04 - What hardware architectures does the Rust target?

45:46 - Learning Rust

Picks

Software Engineering Radio (Dave)
How Will You Measure Your Life? by Clayton M. Christensen (Dave)
The Presidents of the United States of America (Dave)
Design Patterns in C (AJ)
Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ)
The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ)
Firefox Fame Phone (AJ)
iTunes U CS106A (Programming Methodology) (Aimee)
Valerian Root on Etsy (Aimee)
The Dear Hunter - Live (Jamison)
Designing Data-Intensive Applications by Martin Kleppmann (Jamison)
Fogus: Perlis Languages (Jamison)
Galactic Civilizations III (Joe)
Visual Studio Code (Joe)
Tessel 2 (Dave)
Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave)
Plush Hello Kitty Doll (Dave)

Special Guest: David Herman.

 

That’s crazy. She’s a person now

Hello everybody and welcome to episode 161 of the JavaScript Jabber. Today on our panel we have Jamison Dance.

Hello, friends

Dave Smith.

Ahoy.

Aimee Knight.

Hello.

And the ever-purple AJ O’Neal.

Yo, yo… hey, I’m actually not wearing purple today. I normally do wear purple on… [Gasps] it’s not a Tuesday. Coming at you live from a sunny afternoon, Thursday.

I’m Joe Eames, your host. And today we have a very special guest returning after a far too long two-year absence, the fantastic and amazing Dave Herman.

Hello.

Dave, could you give us a brief introduction and maybe mention the last episode you were on as well?

See, I did two episodes. So, I think the last one was the one on compilers and parsers and ASTs. And the one before that was on my book, ‘Effective JavaScript’. Or possibly vice versa. I can’t remember which came first.

A book that every JavaScript developer should own and read.

Thank you very much for the endorsement. So yeah, my… let’s see. I’ll tell you about me. I wrote ‘Effective JavaScript’. I’ve worked for a long time on JavaScript standardization. I’m on the delightfully named TC39, the standards organization that standardizes JavaScript. I also work for Mozilla where my group, Mozilla Research, does investigations into the web platform. So, we do a lot of different projects where we’re trying to push web technology forward. And that’s me.

Awesome. So, today we are going to be talking about Rust. So tell us, Mr. Herman, why is it that we have you on the show to talk about Rust?

Yeah, that’s a great question. It’s not called Rust Jabber. But I think there are a number of reasons why people who are interested in JavaScript and web technology might be interested in Rust in particular. So…

You should define what Rust is first.

I will do that, yes.

Awesome.

So, Rust is a new open source programming language. In fact, we’re recording on a Thursday and tomorrow, based on our recording date, tomorrow is the official release of Rust 1.0. By the time this podcast actually comes out, Rust will be an official thing. So, Rust is what you would call a systems language. And nobody knows exactly how to define a systems language. But I think the easiest way to think about it is whatever C and C++ are, that’s what a systems language is. Or another way of putting it is wherever you could go with C and C++, you could go with Rust.

So, why would a JavaScript programmer have any interest in this? Well, I think the reason why, is really that Rust has something unique to offer that languages in that space have never had before. And that is a degree of safety that languages like C and C++ have never had. So, there are just some things that make doing systems programming terrifying that are just gone in Rust. In particular you can’t have seg faults if you write Rust code. That may sound like a small thing but it’s actually pretty huge.

So for me personally, my background is mostly on higher level languages like JavaScript and even some kooky academic languages like Lisp and Scheme. And like a lot of people, I did some C and C++ in school and I sort of did it for fun. But I would never trust myself to ship C++ code in production.

In fact there was one time where I actually foolishly enough tried to ship some C++ code in production in Mozilla’s codebase. And it had to be backed out in a panic because it was massively unsafe and it would have caused crashes and security exploits. And it would have destroyed Firefox. I actually learned the hard way that it’s pretty scary to try to ship code in a language like C++ unless you consider yourself a real expert. So, the cool thing about Rust is that you don’t have to have that level of expertise before you can feel comfortable shipping code. So, you might think of it as systems programming without fear.

Another amazing thing is that Rust has a lot of features and conveniences that almost make it feel like a high-level language despite the fact that you’re doing things like manual memory management that you do in C++. And Rust has a lot of abstractions that make it not feel like manual memory management anymore.

So, ‘systems programming without fear’. Is that the…

Title of the next book?

T-shirt that says that?

Yeah, or there’s a superhero standing on the edge of a cliff triumphantly?

[Laughs] Yeah, we…

It sounds so epic.

We experimented with different slogans. And I should say, I keep saying ‘we’. I’m not actually a member of the core team. My role is as more of an adviser to the team. I’ve been there all along but I’m not driving the decision making. I’m more there to help the team with their decision making process, with their growth path, just trying to be a resource for them. So, when I say ‘we’ I don’t actually mean that I’m there doing the design or anything like that. And in fact, I’m actually not really an expert [chuckles] at Rust programming. I’ve just recently started writing my first modern Rust library. I’m writing a JavaScript parser, which we’ve talked about before, as my first Rust project.

Systems programming without fear, not the slogan that we’ve been using. We’ve been using slogans like ‘low-level control and high-level safety’ or ‘high-level convenience’, because Rust really combines those two unique aspects low-level programming languages and high-level programming languages in a way that’s unique.

Can you talk about the difference between a high-level programming language and a low-level programming language?

Good question. [Chuckles]

Yeah, yeah. They’re very vague terms and you’re right to ask. And I don’t think there’s a perfect or precise answer. But there are just certain things that you don’t ever expect to have to do in a highlevel language and that you do expect to be part of your responsibility as the programmer in a lowlevel language.

The single biggest thing is garbage collection. In a high-level language when you allocate a data structure, whether it’s via ‘new’ in JavaScript or just an object literal or an array literal, behind the scenes that actually has to allocate some memory on the device that the program is running on. And that device has a finite amount of memory available. So, as the program is going along, it has to figure out, well, all of these things that have been allocated, some of them might not be needed anymore. So, let’s go ahead and de-allocate them and be able to reuse that space on the device. And a garbage collector is just sitting there behind the scenes in a language like JavaScript, in most high-level languages, to just do that for you automatically. So, you simply don’t think about deallocation in a high-level language.

In a low-level language like C++ that’s considered part of your responsibility as a programmer. And there are a lot of abstractions you can use to make that more convenient. But there’s no way that the language can guarantee that you'll do it safely. And in particular, what that means is that there are programmer bugs. We all know every program has bugs. But there are bugs that can cause your program to actually completely crash and burn in a completely unrecoverable way. What’s even worse, in some settings those bugs can actually be exploited by hackers to create security vulnerabilities. So, that’s generally referred to as memory safety.

So typically, a high-level language will be memory-safe because it just does that stuff for you automatically. And a low-level language will be memory-unsafe. What’s unique about Rust is that it gives you control over memory allocation the way you do in a low-level language. But it does it in a safe way. It still has that memory safety that you get in a high-level language.

If low-level languages are so dangerous, what’s the advantage of them?

The primary advantage is performance and in particular control over performance. When you’ve got this garbage collector running behind your back, it’s making decisions for you about memory allocation patterns and about when to run. And that can affect the performance of your application. And for a lot of cases, I am a high-level languages programmer and I will happily say for a lot of cases, that’s just fine. You don’t need that level of control over performance. But there are times when you do. And there are whole classes of programs where you do need that extra control over performance.

So often, when people are doing really close-to-the-metal sorts of programs like operating systems or in applications where they really care about the moment-to-moment latency like very highperformance games, they often do a lot of tricks to try to get performance where they want it to. And so, sometimes having that extra infrastructure doing things on your behalf ends up making it harder for you to control the performance characteristics of your program.

That alone might not sound super compelling because it’s like, “Well, when am I going to write an operating system kernel?” But there are just places that you can go with Rust where, or with C and C++ similarly but without the guarantees of Rust, that you just can’t go with a high-level language like JavaScript. So, things like embedding into an existing framework or an existing language.

So for example, the Tilde startup in Portland has their Skylight Ruby on Rails performance monitor. And they wanted that performance monitor to be high reliability, low latency. But it had to run within Ruby. And it’s much, much harder to embed inside of Ruby. Or the whole hardware hacking space. So, if you can get yourself a Raspberry Pi and being able to have that complete control over the hardware that you can get in a language like C means that there are just some things that you can do that you can’t do with a high-level language.

So, I was wondering too if we could maybe go over some more basic concepts. I am somewhat new to programming and I know that some of the listeners are as well. So, I guess if you’re not new, this is a great review. But as I was reading about Rust getting ready for the episode this week, I read a lot about stack versus heap memory and then segmentation faults like you said. Can you go over the difference between stack and heap memory? And then also segmentation fault for people who maybe don’t know?

Absolutely.

If you answer this correctly, you will get the job offer by the way.

Oh, I am probably going to fail on this whole thing. But if you’re going to fail, do it in public. So, stack versus heap is actually I think one of the things that makes it exciting and fun to go from JavaScript programmer or a programmer in a high-level language to Rust because it’s a concept that you just don’t think about most of the time in these languages. And so, I think Rust is a nice language to start to learn some of these concepts. Luckily you don’t really have to learn the concept of segmentation fault since you’re just guaranteed not to get them.

But the idea of stack versus heap is when you’re running your program you’re going along and you’re calling some functions. And then when those functions return you have more stuff that you’re going to do. So, if I call the function foo and foo’s doing some work and then it needs to call bar, well foo needs to remember what it was doing when it went off to ask bar to do its work. And so, bar is going to come back when it’s done and then foo’s going to continue where it left off. So, the computer needs to keep some [scratch] space about what it was doing when it paused in the middle of doing foo and went off to doing bar. And so, the stack is an area of memory.

And this is the typical way that most programming languages are implemented where there’ll be some space reserved in a stack like fashion where you’re doing foo and it keeps its local memory in one little piece of area that you can think of as a single entry on that stack. And then when it goes into doing bar, it’ll push another entry onto the stack about what it’s doing on bar. And bar might call baz and baz might call quirks. And it can keep on going and that stack can get bigger and bigger. And each time a function returns it pops off the work that it was doing on the stack. So, the stack is like a little local scratch space for functions to keep track of the work that they’re doing. And that follows the same order of operations that you’re doing the function calls in.

The heap is a place that’s more unpredictable. It’s like when you just dynamically allocate a data structure and you don’t know how long that data structure is going to be around. It just sits there living on in heap. But in a language like JavaScript you don’t really have control over what ends up on the stack and what ends up on the heap. That’s just completely up to the implementation of the language to decide when it’s going to store things on the stack and when it’s going to store things on the heap. This is another one of those distinctions between high-level and low-level programming, that in low-level languages the stack is seen as something that’s more directly under the control of the programmer.

And so, in Rust you actually have a very clear contract with the language where you know when you allocate a piece of memory whether it lives in that stack space or whether it lives in the heap space. And that gives you a lot more control over things like how long a data structure is going to live and when it’s going to be de-allocated. It also gives you control over locality which is a really low-level concept. It corresponds to where in the hardware things are actually being stored. And there’s a lot of benefits in modern hardware to having data that’s going to be accessed near each other in time actually exist in a similar place in the hardware. So, the stack gives you improved performance that way.

Then it also leads to some really cool programming patterns that are very popular in C++ because you have control over the stack. And they’re not as popular in high-level languages because you don’t have that control. So, there’s this whole idiom in C++ called RAII which is the worst-named concept ever.

Yeah.

That’s Resource Acquisition Is Initialization. And basically none of those words correspond to the intuition. [Chuckles]

But it’s basically because the stack follows a very predictable ordering, it means that when you have stuff going on in your program that you want to have in a particular ordering, you can leverage the stack to be sure that things are going to happen in the order that you want. And that allows you to do a whole lot of memory management that feels almost as automatic as garbage collection. So, that’s one of the central tricks in Rust that makes it feel like a high-level language but where you still get the predictability of exactly when things are happening.

So, you’re saying that Rust does indeed have garbage collection?

No. So, at some point we do intend to have a garbage collector. But at this point with Rust 1.0 there is no garbage collector in the language. So, basically all of the memory management is under your control. It’s just that there’s a lot of abstractions particularly tied into this RAII idiom that mean that you’re never actually having to write out explicitly delete or free like you would in a language like C++. And in fact, C++ itself uses a lot of these same abstractions to make it feel higher level.

We’ve talked a lot about the background of Rust and the maybe purpose of Rust. We haven’t really talked about the features of the language a little bit except tangentially. Do you want to walk us through the core of Rust a little bit?

Sure. Let’s see. So, we’ve talked about some of those things. I think the central concept that is the most interesting in Rust and that’s been the most eye-opening for me (and this was the one that actually was not clear in the earlier days of the development of the language. It was something that the team discovered as they were working on the design) is a concept called ownership.

So, when you’re having to deal with memory management explicitly you have to figure out programming patterns. And it’s really no different from any other kind of programming. Like we have all of these raw pieces of, okay you’re handed a language and you’re handed some APIs. But now how do you actually use them in practice? And memory management is the thing you don’t have to deal with in other languages but in a low-level language since you have to deal with it, we had to figure out what do those idioms look like? And we realized that there was this one idiom that ended up being the central concept in all of Rust. And it tied in so many different things. It also allowed us to simplify the design enormously over the years. And that concept is called ownership.

So, the idea of ownership is that you have a sense of when a data structure is allocated there’s one point in the program that you can point to and say that this is the piece of the program that is responsible for managing that piece of data and for deciding when that piece of data is dead. And we talked a little bit about stack versus heap. As it turns out in systems programming, a lot of the data that you allocate can actually ultimately be owned by the stack in the sense that you create some local variable in a function and that local variable is where you first allocate the data structure that you’re using. And then when that function is done with that data structure it decides to throw that data structure away.

And so, you can say, okay this stack frame where this local variable exists, this local function, is actually the owner of this piece of data. And so, with ownership comes rights and responsibilities. You have the right as the owner of a data structure to destroy it and you have the responsibility of managing its lifetime. So, it’s also your responsibility to destroy it when you’re done with it. And so, along with ownership there’s a very closely related concept of borrowing and lending. So, I can have a function that owns a data structure and it tracks its lifetime and makes sure to de-allocate it when it’s done with it. But sometimes I want to let a helper function work on that data structure temporarily.

So again, these are concepts that are unfamiliar to a JavaScript programmer because you just don’t have to deal with them. But they end up being the one way of thinking about managing data structures that allows you to actually build software that can scale where you’re in charge of the management of your data structures. So, once you have this one concept it actually makes it possible to understand how to deal with manual memory management. And again, I’m saying manual but the in actual practice of Rust programming you’re not actually having to do a lot of the nitty-gritty details that make it feel like manual memory management.

Wait. So, that’s the one weird trick to building scalable software. There’s a BuzzFeed article.

Well, I would say it’s the one weird trick to scalable systems software. Yeah, sure. I think it’s actually pretty important, BuzzFeed or no, that you can distill all of the concepts in a programming language to one most important thing. Because there’s just only so many new things that you can learn at once.

But I don’t want to oversell it either. When you’re learning systems programming you’re learning new stuff. It’s a new area. And so, there’s definitely… it’s not something where you can expect if I’m a JavaScript programmer I’m going to pick up Rust and I’m going to understand it instantaneously. But I think the fact that it comes with these guarantees of no crashes and that it has actual conventions and it has ways of thinking about systems programming that make it actually possible for there to be an on ramp. Whereas if you imagine going from JavaScript to C++ it’s just a pretty terrifying proposition.

Yeah. [Chuckles]

It’s like, unsafe and there aren’t really guardrails where people can say, this is the C++ way.

Yeah, that’s part of the scary part is if you pick up C and you want to write an operating system, there’s this whole other set of knowledge that’s like how to write good C.

Mmhmm.

Because you can write terrible C, because the language doesn’t help you.

Yeah.

And so, it sounds like what you’re saying is Rust in the language itself helps you write good Rust.

Absolutely, yeah. And a lot of that comes from the type system. So, Rust has a static type system that actually prevents you from having those flaws. But that type system is also keeping you on the straight and narrow path to writing idiomatic code. Obviously you can abuse any programming language. But it’s more of an opinionated language. And when you’re learning C and C++ there’s this sense of, well I better be an expert before I ever try to ship anything.

And I wanted to mention that Rust comes out of the box, it already has had in production for several months a modern package manager. So, think like npm or Ruby’s Bundler. And if you’re just getting started in Rust and you’ve spent a week writing Rust code you don’t have to feel embarrassed about shipping a library in that ecosystem because you’ve got these guarantees from Rust that say, “Well it just can’t crash in these ways.” that you would never dare to do the same thing after a week of learning C++.

[Chuckles] So true.

So, it’s just like npm or Bundler or even Perl’s CPAN you don’t have to feel embarrassed about shipping bad code out there. You’ve got an idea. You put the idea out there. And somebody might find something worthwhile in there. But I think that’s a really liberating aspect of programming in active dynamic ecosystems like npm. And we can have that same kind of ecosystem in Rust because you have these strong guarantees from the language.

I’m still pretty sure I’ll find a way to embarrass myself.

Oh, don’t worry. I’m doing it, too. I’m sure that people will look at my first Rust library and say that I’m doing it wrong. [Chuckles]

So, question for you. Rust as a language, the compiler at compile time guarantees that you can’t write certain kinds of crashes. Does it also guarantee that you can’t write memory leaks?

It does not guarantee that, no. So, along the way the team’s decided, what are the things that are feasible to guarantee and what are the things that are infeasible to guarantee? But that said, because so much of the memory management comes down to stack allocation you actually have this guarantee that you allocated this data structure in this local function and it’s going to be deallocated when the function is done. And that makes predicting the lifetime of things actually much easier than in typical high-level languages. And so, the number of possible things that can contribute to leaks in your program tends to be smaller.

Now, I’m not saying this as an expert. I’m saying this more as what I hear second hand from the community. But it makes sense intuitively. It’s like, if most of your data lives exactly as long as the functions in which it was created then you just know that it can’t leak beyond the lifetime of that function. Now of course you can still do things like dynamic allocation. And so, there are APIs for doing things like ref counting. And like I mentioned, there’s also, eventually there’s work towards having optional garbage collection down the line. So, there certainly are ways that you can have data that lives indefinitely and that can lead to leaks. But in practice when you’re doing a lot of stack allocation it means leaks are far less likely to happen.

You know, I just realized another question that I was asked that I didn’t answer. Aimee asked, I think, what a seg fault is.

[Chuckles] Yup.

So, boy it’s been a long time since my operating systems class. I’m probably going to get the exact definition wrong. So, I’ll just…

I’ll go for a more intuitive definition. Seg faults are what happen when you do certain patterns of programming bugs where you’re touching memory thinking that it’s one thing and when it’s actually something else. So, they’re these common patterns like, one of the most common one is called use after free. So, you de-allocate a data structure but you have a reference into that data structure that’s still hanging around.

And so, imagine if in JavaScript we had a local variable X and we assigned it some object. And imagine in JavaScript we had the ability to say, now de-allocate this object. But X is still hanging around. And now we might say X.y to ask for a field y of this object that we de-allocated. Well, that’s now pointing into some part of memory that we have no way of predicting what’s there. Because we just told the language underneath the hood, you can reuse that memory for anything. So, I think I’m looking into this object but it’s actually, that memory’s been reused for something else entirely. So at this point, the behavior of your program is just wildly unpredictable and totally unsafe. And sometimes that leads to a crash called a seg fault. And you’ll see if you’re in your Unix prompt, it’ll say SIGSEGV to throw the signal that it send to the operating system saying that there was this particular kind of crash that happened.

By the way I still shiver whenever I even hear that word said.

It’s terrifying, yes, yes. And one of the worst parts about it is that it’s so hard to reproduce because it’s random behavior. Between any two runs of the same program, it could behave differently. So, it’s very hard to reproduce what’s going on in that program. And it’s very hard to track down the source of it. It’s like imagine if you have a bug in your program and the only way that the bug was reported was the program just says ‘no’. It gives you ‘no’. [Chuckles]

No stack trace, no nothing, just ‘no’. It could do better, but in practice just never having to worry about that is way better.

Yeah, totally. For people who aren’t super familiar, one of the things I use to envision this is imagine if your program had instead of variable names it just had a gigantic array of billions and billions of integers from 0 to 255. And you tell the operating system, I want a chunk of that. And then you go and read an index that you never said you wanted or that you said explicitly, “I’m giving this back.” And the operating system says ‘no’. [Chuckles]

Yeah. Actually, I think that’s a very good way of describing it because basically we’re talking about different abstraction layers here. That is a pretty good abstraction of a computer. It basically is this contiguous bucket of bytes and it’s just this one big array of bytes. And when you’re operating at the abstraction layer of JavaScript, you don’t want to think about that layer. And the garbage collector means you don’t that to think about that layer. You just think about your data structures and you know that when you’re looking at a data structure it’s going to be around. And when you’re not looking at it, it might disappear behind your back. But you don’t have to care because you’re not worrying about it anymore.

As soon as you expose the programmer to that lower layer, all of a sudden the have to deal with a lot more detail and lot more danger that they don’t have to worry about in JavaScript. And so, Rust lets you be much closer to that layer of abstraction but without those dangers.

So, I have a question that’s kind of a subject change. Before I ask it, do you want to talk any more about the features of Rust? Or are you ready to be taken on a journey?

Let’s go on a journey.

Okay. So, my question is more about programming languages in general. I don’t know if it’s just me learning more or if it really is the industry changing. But I feel like there’s a lot more focus on different programming languages. Even in JavaScript, there’s a lot of ES 6 stuff that is inspired by other languages. There’s a lot of stuff in the ES 7 spec that… I don’t know. It just seems like more and more of my actual working career is involved in programming languages. Golang came out. And how much does the working programming need to care about programming languages in general? Or do they just learn a tool and then go back to making their widgets in that tool? Does that make sense?

That’s a great question.

Yeah. So, I come at it from the perspective of a programming languages nerd. And so, I…

Yeah. You have a PhD in programming languages, right?

I do. I don’t usually admit it. [Inaudible]

You say that apologetically. Like, “yes, [unfortunately].” [Laughter]

I didn’t even know that was a thing. That’s awesome.

Yeah, yeah. I’d like to think that I put those years behind me and I’ve become more practical. [Laughter]

But it did teach me a lot of useful things, certainly. And I’ve carried that with me. So, I as a programming languages nut, I’m very excited about the diversity of languages today. I think you’ll find there’s a cultural split between some programmers. There are some programmers who believe all programming is the same. And a language is just a detail. And I’ll learn those details and then I’ll get to the real task at hand which is my particular program that I’m writing. And there’s another side which says that languages actually affect the way you think about programming and your productivity in programming. And what you can do effectively and what you can’t do effectively. And I’m definitely on that side of the camp.

On the other hand, I think that programming language enthusiasts tend to go too far in the direction of believing that just having some cool new language features alone is going to be enough to drive adoption. And there’s… opinions are a dime a dozen on what drives programming language adoption. But certainly one of the most effective tools that people have had in getting people to use a new programming language is if enables something that simply couldn’t be done before. So, often that means the language came along with some platform that it is the language of that platform. And if you want to write in that platform, you’ve got to learn that language.

JavaScript is a great example of that. If you want to learn web programming it’s pretty hard to avoid learning JavaScript. Certainly, you can learn languages that compile to JavaScript. But most of the time you end up really having to learn JavaScript since it’s the native language of the platform.

And a lot of people spend a lot of effort trying to avoid learning JavaScript.

Yeah, there are a lot of people that kick and scream to do it.

Yes, yes.

To not do it, I should say.

Certainly. I personally believe that it’s a great thing for a programmer to do to learn new languages. Because I think it does teach you new ways of thinking. I think it can be really empowering in that it can give you access to a power you didn’t have before. And that’s what I think is one of the most exciting things about Rust, is that because we’ve eliminated these big obstacles to learning systems programming, there’s going to be a whole bunch new people, a new generation of people, that have greater access to where systems programming can take them.

So actually, to connect this back earlier to your first question of why am I here talking on JavaScript

Jabber. I think there’s very concrete ways in which a JavaScript programmer could make use of Rust. So for example, there was a blogpost a couple of months ago by Andrew Oppenlander about embedding Rust in a Node project. So, you could write a native module in Rust instead of C and that might be more convenient or accessible.

That’s sounds way more [chuckles] likely to happen for me.

Yeah.

I’ve only [inaudible] I will ever write a C++ module for now.

Right. So, that’s a very concrete thing. But then there’s also just the, where do I want to go in my career? And maybe I don’t want to just do JavaScript programming. And maybe I’d like to get involved in the robotics or IoT or the maker movement. And I want to start programming to a Raspberry Pi or a Tesla.

Man, JavaScript’s all in all those places, too. Don’t worry about it.

Yeah, that [inaudible] is. There’s no question. And I think what you’re….

I was just half joking. [Chuckles]

Well no, it’s true. It’s definitely true. But another thing that you’re seeing is that there are performance limitations on this hardware.

Yes.

And so, a lot of times you have partial access to what the hardware can do if you’re writing in JavaScript. But you really can unlock the whole potential if you’re writing in C. But the barrier to entry in C is so high. And Rust I think lowers the barrier to entry. It definitely would not eliminate it entirely. But I think it makes it much more accessible.

So with Rust, the multithreaded aspect of it, do you get some multithreaded access for free? How do you manage that?

It is a concurrent and parallel programming language. It gives you access to threads, definitely. And again, anything you can do in C and C++ you can do with Rust. Part of what’s really cool about the concurrency story is you have all of that power. And again, it eliminates some of the most difficult gotchas that come with concurrent programming, too. And in fact, this ties into the ownership story, too. That’s what so amazing about ownership is it turned out to be the central unifying theme in all of programming Rust. By tracking who owns data at any given time, you have control over shared mutable state.

So, it’s pretty widely understood that what makes threaded programming hard is shared mutable state. And what some languages have done in order to tame that is by allowing the sharing but eliminating the mutation. So, Erlang is an example of that where you have an inherently concurrent programming language and by not having mutation they make it easier for different threads to be communicating with each other. With Rust, we allow sharing and we allow mutation but we control when you’re doing both. And that actually gives you access to a whole bunch of different concurrent programming patterns in a way that I’ll guarantee that certain kinds of the most painful bugs in concurrent programming are impossible. The egghead terminology is data races. It’s a kind of bug that you can get in C++ or Java that just doesn’t happen in Rust.

Okay. Yeah, because I’ve definitely felt the pain on Raspberry Pi of you might have four cores. But you can’t use them intuitively I would say from Node. Maybe I’m just not good enough of a Node developer in that area yet.

Yeah. I’m not an expert at what you can do with multiple cores in Node. I haven’t tracked what exactly you can do. But it’s… JavaScript, it’s hard to get over that hill in JavaScript.

Yeah. In the browser you have web workers. But debugging web workers has… well maybe the tools have gotten better. But when I was playing with it, it was very, very hard.

It’s bad. And on top of that, web workers are limited in what you can do. Rust gives you much more power when it comes to multithreaded programming.

So, very popular question as we’re talking about languages. [Chuckles] I’m sure you hear this all the time, the difference between Rust and Go and why Rust might be better for JavaScript developers.

Oh, I think the Rust team has tried to avoid saying that we’re just better than Go across the board.

They’re both operating in similar spaces, not entirely overlapping. And there certainly is some competition between the two in the sense that if you’re looking at the next thing you want to learn as a JavaScript programmer maybe you’d learn Rust and maybe you’d learn Go. I think the things that Rust has to offer are particularly that there are places it can go that Go can’t. Or at least today in Go you can’t go easily. In particular…

I see what you did there. [Laughter]

It’s hard to talk about Go without using the word ‘go’. But virtually the fact that Rust doesn’t come with a garbage collector, doesn’t come with a [inaudible] runtime system really at all, it’s just much easier to embed it in other systems. So, I mentioned the Skylight product that embeds Rust code into Ruby on Rails. You don’t have two garbage collectors that are competing with each other. You have a very small memory footprint. It’s often going to be the case that you would not put Python or Ruby or JavaScript embedded in a Ruby or Python or JavaScript program for two not the same high-level languages. Because they both come with non-trivial runtime systems that are going to be competing with each other. And you might have cyclic references between the two of them. And there’s no way of dealing with those references between the two.

Not to mention the fact that again, Rust can really go as far down to the metal as C can go. So, I think there are some places that Rust can go that Go can’t. They’re also just different designs. So, Go has deliberately avoided putting some features in, in an effort to aim at a design that fits their aesthetic that Rust has chosen to include. So for example, generics. Rust has generic types built into the language from the beginning. And Go does not have generic types. And it’s a discussion whether it should or shouldn’t. And I think there are reasonable points to be made on both sides. So, they’ve made some different design decisions.

Ultimately I would recommend people check them both out. I think they’re both interesting languages. And I think today there are things that Go can do that Rust isn’t there yet. I don’t think it’s for sure that that will be the case forever. So for example, Go’s had several years of being in production. And so, there’s a fair amount of things like web frameworks out there. So, you can reuse that code and maybe get to market quickly building your web server. And our ecosystem isn’t there yet with Rust. But I think you should watch the space of the Cargo ecosystem. Because I think we’ll see things like Rust’s version of Express hit the scene at some point. It just takes a little while for that ecosystem to ramp up.

Can you talk about Servo and how that has to do with Rust?

Sure. So, Rust is a community project that’s sort of been backed by Mozilla. And it was incubated at Mozilla originally. At this point it’s very much community-owned. But in the early days, Mozilla’s initial interest in Rust was in having a better language for doing the low-level programming that we do at Mozilla, in particular the programming that goes into the Firefox web browser. So, if you look at Firefox today, I’ve lost track, it’s somewhere around seven or eight million lines of C++ code. Which just every time I say that sends shivers down my spine. It’s really, really hard to maintain a codebase of that size in C++. It’s hard to stay competitive. Mozilla’s always had to be scrappy because we compete against competitors with much deeper pockets than we have. And so, we’re always looking for leverage, technological advantages.

And so, we were interested in Rust as a better programming language for implementing a web browser. But once you’re thinking about a new programming language for implementing a web browser you also have the ability to rethink how you’re writing that code, too. Because you’re going to be rewriting a significant portion of the code. You might as well be thinking about the architecture. And so, Servo was a project to, or still is a project to rethink how we build browser rendering engines entirely. In particular, to take advantage of modern hardware.

So, if you look at modern browsers they actually all kind of track back to the original Netscape architecture of the 90s, which is just terribly out of date. It was designed for a computer hardware landscape that was very different than the one today. In particular, today we have much beefier GPUs. We have a bunch of what are called SIMD instructions available. And we also have multiple cores available to us in a way that just wasn’t around in the 90s. But the architecture of the browser engines just wasn’t built to take advantage of that. So, we wanted to build a browser engine that really takes full advantage of modern hardware. So, that’s what Servo is.

Servo is still a work in progress. It’s really starting to show some impressive progress. We’ve got real websites that render correctly. We’ve got some really promising performance numbers, both in terms of just raw speed as well as battery usage. It turns out you can get a lot of power efficiency out of using multiple cores effectively. So, Servo’s an exciting project. It’s still a pretty big one and it’s going to take a couple more years for it to really become a full-fledged browser rendering engine. But it’s got a good head of steam behind it.

Is there any relationship between Rust and asm.js? Like being able to write Rust and compile to asm?

I would say in theory, absolutely. In practice so far, people have only done proofs of concept. There’s a pretty straightforward path to get from here to there. It just hasn’t been I think at the top of anybody’s agenda so far. But I expect that at some point somebody’s really going to say, “We got to do this. It’s going to happen.” The basic path that you would follow is you would use the Emscripten compiler which also was done at my group. That’s a compiler written by Alon Zakai which allows you to take any code that can be compiled with the LLVM compiler and compile it to asm.js to run on a browser. Well, the Rust compiler uses LLVM [chuckles]. So, at least in theory all you have to do is plug Rust compiler together with Emscripten. And boom, any Rust app should be able to run on the browser.

You know in practice, like any system, the details are in the execution. And so, you have to do things like figure out the bridge between Rust APIs and web APIs. And so, people would have to build the libraries that bridge between those. And there are I think just some engineering details about getting Emscripten ported. I don’t remember the details, but that have caused it from being a thing that’s actively maintained. I think part of it has to do with the fact that Emscripten is on a branch or a fork of LLVM. And it needs to rebase with more recent versions. But these are all I think engineering details. And I think eventually people will get there and do that.

But I should say it was never the purpose, at least for Mozilla. It was never our purpose in being interested in backing Rust. Our interest was really in having a better technology for us to build a web browser in. But I think we’re interested in all possible applications of Rust. And the Rust community serves a far, far larger ecosystem than just whatever Mozilla happens to be interested in.

So, are there any cool apps out there being built with Rust besides experimental rendering engines?

Yeah, so I mentioned Skylight as one. There are a handful of companies that have either experimented with it or built some early products. So, there was, actually dating back a while now when we first heard of it, it might even be close to two years ago that OpenDNS has a packet filtering system. So, they have a very, very low latency high performance DNS system that’s filtering packets as they come through. And they’ve implemented that in Rust and have a lot of success with it.

There was a startup in New York that was doing… I think they were doing high frequency trading stuff actually, originally. And I believe that their company has pivoted and it’s doing new things. But they’re still using Rust for very high performance use cases. I mentioned Skylight before that they’re doing a performance monitor for Rails apps. And then we hear about a couple of people like on Hacker News that’ll say things like, “Yeah, I’m using Rust at my startup.” But they hadn’t told us the details. So, we don’t know exactly what they’re doing yet. There was also a company that was recently acquired by Facebook, Wit.ai that was doing some natural language processing I believe, in Rust. I think that…

Oh yeah. I’ve used their stuff.

I think their Rust stuff was just experimental. But they also, as an experiment, they put Rust in their job description and found that they got a lot of [chuckles] really good applicants. Because a lot of people were excited about using Rust. So, those are some of a handful of early adopters.

But it’s pre-1.0 and there’s a really key difference about Rust before 1.0 and Rust after 1.0. We really jealously guarded the freedom to change the language in order to get it truly right up until 1.0. So, we really didn’t make stability guarantees. And that meant that you could build something in Rust one day and a week later it might not even compile. And so, that definitely caused churn in the community. And that puts a limit on how big your adoption can grow. Because for people to really be able to start depending on a platform they need some stability guarantees. But we’ve made a very strong stability guarantee at 1.0.

So, Rust is adopting a six-week train schedule similar to evergreen browsers like Firefox and Chrome. And it’s respecting SemVer. So, with each six-week release, it’s a minor version upgrade which means that you have a strong backwards compatibility guarantee from version to version. So, 1.0 is the beginning of a really strong stability promise from the language. And that means that people can really start to use it in production and know that they have real guarantees that their code is going to continue to work.

So, what hardware architectures can I write Rust code for now?

I’ve lost track. Certainly we have the usuals on desktop. You can build for Android. I believe there are maybe a couple of ARM ports. And then there are some experimental ports as well. One of the cool things is that by having LLVM as the backend, we get to leverage a lot of the portability, a lot of the portability that you get from C and C++. There’s non-zero work that goes into porting to a new platform. But we have a number of ports, some of them just maintained by the community. And people can pretty easily submit new ports. So, I think that set is going to keep growing. There are things like experimental ports for Raspberry Pi for example.

Alright. So, I want to change topics just a little bit and talk about learning Rust. What’s the best way to get out there and learn Rust, especially if you’re a JavaScript programmer?

That’s a great question. So, a couple of years ago there was a book that Steve Klabnik wrote and he was coming from mostly a Ruby background as well as some JavaScript. He wrote a book called ‘Rust for Rubyists’ and he was one of the early people who realized that hey, there’s this low-level language that actually has a lot of crossover appeal to high-level programmers. But it needs to be presented in a way that actually isn’t… not for somebody who’s coming from a C++ background. And I think he may not have continued maintaining that book, primarily because he’s actually joined the core team and is now really the one running the documentation.

And so, he’s put a ton of work into building what I think now is just called the Rust book which is a really from scratch, like get started from zero learning Rust. And he cares a lot about the non-C++ audience. It could be a little tricky sometimes trying to have a book that can address both audiences. And I think that there will probably be room for different books or different guides or tutorials written for different kinds of audiences. But the book is actually a very good place to start.

Also, I should mention that the IRC community for Rust places a lot of value in treating newcomers well and in general community conduct and being kind to each other. So, newbies don’t have to worry that this is going to be like, “I’m a JavaScript programmer and I’m about to go ask Linus Torvalds how to hack a Linux kernel module.” It’s not going to be like that. If you come to Rust and you’ve never written a line of C++ in your life and you’ve never written any Rust, you can ask whatever newbie question you want. And you will find that people will really work hard to help you get up to speed. So, there’s a great IRC culture. And even just to go and ask that same question you just asked me, that’s another place that I would go.

Awesome. Well, I guess it’s about time to wrap up if we don’t have anything final from the peanut gallery. [Laughs] Our panel, any last questions or should we move onto picks?

I’m question free.

Alright. Let’s move onto picks. Dave, would you like to go first?

Oh, sure. Happy to do it. I have three picks for you today. The first one is another podcast called Software Engineering Radio. And this is a pretty cool podcast with a really broad set of topics regarding software development. And I found it to be super informative. Sometimes they get really academic and geeky, which is cool. And then sometimes they get super pragmatic which is also cool. Cool subjects. One of my favorite ones was an episode about technical debt which really changed my perspective on what that term can mean.

The second one is a book by one of my favorite authors, Clayton Christensen. And the title of the book is called ‘How Will You Measure Your Life?’ And it’s not what I thought at first which is, looking back at the end of your life, how will you come up with a score? Zero to a hundred percent. [Chuckles] It’s more about how can you use proven business theory to improve things in your life, which I thought was really cool. And he explores all kinds of different facets. And he’s a very thoughtful man. And I really appreciate his perspective in this book.

And then finally an oldie but a goodie, a little pre-episode chatter from today. One of my favorite bands when I was a teenager 400 years ago approximately, and the band is called Presidents of the United States of America. And they’re an awesome band. I don’t know if you’d call them rock or hard rock. But they had some great classics like ‘Peaches’ and a few others. And I just pulled them up on YouTube and reminisced a little. So, here’s a little blast from my past. And maybe it’ll be something for your present.

Awesome. AJ, how about you?

Oh yeah. So, we were talking a little bit at the beginning about C and it’s hard to do. And that’s totally true. But there’s this one series of design patterns. I think I’ve picked this before. And so, I’m just going to throw a link to that in there. But it talks about how to do design patterns in C. And if you can do design patterns in C then you’ll be a better programmer. I promise. I give you my personal guarantee. Implementing different design patterns in a really hard environment makes your brain better.

Also, I’m really hating Microsoft right now because they’re doing things that aren’t stupid. And that’s inconsistent .And so, now I don’t know which category to put them in. Are they bad or are they good? But they did something really good. They adopted asm.js and they have a blog article explaining that and some of the process with Chakra. They also have got a fork of, I’m not sure whether it was Node or IO.js. But they’ve got a fork where they’re implementing it on top of Chakra, which also sounds good. It worries me. I don’t… what’s going on over there? And TypeScript, they actually have good things that are happening. And I’m confused.

Anyway, and also I’ll pick another podcast, actually. The Web Platform podcast. I was just… I had an angry moment of rant on Google Plus about some things I don’t agree with and the direction of ES 6. And one of the guys reached out to me and was like, “Why don’t you like it? Let’s talk about that.” And then we did a show with one of the guys from the committee, the TC39. And he corrected some of my misunderstandings about ES 6. And I hopefully enlightened him [chuckles] about some of the issues that may exist there. And that was kind of fun. So, I’ll put a link to that episode.

And the Firefox phone. I should pick this one every week. I love the Firefox OS. And I think that you should get in touch with Dan Callahan if you want a phone to play with because you actually think you will use it. And I will leave it up to your googling skills to find Dan Callahan’s contact information so that you at least have to do some work before you ask him for a beautiful shiny phone.

Love it, love it. Alright, Aimee. How about you next?

Okay. So, as I was preparing and reading a bit to get ready for the episode this week I remembered some really good resources I used a while back, before I did my bootcamp and before I started working. It was iTunes U. And there’s especially a good course on there. It’s called CS106A. And it’s a Stanford course. But obviously you can take it for free because it’s on iTunes U. So, I’m going to put a link to that specific course. There’s other really good material on iTunes U too.

And then my second pick. A couple of weeks ago I picked cat strollers. I have another cat pick. [Chuckles] So, everyone’s probably familiar with giving your cat catnip which is great and they do crazy things. But I recently realized that you can also give them valerian. And that, if anyone’s familiar with valerian, it makes humans sleepy. I take it at night sometimes to help fall asleep. But it works the opposite in cats. And it is crazy. [Chuckles] It puts catnip to shame. So, try…

Oh my gosh.

Yeah, try valerian for your cat. My cat absolutely flipped out. I was scared he was going to overdose or something or we’re going to have to take him to emergency vet. [Chuckles]

Ask your doctor if valerian is right for your cat. [Laughter]

Yeah. Do you have to get prescription for that?

He acted so crazy just from sniffing it a little bit that I started googling thinking he was going to have a heart attack or something. [Laughs] But apparently it’s okay. And you can actually buy it. So, try giving your cat valerian. [Chuckles]

I’m so going to try that.

They give it to overweight cats to make them more active. [Laughter]

Anyway, so those are my picks.

Now Aimee, if you’re tired of making cat picks, I am completely willing to ship my 12-year-old daughter out to you. And then after a while you’ll have some horrible kid picks.

[Laughs] Yeah, I seem to have… I always try to do one non-programming pick. And so, there seems to be a theme here. I either have one healthy pick or a cat pick. So, I guess everybody can tell what I do in my free time.

I’d just be interested to find out what drugs you suggest giving 12-year-old girls after a timeframe.

[Chuckles] Mm, I don’t know about that. [Laughter]

None. [Chuckles]

Alright. Jamison, how about you?

Okay. I have three picks. The first pick is a live album by one of my favorite bands, The Deer Hunter. It’s like big, progressive-ish rock. But it’s very approachable. I guess it’s rock with progressive influences instead of progressive rock. And they just dropped it out of nowhere without announcing it. And it’s incredible. It’s really good.

The next pick is a book called ‘Designing Data-Intensive Applications’. It’s all about backend engineering from the database up to distributed systems. And it explains very clearly how database storage engines work. They’d always been kind of opaque to me. They’re just machines that you put data into and get data back out. But on, they’re actually programs and you can understand how they work. And it goes up to talking about building big distributed systems and streaming and all kinds of cool stuff that I think is fun.

And my last pick is a blog called ‘Perlis Languages’, or a blogpost called ‘Perlis Languages’ by Fogus. He’s a famous programming languages and CS blogger. And he wrote a blogpost about languages that expand your brain. There’s this guy named Alan Perlis who said, “A language that doesn’t affect the way you think about programming is not worth knowing.” And so, this term ‘Perlis Languages’ came to mean languages you learn to teach you something. It seems like that was one of the big themes of this show today, is that learning Rust will teach you stuff about computers. And there’s this giant list of languages that will teach you all kinds of different stuff on this blogpost. So, that’s my pick.

Alright. I’ll go next. For my first pick I’m going to pick the game Galactic Civilizations III. It just released today, May 14th. I loved previous versions of it. I’ve been playing it in beta. And it wasn’t really great in beta because not enough stuff was finished. But it’s just released and it’s getting a ton of positive reviews. So, I’m very excited to play it for real, now that the real version is out.

My second and final pick will be tangential to what AJ was talking about with Microsoft, Microsoft has recently released a new editor called Visual Studio Code, which we had a special episode about this on Adventures in Angular. And the main point of that was the fact that that was a terrible name for a product because it’s such a generic word.

Oh , I was going to say, “Does it finally support code?”

That’s what I’ve been waiting for.

[Laughs] Yeah. It’s so funny because it’s a little lightweight editor. It’s multiplatform, works on Mac and Linux. And think of a…

What?

It’s very analogous to Sublime. It’s just like Sublime

Who is this Microsoft and what have they done with the Microsoft that we all grew up with?

Yeah, we all grew up with and agreed to hate because they were old and stodgy. Yeah, so it’s actually a really cool editor. Right now it’s not fantastic (it’s a pretty early release) just because it hates ES 6. So, if you’re programming in ES 5, no big deal. Or if you’re programming in I think TypeScript it’s great. It’s also amazing at debugging Node apparently. It has a Node debugging experience that will make you just get weak in the knees. But right now I’m having problems with ES 6. It underlines everything and thinks that everything is wrong. But overall I really like the editor. It’s got awesome shortcuts, multiple carets, all the bells and whistles you’d expect from a good lightweight editor. And so, that’ll be my second and final pick. And last, we have Dave. We’re all excited to hear what your picks are because they’re usually so fantastically pedantic.

[Laughs] Pedantic. [Laughter]

Hey wait, before you do your picks. I have one question I wanted to ask you. How many computer programming languages do you feel comfortable with?

That I feel comfortable with. Oh, I don’t know. I think just because you understand the concepts of programming languages doesn’t mean that you’re actually effective at working with them. It takes a lot of experience to be fluent in a programming language.

So, are you going to say zero? [Laughs] Just kidding.

I don’t know. A lot of my job doesn’t involve coding anymore. So, sometimes I feel like I’ve gotten out of touch. And usually my go-to language is JavaScript when I’m hacking up something quick. So, I used to do Java. I’m comfortable enough in C++ that I can read it. But like I said before, I’m terrified to ship C++ in production. I was a very avid user of the programming language Racket in grad school. And I’m trying to ramp up my Rust skills. But I don’t claim to be an expert yet.

I don’t think there are any non-avid Racket users.

Yeah.

It seems like everyone that uses it loves it.

But you know, you get out of touch. Languages keep changing and growing. And the style that people use changes over time. And so, I’m probably way out of touch with Racket at this point. So, it’s hard to claim that just because I used to speak Racket I still speak it just as well. So, not actually that many.

Hmm. Well, the most, for me the most interesting amazing thing out of that was that a guy who has a PhD in languages, his go-to language is JavaScript.

Boom! Take that, haters.

Yeah. Drop the mic.

I like me some JavaScript. What can I say?

[Chuckles] Yeah.

Alright. So, let’s move onto your picks.

Alright. So, my picks. Let’s see. For the first one, to be Rust-themed, I mentioned that there are a number of hobbyist hardware kits where you can use Rust. But there’s one that came out that uses Rust as one of its supported programming languages. That’s the Tessel 2. Actually the website is out and you can preorder. But the board is not going to be shipping until August, I think. But it’s a

nice price point. It’s $35. It’s a cute little piece of hardware.

And I have not gotten into the whole hobbyist hardware movement. I’ve sort of resisted it for years because I had a feeling I would get addicted and wouldn’t be able to stop. But once I saw that there was one where you go to the website and it shows you Python, Node, and Rust code snippets, at that point I couldn’t resist. So, I went ahead and preordered myself a couple of them. So, I expect myself to start getting hooked pretty soon on hardware hacking. But…

But have you preordered the Firefox Flame?

Well, we can get those through employee programs.

Well yeah, I know. I just… that’s why I love… exactly what you’re talking about is why I love the Flame.

It’s all the goodness of a Tessel plus six expansion boards in my hand. And I paid for it because I bought them when they were for sale. But other developers can contact… probably you would have the right contact info for that, too. But Dan I know can make that happen.

Yeah, I think Dan’s the right person to go to for that. Yeah, so Tessel 2 is my first pick.

My second pick is a book. It’s by Leah Silber who is a cofounder of Tilda. That’s the company I mentioned before that does the Skylight Rails performance monitor. And Leah has been a part of the open source world for many, many years. And she has done a ton of events planning, like putting together conferences. She’s been involved in the jQuery world. She’d put together a bunch of jQuery conferences. She’s done a bunch of Rails conferences like GoGaRuCo and RailsConf. And she organizes the EmberConfs each year. So, she has years and years and years of experience putting together events. And she has actually written an entire book called ‘Event Driven’ which is a really cool name, about how to put together a successful open source technology conference.

And one of the things I really like about this is I think we all as engineers have seen that there’s this, a little bit of cockiness in engineering culture that we think, “Well we have the hardest job in the world. So, if we can do engineering we can do anything.” And so, what often happens when you’re putting together an open source technology, if it starts to get big is you think, “Well I can do the technical parts. So, I can do all of it.”

How hard could it be?

Exactly, exactly. And it turns out [chuckles] that it’s really hard. It’s very, very hard to put together a successful event. And there are many, many parts that go into it. And so, Leah has done I think an amazing service for the open source world by creating a book just full of the wisdom that she was acquired over the years. So, it’s available on Leanpub and I think you can set your own price. And I would suggest that you set the price high for Leah’s sake. But I know that what she did was not… she wasn’t in it for the money. It was really a labor of love. She wants the open source world to have success. And so, this book was really all about helping people be successful at putting together events. So, that’s my second pick.

And I didn’t have a third pick until Aimee mentioned cats. And I felt like I had to have a cat pick. So, my third pick is going to be the plush Hello Kitty doll that took me an entire day of searching the city of Paris to find. I was in Paris a couple of months ago for a TC39 meeting. And I had one day before the meeting started to try to pick up some sort of a souvenir for my daughter who is two years old and absolutely obsessed with cats. And I thought, “Well, Hello Kitty is going to be easy because she’s basically like Mickey Mouse. She’ll be anywhere.” And it turns out it’s very hard to find Hello Kitty in Paris. So, after traversing the city several times I finally found a little French flag colored Hello Kitty. So, she’s my third pick.

Fantastic. Thank you so much. Dave, we’ve really enjoyed having you on the show.

Yeah.

As we always do every time.

Well, thank you so much for having me.

Yeah, this was great.

It’s been a lot of fun.

I can’t wait to dig into a little Rust