[MUSIC] >> Hello, welcome to Picture Me Coding with Erik Aker and Mike Mull.

Mike, you've been away for a while and you are back and we are on air again.

Welcome back.

>> Thank you.

>> Yeah, I was visiting my father again back in the red states.

>> Did you hitchhike out to Indiana from California?

>> Yes.

Yes, I walked along back roads and hitchhiked.

>> Nice.

>> No, sadly, I flew this time and reminded me of why I hate flying so much.

[LAUGH] >> Why do you hate flying so much?

>> I don't know, I just find it unpleasant.

I think part of it is it's actually kind of physically challenging for me because I have very low blood pressure and so sitting still for long periods of time is difficult for me.

>> Wow, I had never considered that.

I have something far more trivial than that.

My commentary on flying is, the thing that always puzzled me about flying is, I get up, I go to the airport, I sit around, I get on the airplane, I sit around, I get off the airplane and I feel really dirty.

Like my skin feels oily, like I need to take a bath.

>> Yeah.

>> Why is that?

[LAUGH] I don't understand that.

I don't normally feel like I need to take a bath regularly, unless I go get real sweaty or something.

>> Yeah, I have the same experience and I try not to think about it too deeply.

[LAUGH] Yeah, flying is probably the second most unpleasant thing I do voluntarily after sitting in Los Angeles traffic.

>> Here's a flying related question for you, Mike.

Did you listen to the new High on Fire album, Cometh the Storm?

>> I've been listening to it.

I did actually download it from Spotify to my phone just in case I needed something really loud to block out the airplane noise and the screaming babies and so forth.

>> [LAUGH] >> Yeah, enjoy it for those people who are not metal aficionados.

High on Fire is kind of a spin off ban from one of our mutual favorites, Sleep.

>> Of the 100 people who listen to us, I wonder how many of them out there are going to be like, yes, High on Fire.

>> [LAUGH] >> 1%, maybe there's a one of you out there.

>> Yeah, I don't know.

I kind of would guess that our core audience, our base is probably kind of like weirdos.

>> Okay, all right, hey weirdos, there's an album called Cometh the Storm from a band called High on Fire.

And I guess one last question about it, Mike, when I listen to it, it sounds like, hey, this is the High on Fire I remember.

That's kind of cool, I always liked that music.

What do you think?

Does it sound like New Ground or does it sound like Familiar and is it good?

Do you think it's a good one?

>> I think it's a little bit of New Ground.

If you listen to the first High on Fire album, you could sort of trace it back to the doom metal of Sleep.

>> That's the one with Fireface on it?

That's one of my favorite songs ever.

>> Yeah, and I think this is a little bit more traditional metal.

I read one review that kind of compared it to Motorhead.

So yeah, there's some interesting stuff here.

It sounds good.

I mean, I used to think of them as being kind of an obscure band, but they want to grab me back in 2019.

So I guess they're kind of well known now.

>> I guess my awareness is obscure.

I had no clue about that.

They always have sweet cover, album covers with demons with bat wings on them and stuff.

It's like a throwback to the 80s.

>> Yeah.

>> And like chromed out lettering with drop shadows.

>> Yeah.

I guess the guitarist has gotten into Turkish folk music.

>> Oh.

>> And so there's one or two of the metal tracks that have a little bit of influence from that.

And then there's one track on the album, which is just almost straight up a folk tune.

>> Wow.

>> Which is kind of interesting.

>> Yeah.

>> So anyway, if you're a metal person, I recommend it.

I really like Matt Pike.

I aspire to be like him and not having to ever wear a shirt.

>> All right, moving on.

Our topic of conversation this week, Mike, we wanted to talk about, I wanted to talk about, you want to talk about a language that we have mentioned many times, rust.

But this actually isn't just, hey, we want to talk about rust.

It came up because we were having a conversation with our mutual friend Bob.

Bob's been on the podcast a couple of times.

Bob's background is math and finance and data science and neural networks.

He's got a pretty interesting background.

He's done MATLAB, he's done a lot of Python.

And in our conversation, he was asking us about rust.

And you dropped this comment that I thought, hmm, that could be a little bit of a hot take there.

What do I think about this comment?

The comment was, I think professional software engineers should know a compiled language.

>> Do you remember that comment?

Did I phrase it right?

>> Yeah, I think that's the gist of it.

>> I want to ask why.

>> Well, I think there's two reasons.

One is that for a certain subset of the professional least, a compiled language is probably going to be a necessity.

>> Game development, maybe is what you're thinking.

>> Well, if you're- >> Graphics.

>> If you're the kind of person who might have done C ten years ago, rust might be a choice now or C plus plus.

So embedded stuff, stuff where performance is an issue, Linux kernel development is now a possibility in rust.

So I think it's, you need to know it literally in some parts of the profession, but I also think that it is useful to sort of round out your knowledge because there are certain things about using compiled languages that you don't really encounter if you're strictly using Python or even really Java, which a lot of people would consider to be a compiled language.

>> Right.

I mean, I think, yeah, that was my other question.

It's like, what counts in here?

But we still haven't quite gotten to, you're saying there are some people, of course, who have to, but you're also saying the people who don't have to.

Like people like me who work in web and back end and data engineering and infrastructure and maybe data science people.

You're saying it's beneficial for them to know a compiled language too.

And then we'll talk for a second about which languages count. (laughing) >> Yeah, and I think the sort of key reason is because I think they, I think compiled languages teach you a little bit more about how computers actually work.

And I think that is a, especially as you get deeper and deeper into your career, I think it's kind of useful to have some, some at least surface level understanding of the machinery.

>> So your argument is you really should have some visibility into layers of the stack that are a little more low level than whatever you're currently working at.

>> I think it is.

And I think it's been helpful to me.

>> So we're talking stack and heap here.

We're talking CPU registers.

Is that what we're talking about assembly?

>> Memory in general, I think, the fact that there are instructions that are specific to your CPU, I think.

>> Your architecture, you mean?

>> Yeah, that you're, are you an on Intel or are you on ARM or that kind of thing?

Just knowing that those are different things, which is easy to abstract over if you have only ever dealt with, say Python.

>> Yeah, or Go, which you don't have to worry about that, do you, just cross compile?

>> Yeah, I think it is, I think it is useful to understand, the stack and the heap and the difference between those two things and how they come into play with the variables in your program and whether something is being treated as a value or treated as a reference and things like that.

>> Call by reference, call by reference.

So the obvious then question is, what you're saying it's useful for professional software engineers no matter what kind of work they're doing to have this experience with a compiled language.

But the things you're saying that you get experience with a compiled language, through a compiled language, it's the elements you're talking about, it really only speaks to a handful of compiled languages, right, there aren't that many that fit this category.

>> Well, there aren't that many that are in common use, I would say.

I think if you were to look at Wikipedia, there's probably dozens of them that qualify, but are in such infrequent use that most professionals wouldn't know them.

>> I mean, it sounds like you're almost saying, you ought to know C or C++ or Rust, in addition to whatever you know.

That seems like a pretty bold claim, especially when I really like Rust, I never think about stack, I mean, maybe not never, that's not true.

I don't think about CPU architectures, except for when I'm issuing a command to compile a thing.

You know, like I don't actually think about the stuff you're talking about.

>> Yeah, and I think in the difference between the beginning of my career and this point in time is that there is so much abstraction.

I mean, it's almost, I don't have statistics on this, but I would guess that probably a relatively small percentage of programmers are programming to the actual metal anymore.

We're often building Docker containers and then deploying them on virtual machines.

And so the distance between the code you're writing and the actual instruction set of the CPU and which it's running is quite a few steps away.

>> I guess I felt like, well, Mike says that professional software engineers should know a compiled language.

He thinks that C, C++ and Rust are good valid candidates for that.

Well, lucky for me, I can write some Rust, so I fit this recommendation that Mike has, otherwise I'm kind of screwed.

>> Yeah, and I would probably say that, you know, for myself, if I were doing, working on a project now that required a compiled language, I would definitely choose Rust.

I mean, I think the other modern option is probably Go.

>> So you would, you put Go in this category?

>> Well, I put Go in the category of compiled.

Yeah, I think that's a fair-- >> But you didn't put Java in the category.

>> Well, Go's not running on, I don't know anything about Go.

>> 'Cause there's no virtual machine.

>> There's no JVM, yeah.

Well, there's no virtual machine.

But, you know, there's obviously differences there too, especially in the, with respect to memory management.

>> Okay, let's talk about Rust for a bit.

'Cause Bob is like, "Hey, I'm interested in Rust.

"What should I do to learn it?"

And I think you and I were both like, "Oh, cool, it's a cool language.

"Here's why people like it.

"Oh, wait a minute, you do data science."

Hmm. (laughing) >> What do you like about Rust?

>> So I think the reasons I would probably choose it now over say C or C++, I like the type system.

You know, the type system is probably, I'm probably not using it to its fullest effect because I'm still a relatively new convert.

But there are certain things like, you know, that have been brought over from functional languages that I just really like and have a hard time doing without in other languages.

>> Absolutely, 100% agree on that one.

>> Yeah, I mean, some types is the thing that first occurs to me, but there are other things too.

>> Absolutely, when I encountered algebraic data types or some types in Haskell in Rust, that would be an enum.

I was like, I hope to never use a language without this again.

This is a beautiful, absolutely vital piece of writing code in the future for me.

>> Yeah, it's such a nice abstraction.

>> And when paired with really good pattern matching, right?

Like Rust's match statement or the way in Haskell that you define a function by destructuring as some type potentially into its variance, it's absolutely phenomenal feature.

>> Yeah, and although it's annoying at first, I think the sort of option that is common in Rust that kind of comes over from languages like Haskell is a nice thing too, at least in the sense that it frees you from the burden of dealing with nulls.

>> And results similarly, right?

You want to have an error in case in your function, you return a result and everything that handles that function return value must account for the fact that it might be a result.

You can't just assume that it worked out.

>> Yeah, results I guess is really what I was thinking of.

>> Because you got question marks all over in your code?

>> Yeah, when you start looking at Rust, the one thing that we do have to confess is that Rust has a learning curve.

It's not something that is quite as easy to jump into as Python or even go.

But so you first see all these unwrapped calls and you're like, what the hell is that?

>> Clubs.

>> Yeah, it comes with a little bit of, I mean the type system and some of the other features comes with a little bit of learning, but I think it's worthwhile.

>> Well, let's go back to my question.

My question was, what do you like about it?

And the thing you mentioned first, type system.

And when people say to me, what do you like about Rust?

The number one thing I would say in response is type system.

So I'll comment on that, but I want to know what else you like about it.

And I want to compare what we say to what other people say, because I think what we're saying is slightly different than what I see other people saying.

So I love the type system in Rust.

And I like it because it feels like a lot of the benefits of some of the typing in Haskell, but a much more practically oriented strict type system.

Haskell can be highly theoretical and you might have in Haskell, you have higher kind of types.

So types that deal with a handful of type variables and like a functor can convert a type to another type if you pass it a function that has that responsibility.

Rust doesn't really have this.

You might argue, and some people have that it's missing something by not having this, but there's so much production ready, useful value in a type system that it has.

Just this week actually, someone was looking at a code base that I had authored in Rust at work.

And that person said to me, "Hey, I opened this module and I just found it so nice to read and so easy to follow.

And it's gonna be, I've never seen it before.

It's gonna be really easy for me to contribute to."

And I didn't know what they were talking about.

So I went and looked at that module and I couldn't see what they were seeing.

I was like, "Oh, okay, I don't really understand why they've made that comp."

They were complimenting it.

Yeah, but I don't know why.

And to make it worse, when I looked at the module, I was like, "Oh, there's a bug in here."

And then I made a PR to fix the bug.

So I went back and I was like, "I don't understand what you're seeing."

And he pointed to this particular function which had very explicit types, which goes back to this thing people used to always talk about in Haskell, which is you can leverage this type system to make illegal states unrepresentable.

I'll give you one example.

I can write a function that takes an email address as a string, and maybe a first name as a string.

And in Rust, I can use the new type pattern.

So I can wrap those strings in another type.

And what I can do is I can insert some intentionality.

I could have a function which just takes two strings.

And then obviously it'd be easy to mix them up.

But if I instead say, "You have to send me this email type, and you have to also send me this first name type," you have to actually create those types.

And then as they get passed around the program, I can rely on them.

I can be like, "Okay, that's an email type."

And it frees my brain to not have to always debug at the call site.

Like I just sort of assert my function is receiving an email, and then I move on from there.

Type system is very, very nice for that.

Sometimes pattern matching, those are beautiful.

The way generics are implemented, I think it's pretty nice.

Immutability by default.

And, but most of all, making illegal states unrepresentable.

I think you can really do that with the Rust type system.

I really like it.

That's my number one reason why I like using Rust.

What else do you like about Rust? - Well, I think, you know, the selling points of Rust, if it was just a simpler language that implemented fancy types, I don't know that it would have caught on like it did.

So, you know, the selling points are obviously the memory safety and the way that it deals with concurrency, which, you know, we've talked about this, how useful are they actually at a practical sense to most programmers, I don't know.

But they seem like worthwhile features to me.

And they are, once you get past some sort of initial panic, are fairly easy to comprehend.

So, I guess one thing, you know, that for, we're sort of assuming that everybody that we're talking to already know some of Rust.

And I guess one thing that we should probably point out is that one way in which this is sort of similar to C is that there is no garbage collection in Rust.

So the allocation and deallocation of memory is somewhat similar to C and that it's your responsibility.

But the language has all these features to make it very difficult for you to screw up things.

Mm-hmm, make mistakes with your memory.

Now, I asked you what's important to you and you started talking about what people say.

Are these things important to you?

No garbage collection.

Is that important feature for you?

I think it is in certain circumstances.

I mean, I think there are types of programming that you can do, you know, again, that kind of stuff where you would probably use Rust as a replacement for C.

I think not having garbage collection may be sort of a key feature.

Not having garbage collection, but also having features to keep you from, you know, having data races or overflows and that kind of thing is probably pretty important.

You know, whether or not that's a key feature to somebody, you know, writing a web app, maybe not.

But I think it would be a reason I would use for choosing this as my go-to compiled language.

What about speed?

I notice you didn't mention it's very fast.

Maybe that's just implied by a replacement for C, so you don't even need to mention speed.

Yeah, I guess that's a good point, is that I'm kind of thinking that everybody, you know, that Rust is not necessary, is not faster than C, but it's in many cases as fast as C.

So you're not maybe gaining anything in speed over C or C++, but you would definitely use this language in situations where you need something to be fast.

If you're a Python programmer, it's very likely that you've already encountered something written in Rust that is being used from Python.

Yeah, yeah, numerous examples, probably dantic cryptography, a lot of examples.

Yeah, I've been experimenting with Polar's a little bit recently, which is-- There's a JSON serialization library, it's popular called ORJSON.

Yeah, and so, you know, these are situations where even when you're using them from, you know, say you're a data scientist or data engineer, you're still using something that was ultimately in Rust because of its speed.

So I have what I feel like is kind of a shallow reason for really liking Rust, the type system, not a shallow reason, but tied for first place in my prioritization of why I like to use this language is, oh, it's pretty fast, that's cool.

So like, it's got a great type system, and oh, it's really fast, it's blazing fast, it's as fast as I could possibly go in programming languages that I'm capable of writing.

That's kind of a cool feature.

I find myself a little guilty in that if it had garbage collection and was still this fast and still had this type system, I probably wouldn't care.

Yeah, I can sympathize with that.

And to be fair, you know, a lot of the web stuff that we've done with Rust has been with Axum or I guess more specifically with Tokyo.

Web server stuff.

Yeah, web server stuff, so to make it async.

And so there is kind of a, there is kind of a runtime, so to speak in there.

So, you know-- You're calling Tokyo the runtime.

Yeah, I probably don't know enough to get into the precise semantics there, but there's something in there that's kind of scheduling these tasks.

Async tasks is about loop thing, yeah.

Yeah, so, you know, I guess you could argue that has maybe some of the same issues as a garbage collector, but-- So I wanna give you a couple quotes here in a second.

And here's what these quotes are getting at.

So I feel like when people say, this is why Rust is a great language, some of the stuff I read, I go, oh, that's cool, but I don't care about that.

And I still wanna use it.

And so then the problem is you look at me and you're like, Eric wants us to use this Rust server framework for an HTTP server work.

Why in the world do we do that?

We could just write, pipe that one, a Ruby or JavaScript.

And I really like writing Rust 'cause I find the type system makes it, it makes it so I can free my brain to not have to think about certain things in the future.

I like how fast it is, that's a cool benefit.

When people talk about the speed, they often talk about memory management and garbage collection.

And I find I don't care that much myself about garbage collection, but Rust as a side benefit has made me think differently about memory.

And so I actually appreciate that when I use the language, I am thinking in my head, how long do my objects live?

I have written Python programs that have memory leaks in them.

It's happened a couple of times, mostly with pandas.

So I'm gonna give you a couple of quotes.

From a blog from a rerun, a company called rerun, there's this line, we've had fast languages like C and C++ and then we've had safe languages like Lisp, Java and Python.

We're talking about memory safe.

The safe languages were all slower.

Common wisdom said that a programming language could either be safe or fast, but not both.

Rust has thoroughly disproved this with speeds rivaling C, even when writing safe Rust.

So people talk about, oh, it's super fast and safe.

And I'm like, oh, that's cool that it's fast. - Yeah, I don't know.

I think this is probably a very programmer dependent perspective.

You know, one thing that got me excited about Rust was when they started talking about using it in the Linux kernel.

And I think that's definitely a situation where both the lack of garbage collection and the general memory safety is an important thing.

But I could also see like if you were doing certain types of distributed systems, you know, you wanted to build your own queuing system or something, it would be nice not to have to think about what's happening, you know, the variables of the garbage collection.

Yehuda Katz says, "Rust does something everyone said was impossible when I started programming, being able to write tens of thousands of lines of safe code without the performance costs of garbage collection."

So here again is this idea of speed and performance combined with this idea of safety.

It's so fast, but also safe.

And I think that's because of the similar perspective that you started with, which is, oh, this is a great replacement for C and C++.

And I'm one of the weirdos, and there are many of us out here who are like, "Oh, wow, I could use this instead of Python or JavaScript or Ruby." - Yeah, I think there's a tendency that I don't like, but I think is debatable, which is that every time an interesting new language comes out, people try to implement every possible framework for that language.

You know, so for instance, I was doing some experimenting with Julia a year or two ago, and I like Julia.

I think it's a good candidate for certain types of scientific programs, but I don't wanna write web applications in Julia. - Yeah, that seems loony. - I don't really want people to write web frameworks for it, but anyway, slightly off topic, but... - Sorry if we offended anybody there.

If you're writing a web server framework in Julia. (laughing) - Yeah, I think there's two things I wanted to comment about that.

I think one of the features of Rust, which is I think a selling point is that it's very general purpose.

So maybe it's not the best for data science, but you could use it for data science, and you can use it for web applications, and command line utilities, and networking, and so forth.

The other thing is that I've read a couple articles recently where people have said, "Well, we're adding these features to C++ now, and so if you're a C++ programmer, you Rust is probably not gonna be something you need to learn."

My take is even if C++ had all the same features, I still don't think I would wanna use C++, I just like the language better.

I like Rust as a language better. - Not to mention you don't wanna use make or see make.

Sorry, little dig there.

Tooling to come. (laughing) - Yeah, so anyway, I mean, I think there's just certain things about Rust that are maybe not easily quantifiable that I like better than other languages, which are comparable in some ways. - So for me, things I love about it, I love the type system, as we said, I like how fast it is as a benefit.

I actually like how it has trained me to think about memory, but going back to your initial point, where you're talking about different layers of my technical stack, stack and heap, things like that, I tend, usually, I mean, I'll think, oh, I'm gonna box this thing.

Okay, that goes on the heap, got it.

I tend not to think about stack and heap, I tend to think in the Rust way about memory.

Is this owned?

Is this a reference?

Can I mutably borrow this thing?

Carol Nichols, who's a core contributor to Rust, and author of the Rust book, and really like a nice voice to listen to.

If you're interested in learning more about Rust, she's got this great way of presenting information, very kind of reasoned straightforward, I think.

She has this analogy that I really liked.

She said, the Rust memory model is like this.

Instead of having a janitor walk around a party that's like a big potluck and ask people, are you done with this dish?

Can I take it away and clean it?

If you brought your own dish to the party, it's a potluck, you're generally gonna be responsible for washing that dish and bringing it home at the end of the night.

And she says, this compromises that you're responsible.

And this is the idea, janitor would be like a garbage collection, but if you go to the potluck and you bring your dish and you own it, then that's more like the Rust memory model.

And the interesting thing about Rust is that the compiler will enforce this.

You cannot compile a program where you're violating this restriction.

Who owns what?

It takes a while to get a feel for this.

A couple of weeks ago, I was actually looking at a PR and there's another Rust project at work, and someone had cloned this kind of medium-sized, object, a struct, and they were trying to pull out an attribute on it.

They cloned the whole thing to pull out an attribute.

And I said, oh no, it looks like you just want this attribute.

You have a reference to it, follow the reference, and then clone the value inside the attribute.

And they were like, oh yeah, that makes sense.

It didn't immediately occur to them.

But when I think in Rust programs, and maybe this would be true, this would probably be true, of course, of C, C++ if I were writing those, I think about am I being wasteful with memory?

And maybe sometimes I might over-optimize, but it feels like a nicer usage of compute resources to be only using what I need.

I like this memory, this sort of this mental model of who owns what?

Who owns the data?

Who references the data?

I like thinking about my program in this way.

It's not the kind of thing where I could say to somebody else who hasn't used Rust, oh, you should do it so that you think about memory in this way, but it's like this benefit that I get.

Many years ago, I was interviewing for a job, primarily working in Python.

And they asked me, is Python called by reference or called by value?

And I was like, if I pass a dictionary and you can modify it, if I pass a string in, you're not gonna modify it.

In both cases, you're passing in objects on the heap.

What's the question again?

(laughs) It was like I was abstracted at that point away from how the language operated.

I more needed to know the rules.

Numbers and strings bound to variables are gonna behave differently than lists and dictionaries.

And I could sort of reason out why that has to be the case.

But it's a different model.

Do you find it beneficial to think in this way about memory when you write Rust programs?

The compiler tells you, no, don't do that.

And do you think to yourself as I do, oh, thank you for telling me. (laughs) - Well, I think this goes back to my original point about why I think it's useful to learn a compiled language 'cause I think it does make you think about the fact that memory is not strictly abstractions.

I think it's easy with certain languages, even when they're compiled to sort of lose track of the fact that things like memory are a finite resource. - That's you gotta pay for. (laughs) - Yeah, and that the way that you arrange things in memory and separate code from data and stuff like that is important.

I think one thing I like about Rust is that it does make you think about memory without making you think too much about stuff like pointers and dereferencing.

I mean, obviously you can do that and it comes up a lot, but with C it's such a fundamental part of the language. - Yeah, you can't write C without doing that. - Yeah, it's kind of almost too close to the middle there.

With C you're kind of thinking in terms of pointers pointing at memory locations and it's maybe a little bit too low level.

But yeah, I mean, with your question about pass by value or pass by reference, I think it's good for a programmer to think in terms of, okay, I have a vector that has 10,000 elements in it.

If I pass this vector into a function, what is actually happening to that data? - Yeah, 'cause it's possible in your programming language that it duplicates that, that'd be pretty wasteful.

You would wanna know that, right? - Yeah, like you wouldn't probably want those two - Yeah, like you wouldn't probably want those 10,000 things to be reallocated on the stack, for instance. - Or in Python, if I just append in a loop to a list, every time it gets beyond 50% of its memory allocation, it's gonna like build a new list that's twice as large and copy all the elements out.

Like sometimes it's useful to know that type of stuff. - Yeah, so the Eddakruss does still require you to think about that, if you're passing a vector or you're passing a reference to a vector, where is that memory actually going?

And then of course you do run into the sort of unfamiliar or slightly daunting aspects of ownership and borrowing that are kind of tricky at first and rest. - And how long does this thing live for?

I really like thinking in that way. - Yeah, and again, I think it's kind of a learning experience even if you don't become an exclusively hardcore Rust programmer, I think it's a good thing to sort of understanding your head and the fact that these things that you're dealing with sort of explicitly in Rust are still happening in other languages, even if there are abstractions in those languages to sort of take them out of your hands. - Yeah, I agree with that.

I think I probably wouldn't use the language though if it didn't have all kinds of super cool high level features as well, the iterators, I can map, I can filter, I can reduce, I have very, very cool, I mean maybe it's 'cause of the type system of course, but the way the language, the constructs of paradigms in the language are nice.

Sometimes I don't necessarily like how it looks.

That's a different conversation.

Another thing I love about Rust that I often find myself when people say, "Why do you want to use it?"

This is number two.

So for me, number one, type system.

Also, type for first, it's very fast.

Number two, the second reason I want to use it, the tooling is freaking incredible.

This may sound like a weird reason to say I want to use a language.

I love Rust up, I love Cargo, I love Clippy and Rust Format, I love Rust Analyzer.

Just yesterday, I was helping someone who's never done Python development try to set up a Python environment to work on a single Python app.

They'll probably work on other Python apps in the future.

And we have to solve all these problems.

They need a C Python on their machine.

Okay, well, if they only ever work on this one, they could probably just, this is on OSX, they could homebrew install it, or they could use the system one, probably.

But they're probably gonna work on other ones, so they're gonna need some like C Python manager, okay.

Then they're gonna need a virtual environment manager.

Then they're gonna need to know where on their machine the virtual environment manager is gonna install all the libraries because then they're gonna want to wire up their editor so that it can find that stuff, okay.

There was so much garbage worthless knowledge about how to set up a stupid environment that that person is never gonna need again.

And it's hard not to look at that and be like, geez, if this were a Rust project, you just run cargo build and walk away.

The tooling in Rust is phenomenal.

And it's not just that one-time pain of setting it up for the first time.

It's like all this knowledge that I have about setting up Python environments, I don't consider that to be high value knowledge for me.

And when something goes wrong, I have to call on that knowledge to fix it.

And I would love to have people contribute and run maybe one or two commands, walk away for a year, come back, run a couple of commands like that's gorgeous.

Everybody should have that.

Number one, absolutely, in language I've ever encountered the tooling, phenomenal. - Yeah, I've had a pretty good experience with it too.

Just in the last couple of days, I updated this Rust program.

I wrote a couple of years ago, that's just like a hack that I use locally to find all the devices on my network.

And I hadn't touched it for literally almost two years.

And it was so I went back to it and it didn't run, but I had to, once I updated stuff, it wouldn't compile, but it was mostly because the clap library that parses arguments, it's changed considerably. - And the compiler told you you got to fix all these things, right? - Yeah, so it was mostly just a matter of changing those, you know, changing the way that I was parsing the arguments and then everything ran again.

So it puzzles me though, why other languages aren't as good. 100% agree with that.

Why in the world doesn't everybody have this stuff?

I see people in the Python world arguing all the time, can we just have what they have in the Rust world?

And they've got like a dozen people who are all simultaneously trying to achieve that vision.

And that means it's probably not gonna happen. (laughs) How in the world did they get such phenomenal tooling?

And, you know, we talked about the type system, we talked about the compiler a little bit.

When you go back and you wanna refactor or you wanna modify a dependency, this is junk that I have to do that people often kind of hand wave away at work.

This week there's a new CVE in the very, very famous Request Library in Python.

So I need to bump the Request Library.

Some of my apps don't even have this listed as a dependency.

It's a transit of dependency, meaning it's a dependency of the apps dependency.

Okay, I'll bump it.

Things will probably be fine.

But what if they're not?

And I try to explain it to people who haven't, you've worked on these Rust apps.

Again, this is at work.

I'll say, look, you see this library right here?

I could bump the major version.

I could go from version four to version 50.

And the compiler will tell me what's wrong.

And it is true that there may be some semantic difference.

Like maybe the maintainers of that app completely changed its behavior and kept all the types exactly the same.

That'd be pretty nefarious behavior.

It's extremely what I would call unlikely behavior.

In general, the compiler will tell me change these things and I compile the app and boom, it works again.

I have none of that confidence in a Python application.

And I'm not talking about my code.

I'm talking about dependencies, the scariest part of maintaining a larger Python application from my perspective. - Yeah, definitely requires a different level of testing and faith.

One last category for me is a very high quality libraries and applications in Rust.

I use RIPGREP, probably dozens of times a day.

I don't think that's an exaggeration.

It's embedded in VS Code.

I use it on the command line.

I'm always searching for stuff.

There's a new version of Htop called Btop.

I just found out about the other day.

Rayon for multi-processing, for threading things.

It's amazing.

Tokyo, I know people are a little bit, there's some consternation about async and rust, but I find Tokyo to be a pretty cool async runtime.

These are high quality stuff.

We use SQLX.

SQLX will check at compile time, whether your queries are valid by actually asking the database, hey, is this a valid query?

Like that's kind of cool actually. - Yeah, I think the only probably small issue that I've run into is that there are some things where people have not built an official API for something. - Yeah, like Kafka, you had to use Rd, libRD Kafka, like you got to call out to C libraries and stuff. - Yeah, I was looking at GCP.

I think they use Firebase for their, sort of their NoSQL database, and they have a bunch of official APIs for it.

It's Python and Go and a couple other things.

And there is one for Rust, but it's not something that they-- - It's unofficial. - Yeah. - I'm gonna give you a quote right now.

This is Carol Nichols again.

She actually gave us talk on ACM and it's about Rust.

And she had this really interesting analogy with the history of trains.

I had never heard this, never thought about it.

Again, I really like listening to Carol Nichols.

If you're interested in Rust, I would try to seek out some of her material talks, books, articles.

She describes how it used to be super dangerous to work on trains in the 19th century, because you had to apply a break on each car.

I think I'm describing how she said, and they eventually invented these air brakes so you could inflate this bladder that would apply a brake, breaking pressure, and it would work across the entire train.

And people were really critical of the air brakes at the time.

They were like, "I'm gonna let some pillows stop a train.

Are you nuts?"

And then what happened was, over time, passengers on the trains were like, "Wow, those are way safer."

And so they would seek out the safer trains with the air brakes.

And so then all trains adopted this practice.

She says, "This is similar to software engineers, that there's a kind of arrogance in software engineering where we do not consider how other fields, advanced systems, other fields are analogous to what we see too."

We just sort of go, "Oh, whatever.

Your language may not be as safe, C is Rust, whatever, but I can still program in a safe way."

She says, "Rust is a systems language design for the next 40 years."

Now, I really like what she's describing here.

I think it's fascinating.

I feel a little guilty because I don't think it applies to me.

One, I don't care that much about memory safety.

I'm normally writing Python, not commonly a concern.

And two, I don't think I want to write systems.

Like, I don't think I need a systems language.

So I really like what she says, but then I think, wait a minute, am I wrong for wanting to write Rust?

Because I don't have the problems she's saying, it's great at solving.

Can you make me feel better? - Every language is going to have some feature that you probably don't care about or use that frequently.

I think that's at least general purpose languages.

That's almost always the case, but I don't think it's necessarily bad that it has, in this particular case, I know you don't like this term, but Rust advocates use this zero cost abstraction term quite frequently in reference to Rust features.

And I think the nice thing about these memory safety and concurrency features is that they're not getting in your way.

So they're not making things slower or involving some runtime that has potentially unpredictable behavior.

So if that isn't important to you, at least it's not something that's adding to your cognitive load. - Yeah, I guess I just, I really like writing language and I expect that people will come to me and they have and say, and at work and say, "Well, why do you want to write this web server "in Rust so we could just write it in Python?"

And I feel like I can justify internally the argument, but I can't say to somebody else, "Oh, you should do that too."

I feel like I can produce an artifact that I have to think about less ultimately in the long run.

The compiler will help me not make mistakes.

It'll also be pretty fast, the tooling's phenomenal.

And I actually don't think it's gonna be too much slower for me to produce this app as it would be compared to Python.

Now that's maybe arrogant or maybe I'm deceiving myself.

And maybe not true for other people.

It takes effort to use, to learn this language and to use it.

And there is a learning curve as you mentioned.

I guess maybe the other way to say this is, why would you say to somebody, "Don't use Rust"?

Why not use the language?

Do you have any examples for what you would, when you would say not to use it? - Well, I think it's not a good language for experimentation.

So, and what I mean by that is, one of the reasons I think why Python has become so successful as both a general purpose language and as kind of a glue language is that, you can start up the ripple and just start typing stuff into it and do useful things.

Or you can use it in notebook form and do useful things.

And it's really much harder to do that in Rust.

You can write simple programs, but you still have to kind of go through these steps of getting the syntax right and compiling it and making sure it works and so forth.

And so it's not something you can just sort of fire up and load something in and start slicing and dicing.

It's something where you need to think a little bit. - In like a ripple style of fast feedback, right?

So prototyping, people often say it's not that easy to prototype stuff in as opposed to say maybe Python. - Yeah, I think that's true.

I think it also has a reputation of being slow to compile.

I don't know that that's really a major issue for most people these days, but compared to say see it's supposed to be slow to compile. - I mean, I have CI pipelines that'll take 20 minutes to run sometimes in Rust versus my Python ones that typically run in three minutes. - Yeah, yeah, so that might be an issue in certain circumstances.

I think you do have to sort of confess that Rust is not the easiest language to learn. - Yeah, I mean, the memory model is hard.

There's that one blog, which I really liked, which is learning Rust through too many double-link lists.

It's like building double-link lists or trees or recursive tree structures like grass.

These things are hard to write.

Libraries can be tough.

You mentioned already, you were talking about talking to Firebase and you have to go out and find something.

Not only are there often not enough libraries 'cause it's so young, sometimes learning to use the libraries can be tricky.

I found that the easiest way for me to learn to use libraries is to often go and read the code.

Is that a model that I could suggest to other people?

Probably not.

You gotta be pretty comfortable to learn to use the library by reading its code, I would say.

Not that I'm claiming to have extreme comfort. - This is something I used to experience with Haskell too, is that they give you an API documentation.

It tells you what types that thing takes and you're on your own sucker. (laughing) - Yeah. - Yeah. - And so yeah, I'm kind of the same way, even when I'm using something that has decent documentation, I'm likely to refer to a stack overflow item rather than the actual official documentation. - I've probably said this three or four times already in this conversation, but all this emphasis on quote systems programming, sometimes it makes me think, am I in the right room?

(laughing) - Yeah, I don't know.

I think when I started to use Rust, it was hard for, like I said, one of the first things I wrote was this utility to scan my network.

And it was really hard for me to think in terms of, I wanna write a web app with this, or I wanna do, I wanna load data frames and do analysis with this.

It just didn't seem like the right thing.

I think I've come around a lot on that, especially because of the web apps that we've built for work.

But there is kind of a weird dichotomy between the people who wanna use Rust as, a systems level replacement for C and people who wanna use it more generally. - I wanna give you one last quote.

This is from John Jingset.

He's the author of a book called Rust for Rustations.

I have it on my bookshelf.

I like this book.

He also does a video series called "Crust of Rust."

He's pretty well known in the Rust world.

He was in an interview and he says something that I really sympathize with.

If you're writing code in Python, there are a whole host of problems.

The language lets you get away with not thinking about.

That is until they come back to bite you later.

And he mostly means the runtime.

That might come up in the form of bugs due to dynamic typing, concurrency issues that only crop up during heavy load, performance issues due to lack of careful memory management.

And John Jingset calls this, quote, reactive development.

You build something that kinda works at first and then go round and round fixing issues as you discover them.

So it's reactive.

And he goes on to say, Rust is different because it forces you to be proactive.

An apt quote from RustConf this year was that Rust, quote, gives you the hangover first.

As a developer, you're forced to make explicit decisions about your run programs, runtime behavior, John Jingset saying.

And you're forced to ensure that fairly large classes of bugs do not exist in your program.

All before the compiler will accept your source code as valid.

And that's something that developers need to learn along with the associated skill of debugging a compile time as opposed to a runtime as they do in other languages.

It's that change to the development process that causes much of though not all of, Rust's steeper learning curve.

So that's a quote from an interview with John Jingset and the contrast between reactive development, bugs at runtime versus proactive development, which is battling the compiler to have something that will compile.

And then once you've battled the compiler, once you've thought through the types you wanna use for your program, once you've got a working compiled program, there's this feeling of assurance like, wow, it's probably gonna really work.

I remember the first couple of Rust programs I'd deployed it in production.

I was like, well, okay, I kind of fought it.

I had some concerns.

I didn't know certain lower level things.

How are we really gonna handle, I don't know, like HTTP timeouts, for example, or just things like this, right?

And the longer those apps run, the longer I went noticing that I really didn't have a high error count coming out of them.

And sometimes they were like, oh, I didn't consider this thing.

I need to do that.

There's a bug related to that.

They did have some bugs, but I found what he's describing, what John Jenks has describing, to be accurate in my own case.

I was doing more upfront debugging, and I was eliminating classes of errors before they ever made it into the runtime program.

And this is very powerful.

And it's also, as he says, part of the learning curve.

Like you gotta put a lot of effort into working with this compiler.

But if you do, you may be rewarded.

What do you think?

Sometimes people in the Haskell world say, well, if it compiles, it works. (laughing) Yeah, which is, I think, a desirable goal, but probably not 100% true.

I've already managed to write REST programs that would compile and did completely unpredictable things. (laughing) You can write deadlocks if you want.

You just have a couple of locks.

I totally get what he's saying.

And I think it's hard to disagree with, but I don't like the implication that REST is some sort of bad tasting medicine that you have to ingest to do things well.

I don't really think it's that, I don't really don't think it's that big of a-- You're saying it tastes great. (laughing) Well, that line about, it gives you the hangover first.

For instance, I think that's really funny.

And I like the way that it, I like the metaphor, but I don't want people to think that REST is sort of this constant fight against the compiler.

There is some of that beginning and there's this famous thing about fighting the borrow checker in particular.

So it does take some time to get used to, but I think once you get used to it, it's not really like eating your vegetables.

It really is kind of fun once you get to the point where some of this stuff is comfortable.

I agree with you on that one.

Yep.

And in fact, what he's describing isn't, I'm gonna, the feedback loops pretty quick for me.

I'm gonna be in my editor, I've got Rust Analyzer, it's gonna run cargo check, it's pretty fast.

I could type a thing into my editor and it might be something that won't compile because I'm violating a memory constraint.

I'm assuming I have ownership when I just have a reference to a thing, I'm borrowing it and right away I'll get a red underline and I'll go, "Oh, whoops," and I'll immediately fix it.

And so that fighting the borrow checker really, you know, like because I have expectations around how it works now, I can fix, it's like, I don't even remember the moments where I had those errors.

I mean, I have had some weird ones in the past, which there's very extravagant types, maybe in libraries and there's some weird lifetimes in there and I'm looking at the type like, "Well, okay, how do I make one of those in order to call this thing?"

But those experiences are not too common.

I do agree with his idea overall.

It's proactive.

I get nervous anytime in the Haskell world, people would say, "If it compiles, it works, it's correct."

That made me nervous because I could have completely semantically wrong code that compiles, right?

But I also find this to be a good assessment of like what I experienced in the language.

And I like how you said it.

It's not like swallowing your medicine.

It's kind of fun, it's good.

It's a useful practice to think about memory in this way and it's good to think about your type system to guide you in this way.

I guess I would say if somebody listening to this has never used it or tried to learn it and you see all this hype and you think, "Wow, it's trendy."

It's legitimately a cool language and I would recommend it. - There's this tendency I had when I first started using it where, so I use VS Code and VS Code has some tools that plug into the editor to sort of make, make the type system a little bit easier to deal with and stuff like that.

But a lot of times you get these error messages that pop up directly in the editor.

And I think when I first started using the language I was a little unfamiliar with the terminology and so my tendency was just to sort of like, "Change this thing and see what that does."

And change this thing and see what that does.

And one thing that's, I think I've gotten better at and which helps a lot is if you actually read the error messages, they're pretty informative. - They are, yeah.

And they've gotten better over time too.

Plus VS Code with Rust, you can just click that little quick fix button and sometimes it'll just fix your code for you.

That's a weird experience. - Yeah, it's, they've got that wired into Copilot now too.

So when I get really desperate, I just let Copilot write the code for me.

Although Copilot gave me a wrong answer this morning, which kind of annoyed me. - What?

Okay, so overall summation from my perspective, I like Rust, I don't feel like I'm getting the, oh, I'm using a compiled language advantages that you're talking about, but I do think in terms of memory, I'm mostly like it 'cause of type system, 'cause of how fast it is, because of the tooling and the libraries, side benefit, I do like thinking in terms of memory model that it provides, but I still feel, as I've mentioned a few times this conversation, if somebody comes to me and say, "Well, you should just use Python."

Like I still feel like, "Ah, I wanna use this other language.

It's got these cool benefits."

I feel like I can't quite, based on the arguments who will give out in the broader industry, I can't just map those to what I'm doing and say, "Well, they say you should use it for systems development, systems programming."

'Cause someone's gonna look at me and go, "You're not a systems programmer." - Yeah, well, there's, in terms of using a specific language, there's also lots of cultural and organizational issues.

We've had this come up where we've said, "Hey, we wanna use Rust for this."

And people have said, "Yeah, but you are the only people who know how to use Rust, and we're not gonna be able to hire people to maintain this and et cetera, et cetera."

And those are arguments that need to be considered.

It is harder to hire Rust programmers.

And if you are trying to introduce it to a newer organization, it will take some time for people to pick it up. - All right, thanks for chatting with me about it this week, Mike.

Glad to see you back from your jaunt across the country.

Welcome back to California. - Glad to be back. - All right, this has been Picture Recoding with Eric Aker and Mike Mall.

Thanks for tuning in with us.

We will see you again next week. - See you next time. - Bye-bye. (upbeat music) [MUSIC]