Subscribe
Share
Share
Embed
John is proposing learning Rust to enhance Gophers programming knowledge. I do enjoy learning new thing personally, Rust always has been or at least seems to required an extra effort to get started with. John is trying to make it more approachable.
Links:
Links:
If you enjoy the show the best way to support it is by sharing and talking about it to your circle and if you can by purchasing my courses (50% off for listeners of this show). Build SaaS apps in Go and Build a Google Analytics in Go.
Creators & Guests
What is go podcast()?
15 minutes news, tips, and tricks on the Go programming language.
Hello there. I'm Dominic Senthiat and you're listening to Go Podcast. Today I talk with John Arundel on Rust, actually. Hey. So, yes.
Dominic:So let's let me talk, let me start by, reintroducing the fact that we have this Go podcast channel on the Go for Slack. So if you are, you know, out there in the Go for Slack, please join. We are a couple, already there. The channel is fairly new. So, I mean, I'm trying to build something.
Dominic:So, I would like to ask some question before I I do some interviews and what So I mean, we, we could have, we could have some fun. I'm not the best one, I would I would admit, at, managing a, I don't know, things like that. But, yeah, trying to do something here, to help the podcast. So today, yeah, we will talk about Rust. And why Rust?
Dominic:Well, I mean, I'm on the camp of people that just think that, you know, learning new things is very, very helpful in anyone's journey to, you know, to just getting better at programming. So that that's a that, you know, that that that's nothing more than that. It's just, you know, it's just that I I do enjoy some, some new learning. For me Rust is is always difficult. I I never really pass this, this first, initial, you know, effort that it requires to, to get get started with.
Dominic:But, but, yeah, John John Arundel is talking about that. So on that I will leave you with the interview. Hey, gopher. So I am with John Arundel today. So thank you, John, for joining for the second time.
John:Well, thanks for having me back. Great to be here.
Dominic:Yeah. We will have a, you know, maybe a a stranger subject today. Maybe we, you know, we will diverge a little bit on Rust because I've I've followed you lately on Twitter and I've, you know, I was intrigued to see, wow, what's what's going on with John? There there is so many Rust related content these days. So, yeah.
Dominic:I reached out and, you know, can you talk a little bit, what's going on at the moment?
John:Yeah. I have gone down a bit of a rabbit hole with Rust recently. Apparently, that's coming across right, especially if you follow me on Twitter.
Dominic:Oh, yeah. Totally.
John:So this is, you know, we we normally talk about Go here and that's fine. And I apart from writing books on Go, as we talked about last time, I also teach Go. And more and more of my students started saying to me, hey, are you interested in Rust? You know, because it seems kinda cool. And they were learning Rust and asking me for help with it.
John:And it's something that I've looked at in the past. I'm sure you have as well. What was your have you did you sort of get get seduced by by Rust hype or?
Dominic:Yes. I did. But, I hit a wall pretty quickly to be you know, if I'm completely honest, I did not pursue, the amount of energy that I needed to to, you know, just just pass the, I I would not say the yellow world. It's it's it's not that. But but just, you know, just past the initial 1 week, 2 weeks, I got discouraged, to be frank.
John:Yeah. I I had exactly the same experience. I'm sure everybody listening has they've looked at Rust. I sort of bounced off it a couple of times. It's maybe maybe the way to put it.
John:I mean, I don't know about you, but I think Go really appeals to some people who, they're computer geeks like me and they love programming and different kinds of programming languages and it has its own very charming nature, which you've talked about many times. But it also appeals to people who kinda just wanna get stuff done. Right? You know, they they don't want to become a PhD in compiler theory or something like this or maybe don't even have a computer science background, but they need to write some code. They need to get some service running or write some command line tool or something.
John:And Go is appealing to those people. Right? Because it's a pretty small language, not much to learn, not not too much syntax even.
Dominic:Yes. I I almost wondered at some point when when I tried Rust myself. And I've been I've been doing Go for a long time now. And I almost wonder and ask myself, you know, is is, you know, is Go made me a little bit afraid of the unsimple languages out there. Though yeah.
Dominic:I mean I mean, I think I think it's a it's a fair question to ask.
John:Yeah. It really is. Yeah, I think I I I felt a bit the same in that, you know, I really like the aspect of Go that there's very little to it. You know, you can learn it quite quickly because then it takes a lifetime to get good at writing software with it. That's true of any language.
John:Software is hard. But it's I think just like you, I sort of felt maybe has ghost spoiled me for understanding complicated languages? I mean, there's a place for complicated languages too. Right? C plus plus is still around, apparently.
John:But, yeah. And I looked at it. And as, I'm sure we've talked about before, what I often do in my mentoring and teaching sessions is just reading code with people and talking about it. That's a fantastic way to learn. Isn't it?
Dominic:Yes. So so are you are you saying that it's a little bit easier to read Rust at first than than to write a new program?
John:Yeah. And I think, you know, we we start with some of my students, we started doing some code reading in Rust in the same way that we do in Go. And I was pleasantly surprised because I sort of thought, well, I don't really know much about Rust, but we can kind of understand this.
Dominic:Mhmm. And
John:we read through a couple of things, random projects that we found. And we were sort of even though we're a bit frightened by a lot of angle brackets and question marks and ampersands, you know, nonetheless, we could still sort of make out roughly what was going on, in the same way that I guess any program I can in any language, you can sort of see like, oh, this is a loop. This is a function. Bit confused about some of the more abstruse stuff that's happening, but never mind. You can get the overall sense of it.
John:And I thought, this is encouraging, you know. Maybe I am smart enough to understand Rust, which would be great. And I I think I just kind of got the bug and started looking into it a bit more and reading the Rust book and other people's books and reading more code, trying to write programs myself. And as you said, that's a lot harder, but sort of in a fun way, I think.
Dominic:Right. Yeah. For, you know, for me, another thing you know, other than the hard part, I think I think people is, you know, all all aware of you know, ROS is hard. But another another problem that I had myself is I found myself how can I say that? You know, the kind of of programs that that Ross would would would be extremely good at, it's not something that I tend to write myself a lot.
Dominic:Right. So my question is is is more like, you know, what what are you doing at the beginning? Because at the beginning well, if you learn a little bit like me, I I like to I like to write, you know, some small CLI thing at first. You know, may maybe a cat program and things like that. You know, try trying to replicate the the GNU core utils sometimes in like so are you are you doing that as well in Rust?
Dominic:And and and once you get a little bit more experience, what are you building with Rust?
John:Right. Well, that that's a great point. I mean, when I first learned Go, I was very enthusiastic about it. So Go is the greatest language ever. It's all you need.
John:You know, if you understand Go, that's it. You can write any program. It's Turing complete, so no problem. And people love to criticize Go on the Internet, as you know. Gosh, do they love to criticize it.
John:And people would say things like, you know, Go is a bad language because it has garbage collection.
Dominic:Mhmm.
John:So, therefore, it's not suitable for real time applications or really high performance or anything where you need predictable latency, operating systems, phone switches, things like that. And and my killer response was, well, I'm not writing an operating system. Yep. I'm not writing phone switches or a spacecraft control software, you know. Call me when I when I am writing that stuff.
John:Sure. We'll talk about other languages. But for now, go is good enough. And I'm still not writing operating systems, but I I sort of feel like maybe I could now, you know, with Ross. Like, yeah, I agree.
John:Go wouldn't be a good choice for that necessarily. And these things are very tribal, aren't they? So let's say this one thing that people in people who do go often seem to be a bit triggered by mentions of Rust. Maybe they feel it's been too enthusiastically hyped. Perhaps people in the Rust community feel the same way about Go.
John:I don't know. But there's some kind of feeling that these languages are sort of uncomfortably adjacent in some way, isn't it? Maybe they're butting into each other a little bit or people can feel they're competing for developers or mindshare or something like that. I don't really think that's true though. Actually, what I think now that I know a bit about both of them is that Rust and Go were a really perfect complement for one another.
Dominic:Yeah. That's, yeah. That that's also my my vision, but, you know, with very, very limited experience in RAS. But, yeah, I'm I'm
John:It's not something you often hear, is it?
Dominic:No. No. No. Exactly. But I'm I'm a huge huge, you know, a programming language fan.
Dominic:I mean, I I did I did a small, small detour in in 2018 in Elm, to be frank. That was my first functional programming experience. I I enjoyed that so much.
John:Yeah. That's really cool.
Dominic:Yeah. So, you know, that that's that's a little bit, a small small aspect why I was, you know, attracted by Rust as well. You know, I I really, really enjoy Go. But, you know, we we have to be frank that at some time, there's a little bit of verbosity that can be expressed a little bit differently, you know, with a different language. And Russ is, from what I can see sometimes, a little bit more expressive.
John:Yeah. I think it's, you know, in some ways, Rust and Go are like best friends in that they there's certain things they both really care about. You know, safety, correctness, performance even, for different values of the word performance. Mhmm. You know, I think I don't know about you, but it seems to me like both Rust and Go in their designs are kind of a reaction to what's wrong with traditional languages.
John:That's, you know, naming no names, but c plus plus is the one that everybody thinks of in this space. Just because that that language has got so big and has so many different ways of doing things, and it takes so much stuff to learn. And there's also so many potential foot guns that you have to learn to avoid. You know, somebody who's been doing c plus plus professionally for 20 years won't make silly mistakes with memory and things like that. But, you know, if you have less experience than that, you might well do that.
John:It it feels really appealing to just think, well, couldn't the compiler know that stuff? You know, like, if if this pointer is nil, you know, doesn't the compiler know that? Like, can't it prevent me from dereferencing that thing unsafely? Yeah. It really can.
Dominic:Right. I I wonder sometimes, and I I'd like to to know your opinion about that because it's it's a little bit, I I think is what you you are saying at the moment is that do you do you think that it's very hard for companies that that do have c plus plus code bases to, you know, to get to get I don't know. Maybe not junior developer, but but just new, you know, new developers kind of knocking at their doors and saying, you know what? I I never did c plus plus in my life, but it seems to be great. I'd like to to to know that.
Dominic:So do you think that this this is really where RAS could could live at some point? Because those companies at some point, the you know, if we do if we draw a parallel with with Cobble, for example. In in Quebec, we we still have a lot of financial institution that are still running on Cobble. And Yeah. And I have talked with my, you know, my wife, Hunt.
Dominic:And and, you know, she they they just can't find new candidates to maintain the system. So they they had to switch at some point. Do you do you do you see Rust, being that for c plus plus potentially?
John:Yeah. I think so. Perhaps. And I mean, despite what we said about Rust and Go having a lot of values in common, they they do diverge sharply in terms of how they actually tackle that stuff. Right?
John:You know, like, if you think the designers of Go said, it's really slow to compile huge c plus plus code bases because of various things about c plus plus that you can't change. You know, you can only speed up the compiler so much. And so they said, what if we made the language very simple, easy to parse, easy to compile, no circular dependencies, things like that. So we can really build it fast. Maybe the compiled code doesn't run as fast as c code would, but often we don't care.
John:Right? You know, in network applications, the speed of the code is not the bottleneck. It's the network probably. Well, latency of something else, you know, devices, things like that. So where performance isn't absolutely critical, a small language that's easy to learn and easy to compile is absolutely perfect, and it's still memory safe.
John:So the Rust folks kinda went the other way. Yeah. Like, hugely. They just said, you know, let's let's take c plus plus take take out the unsafe things from it or just make people, you know, mark it inside an unsafe box. So you can still do everything in Rust that you can do in c.
John:You just have to say, hey, I know this is unsafe. You know, like, it's on me to make sure it's actually okay to do that. The compiler can't guarantee it for you. But when that's not the case, the compiler can help you a lot. And I suppose the downside of that is Rust is a pretty big language that has everything in.
John:You know, I think with Go they they took c and threw out everything that they could possibly throw out. And with rust, they put everything in that they could put in. Right. And then they they took some things out again because they decided that's not a bad idea. Actually, if we look at the history of rust, it's really weird.
John:I mean, it's changed so much over a decade or so. You used you used to have a garbage collector, not anymore.
Dominic:Really? Wow.
John:Yeah. No. You used to have all sorts of weird things. So it's changed a lot. But another way to look at that is it's been extensively hacked on, refined, changed, and polished by some incredibly smart people for years years years.
John:And now what we have is something pretty excellent. Certainly worth the time of any programmer to look at. I'm not saying it's for everyone.
Dominic:Yeah.
John:But certainly worth spending a few minutes looking into or playing around with, isn't it? And and and resisting that initial sort of bounce off because it's unfamiliar. I like to say Rust isn't difficult, it's just different, you know. And and that's sort of the point. If it wasn't different from what we already have, there'd be no point to it.
Dominic:Yeah. Sure. That that's one aspect that that seems to be worth it. I mean, at some point, if you if you continue and pursue this this this learning curve, at some point, you yes. You do you do acquire a lot of, you know, background knowledge that that you just don't really need to have with with Go.
John:Yeah. And I think, people who who like programming, which I know includes you and me and probably most people listening, you know, and that we enjoy doing it for the fun of it as well as it solves problems we have or we can earn money doing it and so forth. Those are those are great bonuses, of course, but it's also intellectual fun. So it's a creative activity. You know, it's expressive.
John:We we like to figure out ways to solve problems and then try to express those in code. In Go, that that can be sort of it it can feel limiting because so few facilities in the language. And there's generally only one sensible way to do something in Go, which is good. Mhmm. You know, especially if you have to teach it.
John:But sometimes it feels a bit like, I would love to solve this in a functional way or something and it just Go just doesn't suit itself to that particular pattern or it's, you know, it becomes really awkward to do something in a certain way and Go and you just think, yeah, the language is steering me away from this way of solving it. That's fine. Very opinionated. But in Rust, it's very much up to you and you sort of think you can do it this way or that way. You could use iterators or a functional style, or you can even do with inline assembly language, you know, whatever you like.
Dominic:Right. Right.
John:It has all the toys. And that's why why I think people find it really fun. And from an advocacy point of view, they say, yeah, but the performance, the correctness, the memory safety. But what they're really thinking is this is super fun.
Dominic:Right. Right. Have you have you noticed a big difference? So let's say, you know, in Go we do have data races and things like that. And concurrency, even though it's easy, you know, it's still not very, very easy to do.
Dominic:And you can still shoot yourself in the foot in in Go even though, you know, we all love channels and whatnot. But Yeah. Have you seen a huge difference with with the Rust compiler that you you you said to yourself, you know, it it really it it really noticed something that I did there which which might have have gone into production or or in runtime at some point in Go potentially. Is it is it is it that good? That that copilot copilot maybe?
Dominic:Not not in in the sense of the AI, but, I mean, is it truly helpful?
John:Yeah. I think so. That's a great point. I mean, like I say, it's, what I'm not saying is you should all stop doing Go right now. No.
John:No. No. Take up Rust. You know, it's not a zero sum game. That's the point, isn't it?
John:There are lots of languages for lots of tasks. Different people enjoy them, and that's fine. And you can know more than one thing. You can have more than one skill. In fact, that's a really good idea.
Dominic:Right.
John:A monoculture is a bad thing, isn't it? Especially in the tech world where things change so quickly. It's good to have multiple strings to your bow. And also because different programming languages teach you different ways of thinking about problems. And this is sort of your point, isn't it?
John:So a lot of the time, we're not particularly worried about performance. Computers are very fast. Compiled programs are very fast. Networks are relatively slow. What we want is a language that's easy to learn, relatively easy to understand.
John:Programmers are cheap, to put it bluntly, and cheap to train. And that's great. So that actually covers, you know, 70, 80% of use cases probably. But then there's the rest. You know, somebody actually needs to write system software, operating systems and whatnot, embedded software, things like this.
John:And you need a different kind of language for that. Like, people do do this with Go, but it's a bit awkward. So you need something in that space. And ideally, it would be something that sort of shares those values about safety and correctness and things. And I think Rust is that.
John:And one thing that's really different about Rust, not just the angle bracket sort of thing, you know, that's a superficial level. But on a deep level, the way Rust thinks about data is just fundamentally different to basically every other language. In the sense that, you know, what why do we find Go appealing in some ways? One of them, I think, is it lets us forget that there's actually a physical machine involved. You know, we don't have to know that this is x 86 and there are certain assembly instructions available, whatever the memory word has a certain size.
John:We can ignore those details. We just say, let's abstract over those. Let's just say, I want to write a loop printing hello world or whatever it is. I want to deal in terms of strings and things like that. Don't want to worry about the machine details.
John:And that's terrific. Very valuable for programmers. On the other hand, some people say, but I want to I want to get to the details of the machine because I want to use the machine to its maximum capacity. You know, I want to access the special instructions that the CPU has or I want to take advantage of packing data efficiently in memory or something like that. So Rust gives you that.
John:It says, yeah, you can twiddle the bits and bytes to your heart's content. And, yeah, the compiler will also produce very efficient machine code for you. You can use abstract things like iterators, and they all just compile away. You know, there's no function cause. It just it just compiles to the kind of tight assembler loop that somebody would write by hand.
John:So that's very nice, but totally different approaches, of course. And one of one of the ways that RASP forces you to confront the fact that you have a real physical computer is you need to work with memory. Chucking data around in your program is not free. Right? Somebody has to allocate that memory.
John:That that takes time. Memory allocators do things. That's complicated code. You you have to have an allocator. You have to call allocate.
John:You have to get some of that memory might not be available. The operating system has to manage virtual memory and so forth. You have to deallocate memory when you're done with it, all of that. Go lets you entirely forget about all of that stuff, pretty much. Right?
John:You're just like, oh, I'll just declare some variable. Yeah. Which is fantastic. On the other hand, you know, Rust says, well, hold on there. You know, not so fast.
John:Like, are you absolutely sure you want to allocate that memory? And also, are you going to hand out pointers to it willy nilly to people? You know, you're gonna start some thread, hand the pointer to this data, and then you're gonna mutate it yourself. What happens if you both try to mutate it at once? Or
Dominic:Mhmm.
John:What if the other threads writing to it while you're reading from it? Isn't something bad gonna happen? Rust says, yeah. It absolutely will. And that is the kind of bug that we run into in Go all the time, isn't it?
John:You you can hardly write Go without running into null pointer panics.
Dominic:Yeah.
John:Or to a lesser extent, data races and things like this. The problem is your your program probably has data races. It's just you don't know about them because it's just silently doing the wrong thing. Yeah. The best case is that it panics.
John:The worst case is it carries on and produces the wrong result.
Dominic:Yeah.
John:In Rust, your program just doesn't compile. So that's encouraging. You know, you you don't run into that problem because the Rust compiler just says, look, if you had 2 mutable references to this thing live in different threads, you could have a data race. So I'm just not gonna let you do that. Yeah.
John:That impossible.
Dominic:That's a huge benefit. How how many I mean, let's imagine. So when, when you were, when you were starting to discover Rust, how many of this new mental model you, you had to, to think about? You know, let's say you're, you're building something. So usually in Go, we, you know, we structure our data.
Dominic:We do we do a couple of algorithmic things. And so like you said, we don't really think about the underlying memory. But how many I mean, how many percentage of your brain is dedicated now to to do what the garbage collector is doing?
John:Well, less and less over time because yeah. At first, it was brutal because I was just trying to do things in the same way that I would in a Go program or any language. Suppose you've got some string that maybe you read from a file, and then you wanna pass it to some function to do some processing on that. What's actually happening under the hood there? You know, is that string being copied?
John:Who knows? I mean, the thing is it might be. You know. It it wouldn't in Go, but that's not obvious to people who don't know the semantics of function calls and things like this or that strings are actually smart pointers. But in Rust, it's very explicit.
John:If it's something that is cheaply copied, like an integer or whatever, sure, it'll just copy it. On the other hand, if it's something like a string that could potentially be a big allocation of memory and an unbounded time to copy that string, it just says, no, you need to be explicit now about whether you want me to clone that string or do you want to take a reference to it. Oh, you want to reference? Okay. Well, is that a mutable reference or a read only one?
John:Like, just having immutable values is terrific, isn't it? Because most of the time in a program, that's what you want. And, sadly, Go doesn't have that. That would be a great add on. But Rust has this, and everything is immutable by default.
John:And you have to opt in if you say, yeah, I want to mutate this thing. And if you hand out a mutable reference to someone, it automatically locks it for you, you know. Somebody else sort of has the keys to it right now, if you like. And even you can't modify it yourself even though you're the owner because Rust says that might not be safe, which is great. But on the other hand, that that means almost every program you try to write in Rust first time around just doesn't compile.
John:And you're like, why will it not accept this? This is obviously correct. Yeah. And the compiler says, no, no, no. Maybe it's sound, maybe it's not.
John:But I can't prove it, you know, just by looking at the code. So therefore, you have to do something else. So to answer your question, you know, I I haven't the compiler hasn't directly saved me from writing things like data races or memory safety bugs because I just can't get close to that. You know, I can't design the program that way. It doesn't work in Rust.
John:I have to fundamentally rethink what I'm doing. What what data do I have? Who owns it? How long does it live? When do I need to mutate it?
John:When will it not be valid anymore? All of these kind of questions I suddenly have to answer. But they existed in the Go program as well. It's just Go kind of punts on it and just says, yeah, whatever. Right.
John:It'll be fine. Right?
Dominic:That's scary to hear though.
John:Yeah. Well, that that's exactly the point is that now when I come back to writing Go, I'm thinking about it in a slightly different way thinking, would the Rust compiler accept this? Woah. Well, maybe I shouldn't be doing it.
Dominic:Interesting. Are are you and you you say, at some point, you you have some errors and things like that, then you you need to do something. Are are beginners in Rust not relying way too much on copy to to just, you know, work around the compiler errors and things like that at first?
John:Well, I
Dominic:think The clone. I'm sorry. The, you know, cloning things
John:Yeah. Absolutely. All over the place. Yeah. No.
John:That's right. I mean, a lot of times, that is fine. But I think Rust fundamentally wants you to rethink your idea of just sort of freely passing data around, maybe copying it, giving out references to it, that kind of thing. It says that all sorts of subtle bugs can arise from this, that even the compiler can't always save you from. So maybe maybe rethink that, you know.
John:Do you actually need the data to be structured in this way? You know, example is in in the blackjack game that I'm writing in Rust just for fun. There's a game object, makes sense, and the game has a deck that you deal the cards from. And so in the game, when you start the game, it deals cards to the player and the dealer. And maybe you ran out of cards.
John:Like, maybe there are no cards left in the deck. So what do you do? So I I instinctively wanted to write it so that when the deck deals its last card, it automatically replaces itself with a fresh new deck. But you can't really do that in rest because, you know, somebody has a mutable reference to the game, which contains a mutable reference to the deck. And if you're inside a method that's mutating the game, It also wants to call the method on the deck that mutates it and like that's just that just won't fly.
John:You try all different ways to do it and the compiler just won't let you do it any way around. And you think, maybe what I'm doing here, that actually doesn't make sense. And after a while, it does start to train your brain a bit to think about the problem a different way. And now now that you have that new brain architecture that can solve problems differently, you you can then apply it in any language.
Dominic:Right. Yeah. That that's what I was going to say. I mean, this this is extremely valuable, I think.
John:Yeah. I think so. And it's also just the fact that, there's a kind of a peer pressure about this or lack of peer pressure in there. If other people in your language community don't seem particularly worried about potential problems, you tend to not worry about it either. They think, oh, those guys are smart.
John:If they're not worried about it, I shouldn't worry. In the RAS community, people really worry about these sort of things. I mean, that makes sense because they are writing software that controls vehicles, medical radiotherapy machines, things where lives are at stake. You know, They they really don't want to have bugs in their programs, so they're worrying about these things. I've started to worry about them as well.
John:You know, 40 years of writing software or whatever, and I've suddenly started to think, what if I have a bug though? You know, that could be really bad.
Dominic:Interesting. Yeah. Yeah. You you you you talk about that and I'm I'm like super pumped now. Probably probably going to to do something with but but at the at the same time, I mean, it seems just a couple of example that that you just gave.
Dominic:So, I mean, I'm I'm doing web development. This this, you know, this is my bread and butter. And and I I know that there is web development in Rust, but, you know, those those kind of things seems to be extremely interesting to me. Just work working on different, I don't know, you know, systems and whatnot. Just just, and and but but, yes, how do you how do you start?
Dominic:You you were mentioning that your your student were asking about Rust. So, you know, what what what it's like to start, in Rust for you? How do you approach, not scaring them or or letting them being discouraged? What what what what would be a couple of tricks that we could we could pass here?
John:Yeah. That's a great question. And I think it's, it really makes a difference where you're coming from in terms of what your first experience of Rust is. And if you come from c plus plus you're probably like, hey, this is easy. Right.
John:Or Or if you're coming from something like Python or Ruby, there's a lot of weird things for you to grapple with just from the fact this is a compiled language, you know, all of that. You'd have many of the same issues learning Go, wouldn't you? And I did. Perhaps you did too. But what so but it it seems like there's a lot of people going from Go to Rust.
John:I'm not aware of anyone going the other way, but that doesn't mean there aren't.
Dominic:Right.
John:They are. It's just I've I've got one foot in both worlds, if you like. So what I see is people who already know Go thinking, maybe it'd be a good idea to pick up Rust. From a career point of view, that might be a nice thing to have. And also, just from from a programming is fun perspective.
John:You know, this is a fun language with lots of toys, new ways of thinking about things. Let's learn it. This should be fun. And then bang, they run head on into a brick wall of angle brackets. Right.
John:And, also, you know, you you can read a paragraph or some learned article about Rust, and I just won't understand any of the words in it. You know, I'm just like, I I don't know what any of that means. But the thing is I can write Rust programs. So apparently, it's not necessary to understand that stuff. I mean, if if you like programming language theory and things like that, sure.
John:Great. You know, if you're a functional programming fan and you like things like Haskell and, you know, about higher order functions and higher kind of types and things like this, fantastic. You know, Rust is a playground for you. But also for people who just like to write command line tools, Like you said, you know, I think the first thing I wrote was cat or grep or
Dominic:something. Right. Right.
John:And it turns out that's perfectly straightforward. So this is the thing is that a lot of the Rust materials and books and tutorials that you see out there are sort of focused on it from this very academic minded point of view, computer science y point of view. That makes sense. Right? Because Rust is so cool from that perspective.
John:That's naturally what they wanna talk about. But what if you're someone who just says, look, I'm not a genius. Yeah. I'm also not dumb. In in my own case, I'm an extremely average programmer.
John:So I'm a good test case for this. Like, if I can understand Rust and write sensible programs, then anybody can. And it turns out I can, which is great. Yeah. And what so I think I'm starting to work towards figuring out a way of explaining Rust to people because it's it's how I eventually explained it to myself.
John:You know how it is if you read some tutorials or something and you get stuck on something or something you didn't understand. You try to read about it Mhmm. A few different ways to try out different experiments yourself. And suddenly, something makes sense and you're like, oh, I see now. That's actually not very difficult.
John:It just needed to be explained in the right words. And I'm starting to zero in on that. So I'm now writing a book, The Secrets of Rust Tools, available in early access, and people are liking it. And I think I'm trying to be very different from the other Rust books out there, of which there are many, some of them quite good. And the way in which my book is different, I think, in that it sort of doesn't assume that you already understand all of this complicated stuff.
John:It just I'm aiming not to tell people about stuff that's not relevant to them yet. Right? Mhmm. Like in Go, if someone doesn't need to know about pointers, you don't tell them about pointers until you need a pointer. Right.
John:Because there's just gonna be a whole load of complicated stuff that they're like, I don't understand that and I don't know why I need it. So I thought, how how far could we get in a Rust book explaining showing people how to write Rust programs with simple examples without introducing all sorts of complicated high level CS concepts. Right? And and it turns out quite a long way. I think I'm I'm up to chapter 6 now, and we still haven't used generics.
Dominic:Nice.
John:So that's good. Right? You know, I mean, we we secretly have in a way because you probably know in Rust, you you can take a parameter which is sort of generic by saying impl.
Dominic:Right?
John:Like, if you want something like a writer that you can write to, you can say, impl right. That's your parameter type. Now, really, that's just syntax trigger for the function being generic over some type t where t implements right. But but you don't have to put the angle brackets, which is nice. So there's that.
John:So so we're we're sort of saying, you know, let's just talk about the things in Rust that we need to. It turns out one of the first things we need to talk about is errors. Well, that's
Dominic:Yeah.
John:The first thing that I usually talk about anyway. Because if if you write some command line program, you know, you want to print a file or something, well, maybe the file doesn't exist. What do we do then?
Dominic:Mhmm.
John:Or or maybe you try to read from the file and there's an error reading from it. What are we gonna do about that? In tutorials, you always just see unwrap, I e, panic if there's any error. This is like in your Go program, just saying if o not equals nil, panic. Great.
John:Yeah. Sure. That works in a sense, but you wouldn't wouldn't really want your program to be like that. Yeah. Because, you know, these errors always happen, and users don't really want to see panic messages and stack traces and things.
John:So what are you actually gonna do? Probably return some error, print try to print a friendly message to the user, Not just panicking saying IO error, but saying, here's the file I was trying to read. Here's the problem I ran into trying to read it. Here's something you might like to try and do to fix the problem. Or you just used the program in the wrong way.
John:You know, here's what you should type instead. So this story is much nicer in Rust Yeah. Than it is in Go. Much as I love Go, who had written a book called For the Love of Go. So, you know, I I got some form here.
John:But, Go makes error handling really explicit, which is terrific, and errors happen a lot. So good programs are mostly about error handling, I would argue. The happy path is easy. Anybody can write that. What do you do when something doesn't work as planned?
John:That's the clever bit. But Rust has a lovely syntax sugar where you can just say question mark after some function that might fail like read, And that automatically bails out of the function, returning the error type that the function returns, and then someone can handle it. But somebody has to handle it. That's the point. It's it's it's not just an exception that can bubble up to the top.
Dominic:Right.
John:Because a function in which you can use question mark, it it has a return type of result of something, meaning this could fail. There might not be a result. There might be some error explaining what went wrong. So in order to even access that value, you have to do something with it. You can't just say, okay, here's my result.
John:You have to say, no. Did that result succeed or not? And and maybe what you do is just use question mark again to just say whatever didn't succeed, bubble it up to the person that called me and so forth. But, ultimately, it lands on someone's desk, and they have to decide what to do, print the error or whatever. It just doesn't clutter up all the rest of your code with a lot of iffy, not equals nil stuff, which is not.
Dominic:Yeah. This is something I I I'm hearing a lot, you know, that the the result is is also there in element, things like that. I mean, this this is a nice way to to pattern match after that and and see, you know, do I have the real the the value that I was expecting or or I need to handle the error. Once you once you start getting used to that, yes, it it it might be a little bit, I I would not say painful, but let's say verbose to return to go and and have all the the the if block everywhere.
John:Yeah. That's a great point. When I switch back to go, what I really miss is I miss question mark. I miss results and options, which is sort of there may be data here or there may not. It may just be nothing.
John:And I also miss things. The fact that Rust is an expression language. So everything that you write ultimately evaluates to some value. And if if that's the end of your function, that's the value it returns. Whereas in Go, it's a statement based language.
John:So you have to sort of do a bunch of imperative statements and then say, by the way, here's the value that I return. So in Rust, sometimes that means you can really elegantly express your computation. It's just your function is basically an expression. So it is kinda functional in that sense.
Dominic:Right. Yeah.
John:But that doesn't work for every problem, as you know. Sometimes you just need plain old imperative programs. You need to write a 4 loop or something. So you've got that choice in Rust. You can structure it either way around, whichever makes more sense.
Dominic:Yeah. I I would I would guess that it's there's a lot of recursion as well, preferably over looping and things like that.
John:Yeah. Exactly. What really impresses me is how efficient the compiler is able to be in the sense that, you know, the promise of something like c plus plus with 0 cost abstractions, wasn't it? You you can you can have things like classes and, traits or generics or whatever, and yet somehow it compiles down to really efficient machine code and no runtime.
Dominic:Yeah. Yeah.
John:This this is a good selling point over Go if you need one, isn't it? Is that Go has a complex a large and complex runtime, which is fair. It does a lot. Go routines, you know, dynamic memory management, garbage collection, all of this stuff. That's fantastic.
John:But it also means that your hello world program in Go compiles to about 5 meg.
Dominic:Right.
John:In the assembler, it would be a lot smaller than that. And then and in Rust, it's about the same size. Rust has literally no runtime anymore it used to have, but they got rid of it. In fact, the one thing it does have is panic unwinding, and even that's optional. So that that's very nice for embedded systems, really, low memory systems
Dominic:Yeah.
John:Chips inside washing machines, car ECUs, that kind of thing.
Dominic:Yeah. Yeah. The very yeah. Very interesting. So you you were mentioning that you were, writing you were at the chapter 6.
Dominic:So I would, like, I would expect that you at some point, you are you you need to talk early about memory management and trust in in that book. Right?
John:Yeah. Sort of. I'm trying to avoid talking about it. Okay. Because I I don't want people to feel like they're running into a brick wall of computer science.
John:Okay. Even though you know, at a certain point, they'll hopefully think this stuff is fun and interesting, and they'll learn more about it. And then it'll seem perfectly straightforward once they've actually applied these ideas. But if you just try to pile a whole load of theory on top of someone, often doesn't go well. Yeah.
John:And so so again, you know, I'll bring this stuff in when it's necessary. One one reason, for example, is when talking about string types. So in Go, it's nice and easy. You just have string, very appealing. In Rust, you also have string, but then you have some other strings.
John:So what are so what are these? You know, and again, Rust is surfacing this fact that, actually, there's a thing called heap memory. You know? Again, like, this is something that experienced programmers take for granted or they've just internalized this knowledge. So if you ask them how the heap works, they couldn't necessarily tell you.
John:But, nonetheless, allocate for things like variables and whatever. And if if these things are just temporary within a function, then fine. You you don't need expensive allocation. It can just be on the stack or whatever. That's cheap to allocate, cheap to throw away.
John:But if you need to pass that data around from one point in the program to another, it needs to live for a while, then it needs to be something that's on the heap. And that means it needs to be allocated. You have a pointer. That pointer has a lifespan and so forth. And that's that's the string type in Rust.
John:And you can also have a string where, you know, you it's not your string. It's somebody else's string that you just have a reference to. You have a slice of it or something. You you just have a kind of a view onto that string. So you don't need to own it.
John:You're just pointing into someone else's string. So that's great. So that's a stir or a string slice as Rusticians would say. And then there's also the fact that, you know, in Rust, strings are UTF 8 just like in Go. Mhmm.
John:So they're guaranteed to be valid Unicode. But what about strings that come from somewhere outside the rush program like from the operating system, command line arguments, names of files, contents of files? These are just random bytes that you found on the street. No one knows what they are. They could be UTF 8, could be anything.
John:So Rust has an OS string type to say this this is just a bunch of bytes. So we don't know what they represent. It may not be UTF 8, and a few other things. But in general, you know, if if you know about string and STIRR, that'll pretty much get you 90% of the way. So, again, I'm not trying to overload people with too much stuff.
John:I'm just saying, you know, the idea is not let's learn about Rust by writing some toy programs. It's let's try to write some simple but potentially useful programs that resemble the kind of things you might really wanna do. And we'll then see how much CS knowledge and theory do we need to bring in. Mhmm. How much of the big book of Rust do we need to understand in order to write this program?
John:It turns out pleasantly little. Right? Really? It's amazing what you can get away without knowing in Rust. As I say, there's there's huge chunks of it that I just don't know anything about, and yet somehow that seems to be fine.
John:So a comment from Steve Glabnick on Lobsters that he said, you know, I wrote the Rust book, and I've got 15 years experience programming in Rust. And I've only ever written a macro once. And that that was actually just editing someone else's macro. So, you know, it's easy to read tutorials or something. I think, oh god, I don't understand macros.
John:So therefore, I'll never make it as a Rust program. Well, well, you know, relax. You probably won't need to do that.
Dominic:Interesting. Yeah. That that that's reassuring a little bit. I would say, you know, it
John:Yeah. Also, I think it's it's very different from the Go world in the sense that Go is small. And if if you read the standard library or the runtime code or even the compiler, it's relatively understandable.
Dominic:Mhmm.
John:We've said this before. Yeah. And that's great. And you're writing the same sort of code in your own programs. It's a bit different in Rust in the sense that it it is very powerful and complex code.
John:You can write doing really obscure and clever things, and people can do that in the standard library or the compiler. But you don't need to write that stuff. You can just consume the the fruits of their labor. You can use their crate or whatever. And your program can be very simple and straightforward.
John:It's just a variable. Here's a loop over a sequence. You know, I'm printing something. You don't need to do anything clever yourself because you can use all of that stuff built by other people. So that's great.
Dominic:And the ecosystem is, is growing great. I mean, you you you find a lot of library, I guess, that for for everything that you would need to do.
John:Yeah. Too many libraries, really. I mean, this the problem also exists in the Go world, doesn't it? Here's another point where the the two languages have a very different approach to things. Go wants to be a batteries included language.
John:So they just says, look, you may never need to import some third party library in Go. You can just do everything in the standard library. You've got crypto. You've got HTTP. You've got OS.
John:All of this is fantastic. Very useful because there's only one way to do stuff, and you can just easily look it up. However, there are some caveats that come with this that we know about. For example, standard library has to be kind of carved in stone and Yeah. And unchanged forever.
John:So what if it turns out some API doesn't really work that well in practice? Or the world has changed in 10 years and people want to do things slightly differently? Well, tough. You know, sorry. You're stuck with the standard library we have or even the language we have.
John:You can add new things, but you can't necessarily change the old ones. Now, I I think the Rust people saw this and said, let's be really careful about what we put in the standard library. Let's not put things in the standard library until we really know that this is the perfect API that we want for all time. Mhmm. John Jenkset said something to the effect, you know, the standard library is by definition, that set of APIs that we're willing to commit to forever.
John:Interesting. That that's a pretty small set. Alright. And maybe even that is too large. So what's interesting in Rust is that things that used to be in the standard library have moved out.
John:So, you know, things that you'd expect to see in the standard library perhaps, time, Rand Really? Things like this.
Dominic:Okay.
John:Even regex. I've moved out to be just regular third party crates on crates. Io that you can port and use, but you can use somebody else's random crate if you prefer that like the there's a fast Rand, which is not suitable for crypto, or you can use Rand for the full fat version. I think part of the philosophy behind this is if if something is really good and it's just obviously the best solution in the ecosystem, then people will just use it. It has it gets a critical mass and it has lots of people working on it and improving it and so forth.
John:And maybe, eventually, it'll be it'll become so much de facto standard that it becomes a de jure standard and we'll just move it in.
Dominic:Yeah.
John:Or maybe not. It doesn't matter. The point is people have the behavior they need. They don't care if it's in the standard library or not as long as they can use it.
Dominic:But wait. Wait. Wait. Wait. Wait.
Dominic:I mean, this is this is this triggers me a little bit because, you know, I've been bitten by 3rd party dependencies a lot in my career. So, you know, I was a dot net developers, developer, and this is something that I really enjoy about Go. And now what you are describing is caring because it's well, from what I hear, it seems to be, you know, how the they do that in the JavaScript ecosystem where, you know, every everything is basically a it's a module that you that you are bringing. So I mean, is is there not a danger there at some point?
John:Yeah. Absolutely. I mean, the the thing is, if crates if you if you're using third party crates, they can come from anywhere. They can be anything. They can contain bugs.
John:You know. This is true of standard library code as well, if you think about it. There can be bugs in that too. The only problem is really hard to fix them, without changing the API. So the the good thing about stuff being out there in the world is it's possible to change and evolve.
John:The bad thing is it's possible for it to change and evolve. Yeah. This could this could break your bill, you know. And Go has some, you know, way of tackling this with the module system. Rust has a similar system in that, you know.
John:It has versioning and so forth. And if you depend on some specific version of a library, then that's just the version you use, and there's no reason for you to update unless you want to. And if you find that the update doesn't work, well, you don't have to. However, there are things, you know, that are so widely depended on that changes to them occasionally, they have to make breaking changes. And so therefore, then these breaking changes ripple through the whole ecosystem or maybe a tidal wave is a better analogy.
John:And it does cause big issues for people, not not necessarily a disaster, but a fair amount of work involved in keeping up to date on these things. So I suppose, you know, in in Go, if they made a breaking change to some API or standard library, and it would then be go 2.0. Right? Yeah. You know?
John:And and if you wanted to build your program against that, you would then have to handle all those breaking changes and so forth. But that just never happens. So that's just not a thing in the Go world. Whereas in the Rust world, it can be. But at least it's sort of opt in, you
Dominic:know. Right.
John:You mentioned JavaScript, which is always a swear word. Context, isn't it? And that nobody wants to end up in sort of NPM world.
Dominic:Right.
John:Clearly, that is taking the idea a bit too far. But I think we're also sort of striking a balance between saying everything is frozen in the standard library forever and backwards compatible. And the the other extreme is just a free for all, you know, anything goes. I think they're sort of steering a route somewhere in the middle where they say, actually, you know, this de facto set of really widely used crates They're incredibly well maintained by super smart people. In many cases, the same people working on the standard library.
John:It it's just they're sort of allowing themselves to occasionally change it. Right. That's the only difference.
Dominic:What what's the mentality about the community about that? You know, are are they are they prudent a little bit? Are they writing their own things? And and, you know, first before considering a, you know, something that is is not done by the core team of Rust and things like that. You know, what how is the situation there?
John:Yeah. I think, it's less, we we have these kind of discussions about Go, don't we? Where somebody says, what web framework should I use for my web app? And somebody says, oh, you shouldn't use any frameworks. Just use the standard library.
John:Write it yourself. And they're like, yeah, but I don't really want to implement JWT from scratch or write my own auth or something like this. Right. What what about, you know there's so much boilerplate in the web app, as you know, which is sort of just to solve problem. Wouldn't it be nice to just import that?
John:And then all you have to write is the business logic about what what's different about your
Dominic:It's called Ruby on Rails, mister.
John:Yeah. Exactly. Exactly. That's what people want, isn't it? They want Rails for Go, which is why Wales exist.
Dominic:Right.
John:And you can talk to Lee Anthony about this. And there's not really anything the equivalent for Rust, and I'm not totally sure why. There's a a few videos or books that I've seen. For example, Luca Palmieri's 0 to production in Rust, where he basically builds a standard ish web app from scratch in Rust using just crates and things, mostly using the Axsome framework. And he sort of says it's not that hard.
John:Right? You know, it's it's easy for people to be sort of intimidated and terrified into thinking I should just use some framework. You know? Right. People who don't have a lot of experience writing programs, natural for them to feel, gosh, that's really complicated, and I'm not smart enough to do that.
John:Better to just import somebody else's code. When you're a bit more experienced with this stuff, you realize whatever you do, it ends up having bugs. Usually, it's easier to fix your own bugs than somebody else's. Yeah. Well, also, you kinda get smarter as a result of having written that stuff, and then you know how to do it again next time.
John:So it's not so scary. Absolutely. And I I think maybe one reason why this doesn't quite exist in Rust world yet is just that people maybe aren't using Rust to run web apps too much, probably because it makes much more sense to do it in rails or even go with buffalo or something like that.
Dominic:Right.
John:Right. And while while you absolutely can do it in Rust, of course, and and that stuff's fun to do, I don't know if it would be anybody's first choice.
Dominic:No. Right. Yeah. Totally. Perhaps it
John:won't change.
Dominic:But and what about, you know, the, async module or crate or whatever that you want
John:to call?
Dominic:So, I mean, I'm I'm hearing a lot of things there where, yeah, you know, concurrency does. Not seems to be as as easy as in Go for sure.
John:Yeah. That's really interesting. So this is an another place where there's really interesting differences. And it's not obviously the story in one language is way better than the other. So, you know, concurrent programming is hard Mhmm.
John:As we all know if we tried to do it. It's just difficult to mentally process lots of things potentially happening at once and even sharing data and communicating with each other and so forth. So this is hard in any language, and you can have concurrency bugs and things. And the language can't prevent you from that from having that. But it it can give you some nice facilities to do stuff like goroutines and channels, fantastic primitives for writing concurrent programs, but pretty basic.
John:You know, they for example, common thing in Go is to say, well, I'd like to start a bunch of goroutines or computing some chunk of the data that I have to do. And then I'd like them to all line up their answers and reduce them back into one again, and I'll just print it. And, also, I need to wait for all of those goroutines. I need to handle any errors that happen if they terminate abnormally or something. How do I do that?
John:Well, the answer is you just have to write that stuff yourself, and you can use weight groups Yeah. And things. And in in Rust, you don't have go routines, but you you sort of got 2 2 different tools you can throw at it. 1 is traditional threads, OS threads. Mhmm.
John:A lot of times, that's actually what you want. You know, think about something like an app where you're making, you know, you're you're processing some incoming events. Maybe you've got one bit of code that just waits for events and reacts to them and another one that's just updating the UI or something, drawing the GUI or the TUI. And 2 threads are fine for this because they're basically just 2 tasks.
Dominic:Mhmm.
John:And they're long running. And you can do that in Rust as well. But you also have async tasks, which are a bit like goroutines, except really not. So this is the danger is that you see this and think, gosh, that's just like a goroutine, and then you realize it's very different. For one thing, goroutines don't return anything.
John:Yeah. They can't. I mean, where would they return to? The the program's already moved on. You've got a go statement, and then it moves on to do something else.
John:So there's no way you could return it to. In Rust, an async task can return something. In fact, it always does, even if it's just nothing. And so you you have the choice. You can sort of start your async task and then just move on to do other things.
John:And then at some other point in the program, you say, now I'm ready for that result from that async task. So I will now await it. Or you or you can say, you know, I need that async thing to happen, and there's nothing I can do until I have that result. So I'll just I'll call the function and await it right now. There's no equivalent of that in Go.
John:You know, what you'd often like to do is await some Go routine, isn't it? But you don't have that.
Dominic:Okay. So it's it's the same model as, well, JavaScript and and c sharp for that matter. They they do it. Yeah. Okay.
Dominic:Interesting.
John:Yeah. With with some
Dominic:Yeah. Probably.
John:Social differences because, you know, it has to be different. But yeah. But basically, that that same sort of model. And and Go, it really is totally different in this. And it just has its own thing, which isn't like any other language.
Dominic:And do do you have something similar? Do you know when when someone is starting with Go, they they kind of use concurrency everywhere even though even though it might not be the right things to do? What what what would be the the same things in in the Rust world? Does that exist at all since the you are saying that, you know, the standard library is so tiny that I I I would not imagine that there is anything like that.
John:Yeah. Well yeah. I mean, to your specific point, no. People do not try to do everything with async tasks in Rust because they that sounds really hard, you know. It's it's interesting because it's it's sort of like one of these what color is your function problems, you know.
John:Mhmm. In Rust or in JavaScript, for example, you have fundamentally 2 different kinds of functions, async ones and non async ones. And in Rust, you can't call an async function from a sync function. It's basically that your program is either async or
Dominic:Mhmm.
John:So that's quite nice in a way because most of us don't need to write async programs. So if you don't, you just don't need to know anything about that stuff. And if if you do, then everything is async. So, again, it's not that complicated because you're not bridging between those two worlds.
Dominic:Interesting.
John:So I think it's, you know but, certainly, the underlying point of what you're implying, I think, is that it's sort of but once you get this wonderful hammer provided in the language, you start to see everything as a nail, and you think, I'll solve this with goroutines.
Dominic:Yeah.
John:Yeah. Now I have n problems for n goroutines or n equals runtime dot numCPUs. And in Rust, I think, that this problem doesn't quite exist so much because there's an absolutely wonderful crate that solves a lot of these problems called rayon, which if you have some parallel task, like just chomping a big load of data, you can use rayon. And as long as you can turn the thing into an iterator, you can just use par iter from rayon. Mhmm.
John:And that just takes care of automatically deciding how many worker tasks to run, how to parcel up the work between those workers, how to take care of new tasks that arrive, how to reduce all the results back in again, and how to take care of terminating the workers. And that just all happens by black magic behind the scenes. All you do is you just call Parator and then you get your result.
Dominic:Nice.
John:So that is absolutely amazing. And if something like that existed for Go, that would really be a killer app.
Dominic:Mhmm. Nice. Interesting. Well, John, I mean, this is, I, yeah. I'm pumped.
Dominic:We'll probably, probably look at, you know, look at your content because you are you're creating a lot of content. I I read your, you know, go versus rust. For listeners, I mean, I encourage you to, to go check, John's, website. It's, bitfieldconsulting.com. We will have every, you know, all all the the links in the show notes.
Dominic:Do do you have any closing thoughts, you know, anything that you want to mention before we wrap up?
John:Well, I think the phrase that I have in my mind when I'm thinking about this stuff is, you know, the problem that people often run into with Go is that it's deceptively simple. Mhmm. And we've talked about this before. And that this sort of looks so straightforward. The code is easy to read.
John:You think, well, it's easy to understand what's going on. But it's really not because some very subtle things are going on. Subtle things are going on with pointers, with slices, with goroutines, with the runtime, with scheduling. You have to actually understand something about all this machinery in order to understand why your program is not working, which is why people sometimes complain about Go. With Rust, it's the opposite problem in the sense that the language is so big and the syntax is a bit intimidating.
John:In order to kind of tunnel through that barrier, what you need to do is realize, hey, it's actually not that hard. Because 90% of it, you just don't use or Yeah. You don't need to know about or whatever. And and the bit that you do need is completely straightforward, and it works just the same way that most other programming languages do. So the way I've summed it up is, you know, with with Go, you you think you can understand Go code, but you really can't.
John:Whereas with Rust, you you think you can't understand Rust code, but you actually can.
Dominic:Nice. I like that.
John:At least if you're willing to stick with it a little bit. Yeah. If you really look at it and and you try to write some programs and you thoroughly bounce off it and you think, you know what? It's just not for me. That's okay.
Dominic:No. Yeah. Totally. And I mean I mean, you know, I I wanted to to do this this episode. You know, not not be be because I think Go is is inferior and and things like that.
Dominic:I I also like like you mentioned earlier, I mean, just just learning, just being curious, learning a couple of new languages, just just seeing what's what's out there. I mean, it's it's very valuable for any programmers.
John:Yeah. You're so right. It's it's really important to keep on learning new stuff. Even if you think you already know everything that you need to know for the rest of your career, you know, just from the point of view of the health of your brain, it is really valuable to expose it to new ways of thinking new languages and new tools. And learning Rust has lit up a load of brain cells that I don't think I've used in years.
Dominic:Yeah. Oh, yeah. I can imagine. I, I I would like that. I I think because yeah.
Dominic:It seems to be great once you yeah. Once you pass this this famous, you know, x number of weeks. Seems to be seems to be great. Mhmm. Cool, John.
Dominic:Thank you very much for, for this. Maybe maybe we can talk a little bit later. We will we will see. But, but, yeah, if if people want to to check your course, you know, we will have all all the show notes. So, so it was it was great to to have you.
John:Yeah. Thanks very much.
Dominic:Alright. Bye. Alright. That's it for this week. I would really appreciate if you can talk or share about this podcast.
Dominic:It's it's always helpful. Also, another way to support this show is by purchasing my course. There's always a link in the show notes. So on that, see you next week.