What even is this Rust thing -> Naïve Excitement

00:22
Hello and welcome to the Rust Workshop Podcast brought to you by the Rust Workshop, a Rust programming consultancy in leafy Hampshire UK. So today on the show I have my good friend and fellow programmer Jim and the subject of today is what even is this Rust thing? And to share our naive excitement because this is all new, this is as you can see a super early episode.

00:51
and we'll get more expert as we go on. So, hello Jim, do you wanna introduce yourself and then I'll talk a bit about me. Hey there Tim. Yes, I am a C++ developer, among a few other things of, oh I don't know, more than 20 years now at any rate. And I've paid some attention to trying to steal the best ideas in terms of

01:20
idioms and paradigms from other languages and track some of the best ideas as they come into C++ over the recent spurt of standardization efforts to improve it. And I guess I'm generally a systems guy, at least in my core interests. And yes, so.

01:49
Basically, I've got a kind of systems level first view of things in general, a strong eye towards eliminating unnecessary inefficiency, but also compromising it where it's better for other considerations, like readability or maintainability, hopefully. And yes, so I hope it should be obvious to everyone listening why I might be excited about Rust.

02:18
Yeah, I'd say I was a little surprised that it caught your interest. But before we get into that, let me just give people the intro into me and why on earth this is even a thing right now for me. So I've been more of an applications programmer in the web sphere, also for 20 odd years, through permijobs and contracting. Now recently taking it serious, jump into team lead kind of things.

02:47
with existing clients. And I've been poking around the entrepreneur landscape for quite some time now. My latest concept is a second hand buying and selling thing to sort of push on the eco-friendly side to do something potentially that I would prefer to use than eBay or Facebook Marketplace and that kind of thing.

03:16
So I have this idea that I would like to bootstrap this, and the challenge with that is largely hosting costs. I'm aware that there are other challenges. So it caught my eye that maybe C Sharp and Ruby on Rails would limit my ability to support lots of users, which could limit my ability to get to enough users for a good network to get income.

03:45
to support the thing on its own legs. I have written a thing in Golang called Schemer Explorer and very much enjoyed that, but was not super enamoured with the idea of writing the next thing in that, having spent a few years hacking away on that on the side, although it would meet the requirements as a C-sharp programmer primarily.

04:14
I felt like I was kind of losing a lot of the things that make programming nice and less repetitive. So I totally appreciate that Golang is an excellent choice for a large engineering organisation like Google that has to have thousands and thousands of pairs of hands pass over pieces of code over its life. Compiled times are obviously a big thing for them. So I had become aware of Rust.

04:44
It got mentioned in the Stack Overflow developer survey as a most loved language repeatedly year on year. I'd heard enough about it on presumably podcasts and the occasional web article but I'd not really looked at it that much but I knew it was a kind of low level thing. So I went to the Stack Overflow thing and they had a blog article on... I forget what they called it but it was basically, why is Rust so interesting? What's all this fuss about Rust?

05:14
and read that and that enlightened me a bit to how it had come out of Mozilla that it was this really low-level thing that had been built up to become kind of the language that people would like in terms of zero-cost abstractions but still having lots of modern programmer affordances and like looking at the syntax and the way you write things like list comprehension and pattern matching

05:44
It certainly seemed to be something that might feel a little less constraining than Golang. So, that was a little while ago. So I thought, well, obviously I have to learn this thing in order to really, truly evaluate whether this is something that I would like a long-term project in. So I sat down and started reading the tutorials and the docs, and the Rust docs are superb.

06:13
multiple different ways of learning it. They've got the Rust book, they've got Rust by example, and then they've got the reference, and they all complement each other. And having kind of worked through a bunch of that and done a couple of their little tutorial projects, then kind of needed some kind of direction to go from there, but certainly didn't feel like I knew everything and was good to go, whereas with Golang, because it's a very small language...

06:41
I didn't need to read that much before I was like, okay, yeah, I kind of get this. I can head off and build the real thing. Uh, so yeah, of course. Um, what was thinking about go and rust? Can you remember what

07:01
shortcomings in your view of Go made Rust seem attractive to you? What caught your attention about Rust and why given your experience of Go up to that point? Well this is where everyone in the comments is going to tell me I'm wrong. What did I... to an extent it was a feel. So one of the things...

07:28
I mean, they have now introduced generics, but that was an absence that I was aware of, and I remember generics being introduced into C sharp, so that had made me a bit uneasy because I remember how valuable that was. They have now added it, but the syntax is a bit kooky, if you ask me. The error handling, they do by multiple return, so your code is littered with if...

07:59
forget how exactly it looks, but basically when you call a function that you've written that returns a value and possibly an error as like a tuple, then you kind of every single time you have to go if error, then do something, which might be then return the error further up the stack. And it just feels really boilerplatey and it's possible that

08:26
there's libraries that make this better or what have you. And they do have panic, so there is some kind of form of exception system in there, but that's more intended for, you're writing a web server. If something has gone wrong, like your IO didn't work when you expect to be able to rely on it, like you're trying to load a file off disk that really should be there, and you panic, and then your web server can catch that.

08:56
and behave gracefully without tearing the whole thing down. But it's not for the kind of more granular error handling. So whereas in C Sharp, you might use a lot more exceptions. You know, you might have an exception that's like a blah not found. So you know, when a user clicks the wrong link and it's a dead link, then you might have a throw in there that you can catch an appropriate place in your business logic. So that kind of felt kind of boilerplate-y. They are lacking...

09:27
a lot of, in C sharp we have link to like take lists and you know, do map reduce kind of stuff and basically very effectively faff around with lists. Like particularly, I believe Python's particularly good at this kind of stuff. So it felt like we're going backwards a bit with Golang and certainly looking at Rust, like all of that stuff is there and is good. Is that answer your question?

09:55
with your years of experience dealing with real world problems, especially business problems, you could already see a couple of things in go that struck you as perhaps more naive than wise or that would cause problems in large complex systems that you could foresee. So I don't, I don't think they'd cause problems in terms of being able to do a really good job and great engineering. I think the

10:23
with my context, there are two reasons why I was a bit wary of it. One is, because this is a side project, I want to pull out the laptop at 10 o'clock in the evening and do a couple of hours. And if I'm really not loving the language that I built the thing in, I'm just going to be like, ah, this is not bringing me joy. And I've realised that that's important, if you're going to have an extra project that isn't your day job and it's something that you're trying to push yourself.

10:52
And the other consideration is I do have an ambition to have things that it's not just me that works on, like I'll create the seed and prove the business side of it that there is enough traction to make this thing worth investing in, and then as that flywheel starts, then I can bring people on and I can start paying people to work on a codebase with...

11:21
the confidence that this is worth doing and I'm not just throwing my contracting money down the drain. And from that point of view it does matter whether it's pleasing to work on and I do wonder whether Golang is... People get interested in something for its novelty but then once they've had a play with it, if it's really not that fun to work with, they might go and get a job in it and that's cool. But when the shine goes... If I'm...

11:51
trying to find great people who've got lots of options, I might struggle to find people who are like enthusiastic to come and work on something little in Golang. You know, there's a big difference between a little side project bootstrap thing that hasn't necessarily got a huge amount of money to throw at people saying, hey, come and work on this fairly boring language, compared to Google saying...

12:16
hey, come and work on this fairly boring language at this gigantic reputable company, by the way, we can pay you double market rates. If you know what I mean. Yeah, yeah, yeah. And I think it's fair to say that Go was, one of Go's design goals was not necessarily to be fun. It was, it seems to me, from what I've heard, that it was designed to optimize development workflows and deployment workflows above all else, right?

12:45
Yeah, compile times is a really big thing for them in their design. My understanding is they've got a gigantic C++ code base and because of this cascade of headers, the amount of IO means that it literally takes 24 hours plus to build the thing. Careful, you're in serious danger of starting me on a rant. Compile times is the one thing I hate most about C++, much as I love the language. And the worst part is I understand the reasons why it's not easy to fix.

13:16
Yeah, so that's definitely one of the things that's cool about Golang is that the compiles are fast, from what I understand. It's probably the fastest one around. I'm sure. And that is super, super important, lest that escape anybody. It really matters. Yeah, definitely. Yeah, and I like the movement. This kind of, your cycle time as a developer is important. And I'm totally familiar with this idea that, like viscerally familiar with this thing where

13:46
you have all of this context in your head and then you hit build and run the tests and then quarter of an hour later they finish and you've completely forgotten what you were doing. Yeah, yeah. So in a way, in goes defense. Perhaps although it's not explicitly designed to be fun, the fact that it optimizes the iterative workflow of the programmer actually does make it a bit more fun even by accident because you're not constantly dropping context on the floor.

14:14
twiddling your thumbs while it compiles. Yeah, yeah, yeah great engineering is definitely a pleasing thing. I mean it's one of the things that keeps me interested in in contracting. Cool, so where are we? So yeah, at this point we're... I tried GoLang, it didn't seem that exciting. I'd heard about this Rust thing. It's pretty speedy and low-level. I'm now trying to kind of learn this thing to get a better handle on it. The...

14:43
a client I've got has got microservices which means like 20-30 git repository which is a bit of a hassle I hunted around to find out what what was out there to make it a bit easier to manage all of these repositories on your local machine and I found a couple, there's one called git-a which seemed to be about the best one around it's written in Python which means that in order to install it you have to install Python which is a minor faff

15:13
The thing that really put me off with it is the command lines in text doesn't make any sense to me and I can never remember how to use it. So it just occurred to me, ah, maybe this is a good hobby project to have a real problem to solve to push me to learn Rust. And this was also quite a while ago now. I know I don't have a huge amount of time, but this has been an excellent exercise because I made a reasonably speedy start hashing something out.

15:43
I then, and this is where I think we get into the actual experience of Rust, the first thing I ran into was I sketched out the configuration for this thing that it would save for its local state, kind of listing what repositories it knew about in what folders, and there are a couple of libraries in Rust that can parse this format called Toml.

16:12
which is actually a really nice format for this kind of thing. It's really simple. If you've ever looked at a gitconfig, I don't know if it's actually the same format, but that's basically what it looks like. I then lost ages because I'd designed the format that I wanted, which is valid-toml, I was then like, okay, how do I get this library to produce that?

16:40
based on the rust I'm writing, so some in-memory rust structure and then, hey library, make me a string that looks like that and what I eventually discovered is that the Tommel format has a test suite which has a whole bunch of examples, a lot of examples in both Tommel and JSON, and you should be able to to and fro between them

17:09
And the way this particular library had written the tests was they would read one, parse it into its internal structure, write out the other one, and then assert that the strings were basically as expected. And it would do this in both directions. And I spent ages reading the code and scratching my head. And there was a particular structure that I wanted. So most of it worked, but there was a particular structure I wanted that I couldn't work out how to make it produce that thing.

17:38
even having read the code. And what I eventually established is that they had an inter... So you could use normal Rust structs for your own thing, and you could have a vector of these and even B-trees of these, which are like a dictionary in C-sharp terms. And you could give this structure of things into this library and it would produce a Toml file. But it actually has its own internal...

18:07
structures that it uses. And when it's doing these roundtrip tests, it only uses these internal structures. And it turns out there was no way that you could build a Rust structure that would actually serialize into this particular tumble that I'd very unfortunately decided was going to be part of my format. So that cost me loads of time. Kind of what I learned in that journey is that...

18:36
from my limited experience, there's quite good coverage in what they call crates, which is basically their libraries. But like a lot of younger ecosystems, it's gonna be a little bit potluck and you could be working on a project, you could pick a rust crate and discover that it's broken or it doesn't fit your needs or whatever. So this is definitely something to be aware of as moving into the ecosystem that perhaps, unlike, maybe more like node than we would like to say.

19:06
no JS and NPM or You get generally pretty solid. It's been around for a very long time for the C sharp ecosystem So it's definitely something to be aware of so that was a learning Yeah, any thoughts in C++ we just hand code linked lists from scratch when we run up against that kind of thing it solves all problems Yeah, not invented here and all that Yeah, yeah linked lists actually come up as it happens

19:36
But I shall carry on. So I have battled away. Where I ended up with that was discovering that there was already a GitHub issue that explained why you couldn't do it. Which is always the way. So I added some more information to that and maybe put a bounty on it at some point. Which would be cool. And then the next challenge was testing. So I started off with just a bash script.

20:06
ran up DXE and tried a couple of things but obviously that's not going to last and wouldn't run in GitHub actions for continuous integration tests so then I wanted to do that and I wrote a unit test based on the docs that are out there, that was nice and straightforward I like the fact that the unit tests are alongside

20:33
the production code in the file and they're just compiled out. That's really cool. In C Sharp land, they tend to have an entire separate tree called test and having seen alternatives, actually, that's not very good, particularly for unit tests. I mean, I've got a mixed approach in my C++ work, which is to have the tests in their own file, but they live alongside the code they're testing.

21:00
which sounds slightly better than the C sharp approach, but I can see the merits of the Rust way of doing it as well. It's quite nice. Yeah, yeah, Golang does that. You have foo.go and foo underscore test.go and it knows that that's the test file just because of the file name, which is gonna call. Nice. So I did that. Then integration testing has a specific meaning in Rust. So that's where you...

21:29
I think that's where you create a tests folder, side by side, and then that only has access to the public interface of your crate. And I spent a quite a while scratching my head because in C Sharp land...

21:48
If there's not actually a huge difference between an XE and a DLL or an executable in a library in other terms, so you can actually, you know, load an XE as if it was a library and poke it with a stick. But it turns out, and it's not super obvious from the docs, that in Rust, I couldn't access the public modules from the tests in the application binary, and I had to split it into a lib.

22:17
trait thing before I could test it and that had me scratching my head for quite a while. But that's now working.

22:27
The next challenge was... I'd written the code, just hardcoded with real file storage and a real shell out to talk to git and to run commands so I wanted to not run that in my tests because otherwise I'd have to have some kind of real environment in GitHub which I wasn't quite ready to do although I think that's possible because you can pretty much run Docker in GitHub CI

22:57
So then I had to figure out what dependency injection looks like, which is kind of my next thing. And at that point I realised how much I'm not a Rust programmer or a C++ programmer and how much C Sharp gives me for free. Because the first thing I tried to do was assign two different types of things to a trait. So I had a trait which was like file storage.

23:26
for the configuration and I had a trait which was talk to git and then in the production code I gave when I fired it up I gave it an instance of the real code and then as soon as I tried to give it a fake thing in the test it said you can't do that because I don't know what size they are at which point my brain melted because in C Sharp this isn't even a question you just like, hey I assigned this thing, fine, right?

23:56
So a bunch of learning ensued. If I can interject here for a moment, this is a long running issue. I remember at university, all the, I'm not sure we'd for maximum kindness refer to them as Java newbies who'd never really done programming before and who felt qualified to sit around carping about C++. I had a certain smugness about them, but one of the...

24:25
things I realized pretty early on was that there, things like C++ actually have a kind of consistency that things like Java don't. And C Sharp certainly historically has the same problem. And I think it persists to this day because it's baked into the design of the garbage collection system, which is that this, there's no real, although you have both value types and reference types.

24:55
The people who talk about, certainly about Java and probably to some extent with C sharp, try to kind of pretend that that distinction doesn't exist. And when you're writing C++, you have to have this distinction very clear in your mind. And what you're talking about when the compiler doesn't know the size of a type, that is specifically something that tends to happen with reference types, because under the hood,

25:24
the references are pointers, but with value types, they can go on the stack, and generally you're instantiating concrete types and using them as concrete types. So it's something I've been aware of that somebody who's used to languages like Java and C-sharp, which I think originally made, they made this decision to make the intrinsic types value types in the way you would understand in something like C++, but.

25:53
everything else is a reference type. And this distinction is just kind of not talked about. It's just you're expected to understand that when you're using an intrinsic type, there are ways you use it that are different to the way you use everything else, but it's never conceptually clarified. And I might suspect that one of the reasons you tripped over that and had such a hard time with it is that many years of C-sharp had failed to make you think about that distinction enough.

26:24
to see why the compiler might not know the size or why that would be relevant or something like that. Do you think there's anything there? Yeah, no, 100%. Yeah, the concept didn't make any sense to me whatsoever. And I remember in my early days of C-sharp, kind of, oh, reference thing, value thing, some kind of heap and stack thing. And I've done enough computer science, you can start to see things.

26:51
to understand how our computer hangs together and the fact that there is this stack that is the actual bits of execution. You hit a breakpoint in C Sharp and you can see a call stack and there's this idea that it's captured everything that's going on, including at a high level what variables are around and what values they have. But yeah, you can't from that kind of tell.

27:20
oh well that one is actually off on the heap because that's a reference to more data. So yeah that definitely made it harder and I have to say I think probably practically that has given C Sharp quite an advantage in Java over the years because it is easier. You can just ignore all of their stuff and if you don't need the performance if you're just doing what I usually do which is random line of business apps then who cares mostly. So yeah, no you're definitely right there.

27:49
I think that the crux of the thing might be that...

27:54
because of the way they design this distinction away, or kind of have a two tier object system, C-sharp and Java don't allow you to construct anything non-trivial as a value type, obviously, that's kind of the point. And unless you try and do that,

28:16
you're not really gonna think this whole thing through properly. It's, everything non-trivial you do ends up as a reference type and you know how to deal with those. And the kinds of things, because the only value types are intrinsic types, the kinds of things you do with them are so simple that your brain effectively develops two different modes for dealing with those situations and there's no overview that takes both of them in, maybe. Yeah, I'd say like one of the things that's attracted me to Rust is,

28:45
Over the years I've always felt like, as a programmer, I should be able to be closer to the machine and to the metal. I've always been aware that C Sharp has got these kind of fuzzy abstractions and that there is this runtime and bytecode and all sorts of clever optimisations between me and the machine, you know. But I'm never going to get all the way down, I'm not going to start writing assembler or processor microcode or anything crazy like that.

29:15
But I always felt like, do we actually need all these abstractions? Because they all have a real cost in terms of performance and understanding. And maybe just a little bit of extra time learning and then running closer to the machine.

29:31
you know, maybe you can be just as productive and get a whole bunch of advantages in understanding and efficiency and speed. But before Rust showed up, I was not about to start learning C++, basically. Yeah, I think I can just talk briefly historically about the bytecode thing. I think what happened there was that...

29:55
Java certainly had aspirations, and I think to a large extent, it's delivered on these aspirations to be a multi-platform language. That was the justification for having a bytecode system. Yeah, it was right once, run anywhere. And that- Yeah, right once, run anyway. I think times have changed and kind of left Java behind, because when they created this, it maybe was a bit more prohibitive to compile

30:24
a version for every platform out there, and it made sense to have this bytecode, and then they could work carefully on their bytecode interpreter and make sure that that was deployed out to all the various platforms, and also it helped them to own that piece of the puzzle in the platform wars that were going on at the time, way back. But now...

30:48
it's really not any great shakes to just have GitHub actions compile for every platform. Even my little Gitopolis thing, with a bit of googling and grabbing recipes that are out there, I've managed to make it automate building Windows and Linux binaries and publishing them. So all I have to do is push and tag and that's it done. So I think times have changed and that's maybe less important now.

31:13
I think to be fair, there's also a psychological aspect here, which is that the psychology at the time in the 90s was very much around distributing software, was very much that the source code was a trade secret, never to be seen by anyone except the developers.

31:35
And therefore having a binary format that would run identically anywhere with different virtual machines was a natural way to To deal with the problem of multiple platforms in that context And I think that's probably the reason why C sharp which was didn't start that much later than Java certainly Within ten years and probably much less than that. I think forget the chronology

32:03
they went for this same approach, and they also had aspirations to be multi-platform, and what's fallen away now, what's changed, is that in a lot of ways that are hard for people like you and I to notice, the world of IT has become a lot more Unix-y in its philosophy.

32:22
Source code is much more now something that is shared, not always, but very often. And it's often seen as the single source of truth in a way for making real software pop into existence by compiling it.

32:39
So there's just more of a culture of sharing source code. And so the ability to have that intermediate format that is in some way a single source of truth regarding the behavior of the program, but is still sufficiently obfuscated that you can't steal people's source code. That whole issue has just become less important and it's become more recognized that stealing someone's source code is not that big a leg up on them. We've talked about this before, haven't we?

33:09
can steal the source code of an entire company. And without all of the customer relationships and the various other data and logistical aspects that go with that, you haven't really stolen anything of much value. No, not really. Not if you don't know how to do marketing and legal and yadda yadda yadda yadda. Yeah, right, it's been recognized that...

33:34
code is less of a problem than we thought. Less of the problem of business, shall we say, in IT. Yeah, yeah, if you know how to do all of the things as well as the code, then you're not gonna be faffing around stealing other people's code. You're gonna be building a better business and putting them out of business. And building better code while you're at it, yeah. Yeah, potentially. So, we're nearly up to date with the journey. So, I got the Gitopolis.

34:02
dependency injection working and the magic thing was Box which is basically pointer to thing it's a it's a clever pointer it fits in with their whole borrowing system it manages ownership and all of this clever stuff that I don't you know I don't see call it smart pointer if you knew C++ you might

34:26
So from my point of view as a C Sharp programmer, it was like, oh, OK, like all of those things look really, really hard actually if I just box it. And I don't think it's quite the same concept as a C Sharp's box. Then I can now...

34:44
happily swap in and out my various implementations, and I don't think this is a particular performance issue, frankly, especially for a little command line tool. And it sounds like it's idiomatic enough, like, you know, learning a new language you're kind of a bit paranoid about, like, am I writing something that all of the experienced programmers are just going to laugh at and tell me I did it wrong? But there's also, you know, can you get a job done?

35:09
Your great advantage with Rust is that there are no experienced programmers yet. Oh no, there's definitely, there's definitely some fludging around. They're probably very busy and hard to get hold of now. Um, uh, so the next thing I tried to do was, uh, where did I get to? Oh, I was going to add tags. So I've already, I've already got this little GitOpalist tool to the point where you can run it and it give it a bunch of folders that are Git repositories and it will.

35:39
then know about them and you can tell it to run arbitrary commands in all of them which is cool because that's the main feature and it spits out the output albeit not streamed at the moment you can take a config file in an empty folder and tell it to reclone them all and it will run getclone for everything it knows about and that's really cool for new starters and machine rebuilds so please do that

36:07
and the next thing I want to do is tagging so that you could define subsets of repos to do things on things for my team, or things in this language, or things that this other project is working on, so you could just fetch the ten repos that's related to what I need to do next and see what's there in. I have no idea how I fell down this particular rabbit hole, but I basically decided that I needed to know more Rust.

36:36
before I could do a good job of this, and was hunting around for some problem on whatever, that I forget what it was, and I found this article about implementing linked lists in Rust, which started off with this wonderful tirade about I don't know why they teach linked lists in university, it's this really obscure data structure that's only one of many things, but everyone seems to be obsessed by it, but it uses linked lists as a way of like naively

37:06
showing how to build things, layering up until they get something that works. And it's quite an entertaining journey. So I've been digesting that and I've learnt lots. The main thing I've learnt is about mem replace, which is if you want to... Because they are popping things off a linked list. If you want to remove a pointer...

37:33
or value, I don't know which is, sorry I'm not very good at this yet. And then put the other one in its place, you can't because it leaves it in an invalid state temporarily and if everything went wrong, like a panic happened or whatever they call it, then it would leave it in the bad state that Rust is never going to allow. So they've got this memory place so you can do the switch in one go in a way that it's happy with, that's one of the things I learnt from that. And I'm still...

38:03
skimming the last bits of that, but I think I'm gonna go back to implementing the tag thing now. I think I've probably exhausted that thing. I think we should probably go through that, either go through that article or your adventures in trying to follow it in some detail at some point. That's gonna be a very fruitful way to discuss some of the core differences between Rust as it is now.

38:32
the other languages maybe. Yeah, I definitely couldn't do that now. I don't know it well enough. Yeah. It's a voyage of discovery for me. And the very most recent thing that's happened that's cool is RustConf 2022, as it would seem just happened. So I watched the keynote yesterday. Where are we now? We're like early September 2022 today.

39:02
and that was interesting. And then we'll come back to that. And there was another talk about weird rust, which was just a 15 minute, very well presented one where they found like a test case library in the compiler, which is like all of the completely bananas way that you can write code that the rust compiler has to be able to cope with. Which has got things like if, if, if, if, if, if, if, if, if true.

39:30
some more stuff, which is highly entertaining, it's a very funny talk if you're sufficiently jaded as a programmer it's funny for anyone else they'll just look blankly at it, I think so back to the RustConf thing the keynote, I think the second keynote speaker on that mentioned something which is relatively unusual in open source land, which is they

40:00
business and enterprise and employment and services, like it's okay to need money to be able to work on this stuff, which I take as some good encouragement for this venture, that the community is not going to hate us for trying to have a living and provide value in the rob more money kind of mindset of do hard things for money and make the world a better place.

40:27
So before we get onto the broader, what do we think about Rust? The reason that this podcast exists is because where that journey has led me is just getting a bit more into the Rust ecosystem, learning a bit more about it, meeting some people and kind of realizing that.

40:50
Rust really is on the ascendant at the moment and it seems so far to me to be genuinely a wonderful language with really interesting properties that are valuable to not just programmers but also businesses Like I saw a post of one organisation that had rewritten their core business logic in Rust and that meant that they could deploy their code single codebase to Windows, Linux, Mac, Android and iOS and then just write

41:19
platform specific front ends to give you that nice native feel I think that's really cool, I think that's huge and presumably server-side as well, if they're doing that kind of thing So the Rust Workshop is a nascent charm consulting idea to build an agency to connect programmers and projects that need doing

41:47
aspiring entrepreneur and I've been around the coding world for a long time. I've moved into kind of pieces of hiring and managing developers so I think I'm in a really good place to make a success of this. So yeah, my little side project is in danger of turning into this agency so we'll see where this goes. If you're a programmer who wants to get into Rust or is... hello Jim!

42:17
potentially, or a business that is doing some kind of Rust project such as rewriting a hot path in a microservices system from, say, C Sharp to Rust to get extra juice and lower hosting costs and maybe lower latency and that kind of thing, then that's the kind of project that we'll be looking to take on. So get in touch, of course. And I'm hoping to make this, over time, an awesome place for programmers to be and an awesome place for

42:47
clients to get great programmers to work on their problems. So before we go on to the rusting, any questions, thoughts on that Jim? Before I move on to the what is this? What do we think about rust? Nothing specific.

43:04
I've been, I guess I could say I've been pleasantly surprised with how rust seems to have slowly captured your interest and attention because I know you're going through a fair bit of, for want of a better word, agonising about whether to emphasise go or rust going forward. Yeah, we talked about it at length, didn't we? We did.

43:31
And much as I tried not to show it, I think I was quietly rooting for you to go for Rust the whole time. So that was kind of nice. And yeah, so it's kind of, it's nice to, to the degree that you might've, that part of that might've been your developing slightly more interest in the low level concerns of code performance. It's kind of.

44:00
I'm pleased that that's an area where we have more overlap in our interests now, but. Well, I'm like mostly terrified of it and like struggling to cope rather than interested, but yeah. Try trying to climb the mountain. Yeah. Sounds like the starting point for a good interest anyway. It does, yeah. But yeah, and so, and talking to you while you've gone through, especially the process of.

44:28
of writing Gidopolis, but partly the decision process before that of which language to emphasize. It's perhaps drawn my mind, my attention to what Russ has going for it in a way that's made me very interested. That in all my years of watching the language wars, watching the

44:55
the ideological attitudes, the ideologically designed languages, the naivety that drives all of that about real world problems and the best ways to solve them. I feel like in many ways Rust looks like the first serious minded attempt by people with

45:18
appropriate levels of humility to build something that could succeed C++ in the long run. So that's quite exciting for me because the I think we can all agree that you really learn the ins and outs of what's good, but also what's bad about tools by using them heavily. And my

45:43
20 plus years of C++ is no exception to that. It's part of the reason I've made such a point of stealing idioms and ways of doing things from other languages and inventing.

45:58
inventing my own where necessary, kind of independently reinvented a few things because 20 years ago, so you didn't have smart pointers, so I realized that the capabilities of the language allowed me to write those. So I wrote them, I think, before the standard library ones certainly were well publicized, even if they existed by that point. So yeah, in general, I think I'm better placed

46:28
as well placed as any long-term C++ developer who's been around since the time I started, to know what still bugs me about C++ and apart from compile times there's a list of other things that I won't get into but it's not like there isn't room for improvement and much as I would like to wait another 10 years for the standards committee to get around to some of these items,

46:56
There are some things that are baked in so deeply that I can't see them being addressed anytime soon. And there are just some purely superficial things like the existence of the self keyword. I've actually written type def name of this class self semicolon many, many times in my C++ code. And Rust just does it automatically.

47:21
And that's part of that that's that relates to the thing about constructors and destructors. Why would you name them after the class? Come up with a standard name, just little niggles like that, that mostly center around why are you making me repeat myself? And it seems like Rust has actually had a few, it's not mindlessly aped.

47:45
some of those things in the way that it might have in the way that Java mindlessly aped too much syntax from C++ for instance. So yeah, I feel like it's, it's the first thing I've seen that gives me the vibe of being a serious, relatively ideology free attempt to do better than the state of the art in C++. So that's, yeah, it's very exciting.

48:13
Yeah, I mean, that's huge to like, I was not expecting that whatsoever. Like for me as a C sharp programmer, it's like, Hey, this is lower level and seems cool. I was not expecting someone who knows every last corner of C++ to be like, Oh yeah, I might consider replacing my language with this. That's surprising and very encouraging. Well, yeah, I should add that.

48:38
only someone who isn't a C++ programmer could think that I know every last corner of it because I don't think there's a person alive who actually does. Well, maybe some of the guys on the standards committee, but you know what I mean. But yeah, I know enough to see promise in Rust, shall we say. Yeah. And on that note, that's one of the things that's putting me off C sharp these days is they've like, they've gone completely bananas with pulling everything from every language.

49:07
They're playing the we can do everything game. And knowing every corner of C sharp is not that easy anymore. And picking up someone's code base who's been a bit clever can be a real problem. Like you can literally be like, I have no idea how to change this without breaking it, which is not great. It seems like the general drive is, and I don't know what forces are driving this, but I suspect it's something to do with

49:36
the amount of time C Sharp has been around and in a way that like every language that becomes as big as C Sharp, it's a victim of its own success in that it's all the easy stuff has been done and now people are making serious demands for cutting edge performance.

49:56
for as you as you mentioned for things like hosting costs to keep those minimized the easy stuff has been done the language is no longer in the in the

50:10
the utopian, we designed this within the last five years phase and we made these bunch of decisions as to what would make a better language. It's now firmly in the, all of those decisions have smacked up against real world experience and several of them have been found wanting and now it's time to turn it into C++ in order to make up the Slack phase. Yeah, C++ and Ruby and Scala and Clojure and Haskell.

50:40
and I heard a line at university actually about how every programming maybe this is probably one of those things that's attributed incorrectly to new Thor somebody

50:55
but along the lines that every language followed the same trajectory ultimately of slowly but surely becoming an implementation, version of CLU common Lisp, but with worse syntax, something along those lines. Yeah. Yeah, enough about C sharp bashing though, because that's not, we have a brand new direction, much as I love a good C sharp bashing.

51:22
Well, I like C sharp. I mean, don't get me wrong. It's it scratched a lot of the itches that I found wanting in C plus plus as well, I've got a lot of good feelings for C sharp, but Everything reaches its limits. I guess Yeah, I'm not gonna bite the hand that feeds me. I'm like that's done me done me very well and I still like I went and played I did a couple more than one full-on commercial project in Ruby on rails and

51:50
I came back to C Sharp going, actually, no, I do like C Sharp. So yeah, it's got a lot going for it. The ecosystem is good. The dev teams are good. It's just the long-term trend. It might be a bit worrying. I guess that's the thrust of your point, isn't it? It's probably got another 20 years ahead of it before it completely collapses. Who knows? On the agency thing, the Rust agency, the Rust workshop.

52:20
which I've decided to name it. There was just one little thing that I wanted to say in there, which is that if anyone's a bit concerned that somebody who is just learning to do Rust is going, hey...

52:36
I'll write all of your really important rust. The plan for this agency is not at all for me to be the be-all and the end-all, so my existing business is very much me doing C-sharp and team leads and team lead stuff and things like that. The...

52:53
the new thing is very much not me being the core of this, like yeah sure I'm gonna pitch in, I'm gonna bring my experience to bear when it comes to keeping things on track and reviewing and leading and filtering in terms of recruitment and things like that, but yeah, I fully intend to have people who are far better at me at this than...

53:15
doing the actual projects over time. So I just wanted to mention that in case people get in the wrong end of the stick with this one. This is not a solo enterprise. The fact that the likes of you, Jim, are even considering doing this kind of stuff is encouraging because I think you'll be far better at this than me because you come just from the right background to really get rust properly, whereas I will probably for quite a long time be...

53:42
using my C-sharp clown feet and making things work, but not like really that great way. Well, I think we've both got a bit of that in store for us, to be honest, because there are definitely at least one or two paradigms in Rust that I find completely fresh. Certainly.

54:07
Yeah, I mean, I don't want to go into it too deeply, but the the the borough checker is something that strikes me as nothing but positive, because it makes a serious attempt to systematically solve whole classes of problems that dog people working in things like C++. And and at compile time, which is a critical thing for productivity and and avoiding the thing we all hate the most, which is debugging, of course.

54:37
And that said, the lifetime side of it is still a bit mystery meat woo to me, I fully admit that. And one of the things I look forward to is getting my head around exactly how that works and getting some conceptual solidity on that because I sense in it.

54:56
the potential similarly for knocking down whole classes of problems, especially with manual memory allocation in a genuinely new way. So I see that that latter one is definitely one I'm still, I still haven't got my head around. The formal one.

55:17
more so in that it corresponds with the kind of design patterns that I've had to practice time and time again for writing reliable multi-threaded code. The borrower checker fits with that mentality. The borrower checker and how it corresponds to the classic reader's writer lock, which is a great primitive that's still not sufficiently widely used.

55:41
for multi-threaded programming. There's a correspondence there that fits me conceptually. So, the borrower checker excites me pretty much exclusively, much as fighting it is a thing, mainly because people really.

56:01
in my opinion anyway from what I've seen so far, fight the, fighting the borrower checker amounts to people really, really don't like being forced to write correct code the first time. Whereas the lifetime stuff scares me a bit, but I sense in it similar massive promise that the borrower checker has for.

56:21
just getting rid of classes of problems that none of us particularly like having to think about actively, so yeah. Yeah, I definitely, there was a bit of a hump for me with the borrower checker, but I feel like I've made friends with it now. Like there was a couple of difficult learnings that.

56:41
because this stuff doesn't exist in C sharp in any way at all that I just couldn't do anything to start with and then I got to a point where I was like, oh I see what it's trying to do here and what that means for what I can assign one of the big things that passed me by the first time around is that you can define an immutable variable and give it a value and then you can define a mutable variable and pass it in and now that's mutable and that

57:09
was not what I was expecting at all, whereas I'm coming more from like the nascent C-sharp immutability where, like once you've made it immutable, then you can do what you like with it, but you ain't changing it. So that was a bit eye-opening. So yeah. You can make a variable more mutable than it started? It seems that way. Yeah, like let mute y equals x, and now I can change y when I couldn't change x. Like it's like the container is mutable. Yeah, it's...

57:38
bizarre. It's it's it's it's kind of like the reference through which you're accessing it. Yes. Or it did, I guess the C++ analog would be defining a mutable object, but assigning it to a reference to const. But in such a way that you can const cast that you can cast the const away later, and produce another reference that lets you mutate it. That's interesting.

58:02
But that is just very good. I mentioned this because this is, this is another of the bug bears I've had with C plus plus over the years. One of the big ideas that I had years ago was certainly the ability to go the other way would be damn handy because for most of my time writing C plus plus, I've been an absolute const fiend. Everything is immutable by default. That again is a design decision of rust that I absolutely love.

58:31
And so I've got used to making everything const, but there are exceptions, of course. And one of the thoughts I had was I would really love to be able to add certain qualifiers to variables after the fact. So be able to

58:50
write a mutable vary, declare a mutable variable, maybe without initializing it, because you have to pass it as an out parameter something. So you can't initialize it directly, but the function call initializes it for you. But then afterwards to immediately say, okay, now it's immutable as a workaround for some of these initialization problems. And there are other situations. So yeah, but the idea of changing qualifications on variables, peaks my interest.

59:20
That's neat. Yeah, there seems to be an absolute tonne of little gems like this floating around. To go to the lifetime thing you mentioned, one of the things that encourages me about that is I also don't really get it yet. I've kind of got some vague idea. The global mystifies me entirely. But I've been able to write stuff that does include lifetime stuff and get by. So in terms of initial productivity, which matters to some extent, that's been quite an encouraging thing so far. Yeah.

59:50
I think every programmer recognises the phenomenon of cargo culting it until you make it. We all have to do it with new stuff. Yeah, I've done lots of that so far with Rust. And it's been relatively pleasant. Like, people had kind of warned me about the borrower checker. So I was kind of prepared for a compiler that hated me. But now I feel like it's like giving me a slightly longer leash because of for good behaviour. I want to gently guide the conversation.

01:00:19
a little away from the details, because we could talk endlessly about Rust's details with our relatively naive understanding. And there is a ton out there on, you know, there's not a lot we can educate people on, like the ins and outs of Rust, there's so much out there. But I think what is interesting to talk about is kind of a bit more about, okay, given all of that, which admittedly was quite long, but that's what I love about podcasts, there's no news on the hour.

01:00:49
What is our interpretation of that and what does that mean in terms of whether we'd use it or not, what the future is for it, whether we see it fitting into our lives, and what kind of properties that gives it a layer out from the actual coding. So I'll go first because it's my show and I can go first and then I'll hand over to you, which is why...

01:01:19
What I'm really feeling positively about with this is it really is showing the promise of being that low-level, high-performance, zero-abstraction thing. No runtime is very unusual, to say the least, especially for a language that has so much capability. No garbage collector, so no glitches there. Although there is this, you can have a garbage collector and there are trade-offs, so it's not always the right thing to have no GC. We had a conversation about that.

01:01:48
And in terms of the ecosystem, it's growing, people are loving it. It really looks to me like this might... This stands a good chance of being a language that is not one that people kind of come to because it's interesting and novel or they're new to programming. And someone introduces it. And then after time, they realize it's really not the thing like this. The ecosystem of crates and libraries.

01:02:17
I think is still relatively immature. There's definitely a lot you could do. I think you could certainly write all sorts of things in production now. I worry a little bit about the security, but I think that's going to improve over time and it's all open source, so this usually goes better than private closed source things. So for me, my feel so far is like this could actually be the language...

01:02:46
that I would like to write all my pet projects in from now on. And would like, I can't just suddenly become an individual contributor in Rust overnight from C-Sharp. Well, to be honest, I could, but I'm not going to. I'm not going to just throw away all that experience. I'm going to continue in my servicing C-Sharp clients. But I think I can join the Rust community and contribute in that world. And this, this agency idea I think really does have legs.

01:03:16
So I'm super positive about the whole thing at the moment. Like I've spent quite a long time getting my head into it, learning it both like ecosystem level and me actually trying to build something, which is always like you say, very instructive. And after all of this, I'm still really positive. I haven't come across anything which makes me think, listen, this is not gonna work. This is, oh no. Cause sometimes you learn a language and you get in there and then you're like, oh, they did that. Like I had a crack at Django.

01:03:45
and then I tripped over something and was like, oh this is junk. I'm never going to use this. This has not got a long life. I know there'll be Django stuff out there, but this is never going to take over the world. And Ruby on Rails is obviously huge, but it's dying and they've kind of done the opposite of Rust, which is, whereas Rust does what they call shift left, like make all of your errors earlier because they're cheapest to fix.

01:04:15
the earlier you find them, Ruby's kind of the opposite, which is like, roughly prototype something, ship it, and then prove that you've got a business, and then refine. But having used it, it really hurts not having types. Like, being able to pass anything you like as arguments to a method that might not even line up, and you only find out in your unit tests or production, like, is horrifying to me. And I think after a while people realise that...

01:04:44
it's not so great maintaining these things and maybe they don't want to write their next project in it so yeah that's about where I'm standing on the whole thing right now what's your feel from your exposure so far?

01:04:59
Well, just to comment on that last point very quickly, that this whole issue of not having a type system, it feels like something that actually works surprisingly well for small systems, for simple pieces of software. Yeah, knowable systems. What ones where you can keep the whole thing in your head as a single programmer? Exactly. I've done Ruby, I've worked on systems like that. I didn't spend my life.

01:05:29
dealing with violations of type expectations in function calls. But I can see how that would become a big problem once you try and do something less trivial with it. So in general, I think I'm happy to out myself as a card carrying type system bigot that that's just something you've got to have on your side at compile time for anything non-trivial. Where I found- Or you're gonna have a bad time. Where I found that that fell apart in my experience was not so much that, you know.

01:05:58
somebody passed the wrong thing in, it was more like, when you're thinking about making a change, the question is, where is this used? And if you have a proper type system, then the compiler or the interpret, the, what do they call it? Like the code analysis systems can say, I can guarantee you these are the places this is used. In Ruby, it's like, have fun searching the code base for strings, which is not a great basis for refactoring. And you better, this is partly why I think the Ruby,

01:06:26
are so keen on testing is because without it they're completely sunk. So just tell me something on that. If you make a function call in Ruby to a non-existent function, what happens? Does that get called with compile time? No, it's an interpreted language. Oh yeah, because even if it had checking for the existence of functions, then one could use some of the tricks that I use in things like C++ of

01:06:56
when I want to make a change, I just rename the thing and let the code break. And then that's how I find out all the places it's used. But if you don't even have validation of the existence of functions at compile time, you're really up a creek there. So yeah. Yeah, and I wonder if having worked on Ruby things before, like maybe there are businesses out there who have a Ruby code base and they wanna rewrite some or all of it in a language that's not gonna be so painful for the long time.

01:07:25
long term, maybe they want, maybe their rails costs, hosting costs are killing them. And they're like, what's next? And Rust might be a good candidate for starting in the middle and working outwards. Yeah. As for the more general picture, but what kind of thing are you looking for me to comment on there? Kind of what your feel is about what you've seen so far, like

01:07:54
You've mentioned that like actually this might might potentially be something that you could get more into Yeah, just elaborate on that really like what was like the broader picture, you know What's your assessment of the ecosystem from your limited knowledge like the business side of it? Yeah, I think is of interest you really but the one thing that struck me is your comment that this is the Language, I would like to do all my projects side projects in or all my projects in

01:08:23
That's a sentiment I recognize. That's basically my life as a C++ programmer up until now. That when you enjoy the mentality behind the design of a programming language, it's almost like a friend that you want to spend more time with. And that's a lot of what's kept me using that language for as long as I have, despite the deficiencies. So...

01:08:49
Yeah, I, I, I sense some of what you sense in rust that way, that this is a language that could also become a trusted friend, surely say that I want to spend lots of time with. Um, and yeah, it's, it seems to have all the basics, all the things you would expect like type systems. Um,

01:09:15
it does all the obvious compile time checking that you'd even expect from something like C, but I just, I feel like there's a paradigm shift where there's actually been the courage to take on classes of problems that even C++ has kind of drawn a line in the sand and said, no, we're not going there. And maybe that's because it's an existing language and it's impossible to retrofit this kind of stuff, but then...

01:09:45
from what I gather, things like the borrower checker were not always in Rust, and they simply evolved them into existence. So it's interesting from that angle that it is possible to... One thing that strikes me about it from those things like that is that Rust is more than maybe any...

01:10:10
other recent language I've come across. I mean, I'm sure this is going on in the 70s a lot during the development of things like C. It seems like a modern example of the evolutionary approach to programming language design. And that's the kind of thing C++ has always had. And although that has now reached a level of complexity and

01:10:35
fullness of features and complex interactions between the features that make it extremely hard to continue with that evolutionary approach, which is why C++ of zero X turned into C++ 11. Because it seems the committee just bit off more than they could chew. They didn't understand the full weight of everything that was already in the language enough to know how much to take on in one release.

01:11:04
And they've done much better since, because I guess lessons were learned and they now fully understood what they did wrong there. But very few languages continue to adopt an evolutionary but radical approach, I guess is the way of putting it, in the way that C++ has done. Introduced like, for instance, you don't need to...

01:11:33
know what this is, but people like me will know things like R-Valley references in C++. They are only introduced in C++11, I believe. But we're talking about a foundational paradigm shifting feature to add to a language that's already 20 years old. And so there was a certain amount of courage in doing that radical but evolutionary change.

01:12:00
And I feel like a lot of the spirit behind rust as evidenced by the fact that the borough checker didn't start out being in there, but now it is, um, as that that's, that's, that's in rust. It seems to me the community or whoever's responsible for evolving the features of the language have the necessary guts to do major new paradigm shifting things and really explore, make rust an exploration.

01:12:30
in the entrepreneurial spirit that a company is really an exploration, like where a company ends up, it's not a foregone conclusion. It's a function of the specific audiences it had at different times and the specific things those audiences valued because of a myriad of factors that had nothing to do with the language. And so in a way, it's really a recognition that

01:12:59
that it's the journey, not the destination. And the hope that the destination will be good if the journey is undertaken diligently enough and with humility regarding what's important. So I sense a spirit that I like behind Rust that's similar to the extremely disciplined spirit of the C++ standards committee, but with a younger language that has more room for maneuver.

01:13:29
to do this radical evolutionary change. And so I don't know what Rust has gone. They definitely got a second mover advantage there. Yeah, I don't know what's coming to Rust in future. Maybe they've got more paradigm shifting ideas, but even, and I might be showing my ignorance here, but as I said before, I think the major two paradigm shifting ideas I know about so far are the borough checker and the lifetime system.

01:13:57
And to even to take to produce something that is C++ like enough to interest people like me, but also has two major areas of conceptual innovation to make the job of programming easier. It's like, I think, in some sense, Rust has already proven its worth as a contribution to the field of programming language design by this point.

01:14:25
and it's by no means finished of course, so who knows. Yeah, there's two things that I'm aware of that I'm sure have contributed to this. One is you've got Mozilla behind it who have a real product used by vast numbers of people and Rust is particularly for building that in ways that are more reliable, which means that

01:14:55
they already know how to build and design things in a community in a more distributed fashion. So they they've brought that wisdom of how to run that kind of more egalitarian kind of project in ways that very few things I know of have succeeded like Debian is a notable example of something that has outlived its creator because of the design not so much of the thing itself but of

01:15:25
the community and systems around it. So that's very encouraging and Mozilla have recently spun out the Rust Foundation to shepherd that independently and we hope to have that. Sorry, just to interrupt, but what is this project of theirs that's developed in Rust, if I understand you? Firefox. Really? Firefox is written in Rust?

01:15:48
now? Well it's getting there because because it's um this is one of the reasons it has no garbage collector and no runtime is because um that means that they can piece by piece replace their old C++ code with Rust code and compile them both together into one binary. Wow I'm I'm quite stunned that is a ballsy move. It's impressive. Nice. Yeah I think they started with something very small and it's been expanding and it's been getting better and they've been able to do more and more.

01:16:18
And yeah, that's quite a thing in itself. Yeah, but. And I mean, let's let's be under no illusions. A web browser is a very complex piece of software these days. So whatever, whatever deficiencies Rust has with respect to whatever deficiencies it might have that are only gonna show up in very complex software systems, Firefox is probably gonna get there first, I imagine. Yep. And those problems are gonna get solved. So that's.

01:16:48
Very encouraging. Yeah, I mean, I can't really speak to that because I've not done anything even vaguely close to that. I live in the world of web, but yeah, it's certainly encouraging. And I'm super encouraged by the creation of this, this new foundation to shepherd this thing into the future. And the other thing that I'm aware of that I think has helped them with this innovation is they've got this concept of rust additions and I may mangle this, but I'll have a go. So.

01:17:16
Every project has a cargo.toml file, which is similar to the various dependency files that you'll see in other languages, like a gem file for Ruby or a CSproj file in C Sharp that might define the libraries it pulls in and some other bits. I don't even know what NPM node uses. Anyway, it's not important.

01:17:46
So they have at the top of the cargo.toml file that you include when you create your own Rust projects. A line that says addition equals say 2018. And my understanding of what this does is the single Rust compiler is able to basically behave differently.

01:18:13
compile completely different versions of the language. So by having this say 2018 in here, the Rust compiler is like, oh, okay, I need to use this version of the compiler. But if you change your project, say, the edition equals 2021, I'm not quite sure what the versions are, then they might have completely dropped a feature that you had before and added a new feature. And if your code works that way, then that's all cool.

01:18:40
I think they've got some tools to help you migrate. But the real genius of this whole thing is that you can have things built in different editions and then compile them all together into one binary, which is epic, which means that you can consume a library that was written in a different edition. So you don't have this thing where, like in.NET land, they've got this massive fracture because they had.NET framework.

01:19:08
which only ran on Windows, basically, and then they rewrote the entire thing as.NET Core, which is now a multi-platform, but you cannot consume a.NET Framework library and.NET Core, it's not possible, as far as I know. Someone's probably gonna prove me wrong, but it's certainly not easy. Whereas in Rust, that means that every library can evolve at its own pace to the new versions of the language. That means they can make much more breaking changes, like as long as it all still compiles together, they can do cool stuff.

01:19:39
So this really puts me in mind of something, which is what I've seen happen in C++ development in Visual Studio, and I think it applies to all the other major compilers as well, that the kind of return to radical evolutionary change that the C++ committee has been up to since C++ 11, and since they committed to a three-year release cycle.

01:20:07
for new editions of the language standard, it's ended up in very much the same place where in Visual Studio, you will either for an individual source file, translation unit to use the right term, or for the whole project, you tell it which version of the language to use. So this strikes me as a hard-won lesson from a language with an enormous

01:20:34
amount of legacy code out there. I don't know whether it's millions or billions of lines of code, but it's gotta be billions. Millions is ridiculous. Even the Jurassic Park security system had millions of lines of code. So it's interesting to see such a young language preemptively, whether they, they must have, I imagine they must have been partly inspired by what's kind of happened to C++ organically.

01:21:02
but it's interesting to see a young language that doesn't really need to deal with these problems quite yet preemptively taking on a reasonable solution to improve its own scalability as a language out there in the world with an established code base. So that's nice. Yeah, I'm definitely seeing Rust having had the advantage of being able to learn from everyone else's language challenges.

01:21:30
Yeah, and they've definitely not been afraid to change things. I think it was on the weird video from RustConf that apparently the early version of Rust, if you assigned something to something, the equals operator was formerly like a left arrow, as in less than minus, which is a bit random. Ouch. That gave way to a more normal equals sign.

01:21:58
Yeah, yeah, that suggests that there was a certain degree of inspiration from the kind of functional languages that are extremely popular in very limited circles. And that maybe they're now starting to move away from more towards a better version of C or C++ kind of thing. Maybe actively.

01:22:25
drawing what affordances they can from those languages without inappropriately overdoing it. I think if I can just comment on what you're saying about learning from everything that's come before, I think there's a slightly subtle point to make here, which is that every language, at least for the last 30 years, every language at inception has, its designers have had in mind.

01:22:54
learning what came before. But what feels different to me about Rust is maybe that they're trying to learn on a more meta level from what's come before. Java, for instance, has the obvious hallmarks of trying to learn from C++. It stole a lot of the syntax, sometimes inappropriately, and made a lot of ideological decisions about which bits were not worthy of making it into Java.

01:23:21
because they were too complex or hard to understand or unnecessarily complex for some naive understanding of unnecessary. Whereas what I sense from Rust, maybe I'm overinterpreting here, is that they've learned from that whole cycle. They've seen Rust is new and is, Rust exists at a point in history where there is enough prior history of

01:23:50
of full cycles of programming language evolution, that the designers of Rust can be, can be kind of beaten by a careful study of the history into acknowledging that it's not enough to make a bunch of ideological decisions about which bits are good and bad in previous languages, but to understand how the perception of what's good and bad changes through the evolution of a language, much as has happened with C-sharp, it was

01:24:19
started out as a much, much better, less ideological version of Java, but it still maybe took some things that it shouldn't have from Java. And now it's paying the price in having to revisit some of that and having to become a much more complex language as a result. And I feel like maybe in some degree, the people responsible for evolving Rust are looking at those cycles and...

01:24:47
understanding the harm that naivety and utopianism often, perhaps always, tend to do in the early stages of a language's life. And they're trying to avoid the long-term pitfalls that come with that. It's one of the reasons that it just gives me a better vibe than a lot of other things I've seen, I think. Yeah, yeah, I agree. And to go back to the like, go lang.

01:25:16
rust contrast. Like one of the things that makes me a little bit uneasy about Golang is it like it's a really nicely designed language but it does feel a little bit like they just chopped off everything that they didn't think they'd need from the possible space of language capabilities and you know and also like what they could feasibly achieve to get their key things like compile time and what have you and I don't know how long that stands before.

01:25:45
you know, the dam bursts and it all comes flooding back in again. Um, like they stated intent to not let it, but you know, they've, they've added generics and I don't like the syntax. I think it's ugly. Um, I have zero faith in their statements that they intend not to let it. It's not up to them. The market will decide. It depends what go is used for what areas it finds penetration in, where it becomes popular. At a certain point, the decision is you either increase your market share and try and spread the appeal of the thing.

01:26:15
and give people what they want, or you stick to your ideological principles and in some sense you doom the ultimate popularity of the language to be limited. And yeah, I agree with a lot of what you're saying about Go. I was uncomfortable with the degree of ideological thinking that I kind of sensed when I looked into it when you were working on Schema Explorer, for instance. Yeah.

01:26:44
I sensed some of the ideology that I recognized from things like Java, for instance. And I thought you guys are going to be sorry in the end if you're not careful. Yeah, there's definitely parallels there. Yeah, like they made a minimal thing so that engineers could just get on with it without falling down all these holes. They had a couple of innovations like Java had their checked exceptions and their bytecode,

01:27:13
go routines and channels and its particular way of doing things. But it seems kind of arbitrary, doesn't it? Whereas, and so it kind of C-sharp's been through the same evolution in that the original C-sharp was kind of a simpler, nicer version of Java in a lot of ways, but the same concept of a bytecode, which they called intermediate language. And then they kind of held back the floodgates really for a very long time. And then over the last, I don't know, five years.

01:27:42
floodgates have opened for whatever reason, and they finally decided one, performance is everything. Like I saw a.NET Chrome work post the other day saying, performance is our number one thing, which is not a developers, developers, developers kind of point of view. And yeah, they've been definitely copying everything from everything. So at that point, yeah, there's like, like you say, it'll bite because

01:28:11
If you design your language kind of in an ideology of simplicity, then you haven't, by necessity, you've not left room for all of the other things that are going to come down the line. And then you force yourself into corners where, well, you can't have a nice syntax for that because that would conflict with this other thing that the compiler would interpret it as. And you can't change that because you'll break all the existing programs. Therefore you have to do something that sucks. And, you know, that lasts more or less amounts of time.

01:28:40
And, you know, I'm sure C++ and Rust have and will suffered from that. That's kind of unavoidable, and to an extent, the only answer to that is a brand new language.

01:28:54
thing is if I'm being honest of course there are aspects of ideology to everything and I can name one piece of ideology that I recognize in both C++ and Rust which is the Beyond Star Strips dictum I think it is originally about C++ which is you don't pay for what you don't use. Mm-hmm. Yeah that's definitely a good one. Zero cost abstractions is mentioned a lot around Rust. Exactly.

01:29:24
I can only assume that's a weird kind of exception. It's the kind of ideology that is so abstract that it has relatively few downsides. And it is, given that I think there's an element of...

01:29:44
attraction to some degree of ideology or utopianism in every programmer, because why else do you become a programmer? You want to write stuff that can help as many people as possible. Programming is the best way to scale your manual labor as widely as possible. Nothing else compares to it. So in some degree, programming as a discipline has that ideological foundation. And so I like to think that you don't pay for it, you don't use zero cost abstraction.

01:30:15
piece of ideology is something that we can all live with. Because what's the alternative? You do pay for what you don't use and plenty of languages, especially Java, have tried that. And it's not clear that in the long run it offers any great advantages. No, and certainly the horrors of like, oh God, we have to run the JVM on our server and worry about tuning the memory usage to be somewhere in the region of gigabytes is not much fun. Exactly.

01:30:46
Yeah, why is my Java service down? Oh, because you limited it to only 1.5 gigabytes. Oh dear. In the JVM. Yes, well, let's just say that I've seen that in C++ as well. A former client who shall remain nameless was unable to do 32-bit builds of their core software product because unrestrained template bloat through generations of

01:31:15
of insufficiently restrained programmers working in C++ had basically made an executable that I don't even remember how long it took to build, but the final executable was five gigabytes. So. Yes, yes, it's what we programmers like to refer to using the technical terminology as bonkers. Absolutely. Right, I'm gonna.

01:31:45
wrap this up because I've got a long day tomorrow. And the way I want to wrap this particular interesting flowing conversation up, which hopefully has been interesting to more people than you and I. I should mean we don't lose the recording. You've jinxed it now. Oops. Well, we're using this wonderful new riverside thing, so it's all cool. We shall see.

01:32:15
is to kind of summarise all of the above in terms of, it seems to me that it's silly to naively go into a brand new language and kind of go, right, this is the brand new thing, let's go, let's write everything in that. Because there are things that you could figure out that would bite you and trade offs that you would realise if you thought a bit harder and tried a few things out that you should

01:32:45
I'm getting deep enough that I'm getting significantly more confident that there is really not that much to make me think otherwise about this. This is really just such a solid language and ecosystem, it's interesting, it's probably sustainable for a very long time, and at some point you basically just have to take the gamble and get on whichever language ride is going.

01:33:13
and see how it goes, you know, hang on. I mean, in the end, the worst case is to learn another thing. You know, it'll be many, many languages down the line for me, I mean, goodness me. More or less deeply, you know, Pascal, Delphi, C, C++, C sharp, VBScript, ASP classic, SQL, like, oh, goodness, Ruby. What else was I trying to write? JavaScript, don't forget JavaScript.

01:33:41
Yeah, definitely showing my age. No COBOL, so I'm all right. Someone, one of the older coders on our project shared a, look, this is COBOL and picture of some punched card. If you want to be rich, just go learn to code COBOL and learn how to unscrew an enterprise mainframe, because apparently there's still enormous money in that. But anyway, back to the summary. My feeling is we've been

01:34:11
kick the tires quite a lot on this now and I'm pretty happy to get on this train and see where it goes, be along for the ride. How are you feeling on that kind of judgement call at the moment? I know it's much earlier for you. I think it's basically sound. I mean, I've really come to value the kind of running commentary you've been giving me on your experiences with Rust.

01:34:41
because it's been a fruitful source of conversations, but it's just every now and then a little nugget of insight into the mentality of the language has filtered through to me, basically without the cost of having to go away and write it for a week. So it's been nice to kind of parasitize on your journey that way, shall we say. In the bigger picture, I think if I look at myself,

01:35:09
Let's say we live in a world where five years down the line I'm knee deep in rust and quite conversant with it myself. There are undoubtedly gonna be things that annoy me about it because every solved problem makes room for you to see a new problem that was just too big to worry about before. And there might even be things where I think, God, I wish this was C++ because I could use this pattern that I can't use in rust.

01:35:40
I have a strange feeling of confidence that none of that is going to be big enough to break my enthusiasm for it as and when I do get into it. My experience, this goes back to my comment about how I think it's the most serious contender I may maybe have ever seen for a C++ successor. With almost any other language, I can spot the things that are going to tick me off.

01:36:11
just by reading a description of, a very high level description of the language, I can immediately see the ideological decisions and how my experience shows those decisions to be questionable and quickly develop a bad taste. And I haven't yet come up with anything, come across anything about rust that leaves a major bad taste in my mouth that way. I feel like I trust the,

01:36:40
the philosophy of the minds behind it and that they have that ideological angle sufficiently under control and are capable of looking far enough ahead in the language's evolution to avoid stepping on the kind of rakes that designers of new languages have been stepping on for the last 30 years repeatedly and painfully for people like me. Head, desk, et cetera.

01:37:08
And that's not to say that in 10 or 20 years, I mean, looking at things like the borough checker and the lifetime side of Rust, as I say, these seem to be major paradigm shifts in pushing the state of the art of static code analysis, pragmatic static code analysis forward, not the kind of static analysis where you can prove the behavior of an entire program without running it, that is basically impossible for any non-trivial system.

01:37:38
but that people use to the maximum extent possible where safety critical systems are involved. It's a much more ground up evolutionary, bottom up rather, let's just push the state of the art of static analysis forward where we can, introducing one concept at a time. So it strikes me as what the C++ standards committee would do if they cared more about

01:38:08
that if they, how can I put this, if they had more of a burning faith in the importance of pushing forward static analysis as a tool to help programmers in the future. So in 10 or 20 years, maybe something will come along or be invented that is able to supersede some of the limitations that rust has accrued, some of the areas of

01:38:38
static analysis and verification that they weren't quite able to even see because they were being evolutionary about it in the same same way as with language features in general. Static analysis features are bound to suffer from the same problems in the long run that at a certain point you have to get more holistic and start from scratch and make use of what's been learned by previous languages and start from a better place. But for right now.

01:39:07
Um, if it's, if it's actively pushing the field of, of static verification to help the programmer forward in a pragmatic way that does turn out to be better than what's generally come before, then what's not to like, what else are we going to do sit around for 20 years and wait for its successor? It's still going to be less frustrating than trying to use things like C plus plus. So why not? Yeah.

01:39:36
Yeah, I mean we're almost into the realms of computer science sci-fi at that point, are we like visualizing what the future could be, which is fun, but doesn't really help us know what to write in now. Cool. Yeah. Right. If there's one thing I've learned from sci-fi, it's that trying to predict innovation beyond a 50 year maximum time horizon is totally impossible. Yeah. I still love watching it. Because I know it. I'm reading it though. Oh, absolutely. But I've been watching it and...

01:40:04
reading it for long enough to see a sci-fi that is 30 and 40 years old in a new light and to see all the things they got wrong, like chunky displays that are supposed to, that looked futuristic at the time, for as a silly example, but there's a lot of deeper stuff. And yeah, it's futile to try and predict on a scale of too many decades. So do you just get on pragmatically and...

01:40:34
have the best and try and have the philosophy that you think is gonna advance the state of the art as much as possible in the near future. Yeah, there we go. Maybe there's a tagline for the Rust Workshop. Something about pragmatic. It's a bit verbose. Might have to edit it down. The pragmatic future, there you go. Pragmatic future, I like it. Anyway, right. Thank you very much, Jim, for joining me.

01:41:02
This might be an awkward question, but is there anywhere that people can find you online should they wish to I'm I'm currently working on on Getting together more of an online presence in the medium term. There's nothing much for the time being but Okay, I hope we'll talk again on this podcast and I hope to be able to give a Better answer to that question in future. Well, if if there is then we can stick in the show notes underneath. So

01:41:31
check the links under this. My personal home is timwise.co.uk. The consulting company is charmconsulting.co.uk. The Rust workshop is so new, it doesn't even have a domain, which is quite something, but it will do, along with wherever this podcast lives. So check the show notes for links. And if you follow me on Twitter, I am sharing my little piecemeal learnings in the open at the moment.

01:42:00
So all that remains to say is, if you would like to work in the Rust workshop as an excellent coder, then get in touch, and if you would like to bring an interesting problem to the Rust workshop for our excellent Rust people to work on, then get in touch. And that is that. See you next time.