Matt (00:00): Hey, Ben. Ben (00:00): Hi, Matt. Matt (00:01): How's it going? Ben (00:03): Good. Matt (00:04): So it's that time of the week again. And you and I are staring at each other through, uh, webcams and blurry backdrops and all of that. I...how much processing time do you think is being wasted by GPUs blurring backgrounds or substituting in other people's backgrounds right now? I mean, there's gotta be a substantial amount of heat death of the universe is caused by, uh, Gmail, not Gmail. Uh, Google, Meet and , Ben (00:30): yeah, yeah Matt (00:31): Um, Zoom and all these things like doing these, this really intense AI operation to determine what is foreground, what is background, and then doing something with the background. Ben (00:39): Yeah. Well, you know, now that crypto's crashed, we gotta do something with all those GPU's, so might as well be this. Matt (00:45): Very good point. . So we staring at each other. We, we staring, we're staring at each other. It's that time and this week I figured, um, we've been talking on and off about various different languages and our experiences with them. Obviously Python, JavaScript, C++, um, html, such as, that's a language. It's got, it's in an L so it's a language, Ben (01:08): Right? Yeah. The L does stand for language. Yeah. Matt (01:11): Like sequel, Right. SQL structured query language. You know, it's not really that structured. You can do more than query with it. And so questionably a language. Visual source safe, again, none of those words are true. Ben (01:21): True . None of the above. Matt (01:23): , none of, Anyway. We, I feel like we're, again, we're, we're off target already, but the talking in general about languages and the one we haven't really spoken about is rust. Ben (01:33): Mm-hmm. . Matt (01:34): Mainly because you and I haven't got as much experience with it as perhaps we ought to in order to have like really strong opinions, but we have used it. Ben (01:43): Yes. Matt (01:43): I've used it on a couple of projects. Uh, I've got a toy project that I, uh, created, which is like my standard way of learning a new language, which is to write a ray tracer or a path tracer in it. And that was a lot of fun and it's pretty performant. I was very impressed with it. But that was a while ago. And then I've written some command line tools in it since. And you've done some work on it too, right? Ben (02:03): Yes. Yeah. I, uh, made some changes to the, um, Ethereum, uh, node software that was written in Rust. Matt (02:13): Oh. Ben (02:14): To do a little bit of research into how the Ethereum network worked. And this was like, gosh, three years ago, and I have basically forgotten everything about that project. Um, I, I probably remember a few interesting things to know and tell. Um, but my intent, what I was trying to do there, and what I, I think reasonably accomplished there is to sort of draw a, a, a map of what the Ethereum network looked like, not necessarily from a geographic level, um. Matt (02:46): Right. Ben (02:46): But more like a, um, you know, what nodes are actually producing the blocks that wind up in the blockchain, and how do those blocks propagate across the blockchain? Because at the time, time, I was really interested in prediction markets. Um, Auger was one in particular that was, uh, had a lot of attention and, and was, um, you know, people were talking about on, on Ethereum. And I was like, well, I mean, knowing what I know about traditional financial markets, uh, if someone's gonna place an order and it's gonna take some amount of time to get to the exchange where it's gonna actually be recorded, uh, being able to know that that order is coming has a lot of value. And that is, Matt (03:34): I see. Ben (03:35): actually what the, Matt (03:36): And is talking about like in a distributed exchange, like you would see on an Ethereum-y magical something, something. Got it. I see. Ben (03:42): Yes. Yes. So I, I was like trying to figure out if this was a problem, basically. Like, is this a flaw in the theory behind distributed, I mean, would really be any distributed type of exchange. Yeah. But specifically I was interested in prediction markets and, and Augur in particular. Um, Matt (04:01): What is a, what is a prediction market? I feel like we're going, we're getting derailed immediately here. Ben (04:05): Yeah. Right. Matt (04:05): You should tell me what a prediction market is because sounds Ben (04:07): That sense go way. We're gonna put a lot of things on the conversation stack, and then we're gonna pop them back off again and figure out where, and then we'll be like started. Matt (04:14): Yes. Blury backgrounds, Ben (04:15): Blury backgrounds. Um, so yeah. Um, a prediction market is a, uh, a particular type of financial exchange. It's similar to a, a futures market. It's similar to, um, uh, if you know what a binary option is, it has some similarity to that. But basically the idea behind a prediction market is that you use the quote unquote wisdom of the crowds to predict the probability of future events by letting people bet on whether those future events will occur. Um, Matt (04:51): Okay. Ben (04:51): There have been a few of these, um, sort of normal centralized ones. I think there was one called sort of an Insight. I wanna say insight Matt (05:04): Wasn't, That's correct. It rings a vague bell that like some university was involved with one of them at, at some stage in order to. Ben (05:09): Yes, well, there's one called PredictIt. Um, Matt (05:11): Right. Ben (05:12): Which actually recently I think got shut down. They got their, they had gotten a letter, a no action letter from, um, some government agency, the CFTC Matt (05:22): FCC or the FTC or Ben (05:23): Yeah. Something like that. Matt (05:25): CRC error Ben (05:26): Yeah. And the, that agency recently rescinded their no action letter because of some things that PredictIt was doing. And all of, by the way, when that happened, I'm sure all of the auger and sort of Ethereum based distributed network, uh, prediction market folks went see, see! I told you so see, see! Matt (05:45): Right. Ben (05:45): Yeah. Um, Matt (05:46): So this prediction market is somewhere where I can bet on a future thing happening or not, so like what, like a, a presidential election or something like that. And I say, I think, uh, the conservatives are gonna get into the next uk, uh, general, um, election. And so I, I bet. But who's taking the other side of the bet and how do you, how does someone work out the probability of that happening or something? Cuz like presume I like bet a hundred quid or whatever, and then someone will like, Yeah. What, what, how does that bit work? Ben (06:22): Yeah, so I mean, the, the way that different markets do it in different ways, Um, my memory of Auger is that the way that they did it is that you, you basically, uh, wound up creating two tokens every time you, you sort of placed an order. There was, there was one that it would happen and one that it wouldn't. And if the, the transaction got through, or basically if the order was filled, if you matched with somebody else that that took an opposing, uh, position at a matching probability and price, like that's sort of the, the magic markets is that the price and the probability are the same. Matt (07:02): They're linked together in some way. Right. Ben (07:03): Right. Exactly. So, like, you know, in the case of PredictIt, it was like all of the prices have to be between one penny and 99 cents. Right. Um, and that was the, basically the probability that you were saying, you know, if you're buying something for 56 cents, you were saying there was a 56% chance it was gonna happen. Matt (07:18): And something like you buy it for 56 cents and it's either worth nothing or it's worth a dollar when the market actually, when you decide, and therefore the price approaches, uh, the certainty of the event as, Ben (07:32): Exactly Matt (07:33): Yeah. Got it. Okay. Now that makes sense to me at some sort of very hand waving level. Ben (07:38): Yeah, Yeah, Matt (07:38): Yeah. But like, so any exchange, I no, from a tip, traditional finance point of view, I, like you say, any exchange knowledge is power, and if you can see somebody is strongly buying up something on one side of your network and you can see that the price is therefore, therefore going to go up, you can take advantage of that. And that's what you were trying to do with this was to say, is that a problem? Ben (08:00): Yes. Matt (08:01): Can this actually be gamed in some way, or is it just fundamentally flawed? And in order to do that, we're going slowly back up the stack here. Although I can easily go back down. Ben (08:10): We're gonna get to Rust here any minute! Matt (08:11): Any second. Any Second. You, you wrote a program in Rust that parsed some kind of exhaust from the Ethereum network itself to see how information traveled across the network. Ben (08:23): Yeah, I mean, I wouldn't even give myself the credit to say that I wrote a program in Rust. What I did was I made some modifications to the, uh, rust Ethereum, the, the Ethereum node that was written in Rust to capture some information as it was flowing through the node and to sort of, um, intentionally and change its behavior a little bit. Basically what I would do is when an Ethereum node connects to the network, it finds some number of peers that it can pull information from, basically pull the blockchain information from. And I made some modifications to that to actually actively seek out peers in the network. So you, instead of just taking whatever peers I discovered. Matt (09:07): I see, Ben (09:07): I would try to like backtrack and figure out like, okay, well you got this from this node, so I'm gonna go back to that node, connect into it directly and figure out, oh, you got this from that node, and sort of try to work my way back and be like, where is this block coming from? Right? Like, what nodes are are generally originating the blocks on the blockchain, um, because that is probably the first reliable place that you would see this information. Additionally, the other thing that you can do when you connect to these node is look at the transaction pool. So these are the pending transactions that may or may not show up in future blocks. Matt (09:42): I see. These are like, Ben (09:44): and you get Yeah. Matt (09:45): To be mined in the kind of bitcoiny sense of it, there are things that are, are, are yet to be checked to make sure that they are actually okay in terms of the rules of the network, but they will be put into the next available block once the, once whoever wins the lottery, wins the lottery and publishes a new one. Got it. Ben (10:02): Exactly. Exactly. And you can see, you know, the gas costs that they're willing to pay. And, you know, the way Ethereum works is the higher you pay, the more you pay for, for your, your transaction costs, your gas costs, the more likely it is that you'll wind up in a block. So you can look at like, it's almost like being able to look at the queue of incoming orders into an exchange. Like these orders haven't hit the. Matt (10:22): Ohhh Ben (10:22): the book yet, but they will at some point Matt (10:26): Assuming they aren't like, um, yeah. Assuming they aren't ill formed or they haven't got that double spend kind of things. That's the whole thing that the blockchain and technol, sorry, the whole, the thing that the miners are supposed to be doing is doing all these checks. Ben (10:38): Right right. Matt (10:39): Then, then that will stand, that order will stand once all the checks have been done. So you can look at it and kind of go, well, this is an intention to send an order. Ben (10:47): Yes. Matt (10:47): Even if it isn't an actual order. And you can use that as a Oh, that's really interesting. Right. Ben (10:51): Right and you, you can even do some things to validate for yourself that those things will in fact clear through. Matt (10:57): Right, because you, you could be right mining yourself at this point. Ben (11:01): Yes. Matt (11:01): You could, you know, your node is capable of doing the mining, it's just that you need to solve some drastically complicated maths problem in order to mine the block. And that's just not what you're interested in doing. But you could run the same checks that you would do. Ben (11:13): Yeah. Yeah. You don't even need to solve the drastically complicated math problem. Matt (11:17): Right, because you don't care about that part. Ben (11:19): You can do the same validation. Matt (11:19): Don't have to sign it effectively, which is Yeah. Yeah. Yeah. Okay. And that happened to be written in Rust already, so you modified an existing piece of code. Ben (11:27): Yes, yes. So Matt (11:28): What were your experiences like then? Obviously you've done a whole bunch of procedural style sort of C derived ish languages before. Yeah. Um, what were your thoughts about Rust then? Ben (11:40): Yeah. Yeah. The, probably the closest analog to Rust that I had worked with at the time, and this is probably still true, is Scala. I wrote a little bit of Scala Matt (11:49): Interesting Ben (11:50): Probably about 10 years ago, Something like that, um, that had, you know, that sort of like, you know, heavy use of algebraic types and pattern matching and all those sorts of things. Matt (12:00): Got it. Yep. Ben (12:01): Um, and you know, like it was a little hard for me to separate the challenges of working in that style of language versus the challenges of just working in a completely unfamiliar code base. Right. Because this was a fairly mature piece of software and, you know, I I, and I kind of knew the domain, but not, you know, nearly as well as I sort of had to eventually learn to sort of figure all this stuff out. So there was a lot of additional layers of challenge, uh, heaped up on, on top of this to sort of get me to where I wanted to go. But, um, the, uh, the language itself I thought was really nice. Ben (12:40): The tooling I thought was really nice. Matt (12:42): Right. Yeah. Yeah. Ben (12:43): Um, you know, the compiler was a little slow, but it was also doing a lot of work for me. So it was sort of like, Okay, I get why this is gonna be slow. Um, the interesting thing for me, obviously being so like, you know, test driven and everything was like, I tried to write some tests for the code that I was changing and I managed to write a few, but the code in this Ethereum wallet, I don't think was particularly designed to be tested. And, and even if it. Matt (13:11): It's not really doing anything important, after all. Ben (13:13): Right. Of course. Only, you know, only sending transactions worth hundreds of millions of dollars. Um, so yeah, I mean the, the challenge I think was, was finding a new level for a new sort of baseline for me in the balance between sort of types and tests, right. Because like, depending on the languages I'm working in, I might write more or less tests. I definitely don't want to write tests for things that are guaranteed by the type system. That's silly. Matt (13:41): Right. Ben (13:42): Um, and so, um, working in Rust for me was sort of, uh, I was discovering multiple things at the same time. A, how this Ethereum node worked. B like the general structure of this code base, C how Rust worked, um, and then D how to write tests for existing code in rust that didn't just check what the compiler was checking for me. Matt (14:05): Got it. Ben (14:06): So all of those things together made for a pretty interesting but challenging experience. Matt (14:11): But, So what was the, um, I mean just ignoring the Rust aspect of this for a second, what was the upshot, Did you find anything interesting in, in your, uh, a analysis? Ben (14:18): Yeah, I, I'd have to go back and, and look at the data that I captured to remind myself exactly what it was. But it, the, the, what I saw was that there are very, there at the time. It's probably different now. There were very specific nodes on the Ethereum network where it's like if you wanted to see the transactions first, you just go there and you get Matt (14:36): 'em. And these are like nodes where, um, the whole thing's peer to peer, right? So if I want to put a new thing on the network, I connect to my, to just some random peers. But clearly the folks who are placing orders more ha are either geographically located in a place where their client had connected to them to some set of peers that were able to take the load or, or, or some other aspect. But, and you were able to say, Well, this is, these are where you should go if you wanna see those kinds of orders. And, and yeah. Whatever reason, for whatever reason, Ben (15:05): Right? I didn't come to any conclusions about the reason. And at the end of the day, it's not really that important. Like, is this happening because of internet network topology? Is it happening because of geography? Is it happening because of default settings in the network or the nodes? It's like Matt (15:18): Right is it literally the connections.ini file file in there. Ben (15:20): Right! Right, right, right. Um, but it doesn't actually matter if, if the transactions show up somewhere first, Matt (15:26): That's where you want to be. Ben (15:26): You wanna be there first. Right. Um, so that's, that actually, um, discouraged me from pursuing any more stuff with distributed, um, prediction markets on Ethereum. Cause I was like, well I think this, I think this game is, the game you're playing here is not, you know, how do I operate effectively in this market? The game you're playing here is how do I get the transactions first and, and literally front run, I mean, people use the term front running for lots of things, Matt (15:54): Which is a legally defined term I would just like to say. Ben (15:57): Exactly. Matt (15:57): Because people use it in a lot of ways that are not correct. Right. Especially given our industry. We're a little sensitive to that. In this case, literal front running because you could observe the pending orders that were yet to be, um, placed on the blockchain and you could make a decision based on them. And then you could try and get your order in before them by sending it to faster nodes or different nodes or more, or some, some Ben (16:21): Just pay more gas. Matt (16:22): Or pay more gas! Ben (16:22): You could send it to exact same node. You say, Okay, they're paying more, they're paying two eth of gas. I'm gonna pay three eth and I'll get there first. Matt (16:29): Yeah, that makes sense. So, yeah. Gosh. Ben (16:32): Yeah. So that really dissuaded me from doing anything in those markets cuz I'm like, this is very gameable. Um, and that was, that was basically my conclusion. And then after that I just stopped working on all the Rust. I, I kind of like, it's almost like you have the revelation and you're like, Oh, you just sort of like back away slowly and that was it. Matt (16:51): Yeah, well, so a lot of Rust there, but there was a lot of other things going on for you. Yeah. So my, my type project was, uh, at least the first one I wrote was this, uh, path tracer or Ray tracer. I mean, they're similar path tracing is what it's doing technically. But ray tracing, if people know what ray tracing is, it's basically that. Uh, and I do that. I've done that in pretty much every language. Um, I've, I've learned of recent times. It's just like my kind of icebreaker. I know the domain fairly well. The maths is pretty interesting. There's some modeling things. It's kind of an OO-y type project, but you don't have to do it in OO In fact, I have a talk where I write that program three different ways in just in C++ using, uh, object oriented or functional or data oriented design kind of techniques just to show that they're how multi paradigm C++ is. Matt (17:41): But anyway, I was writing this in Rust. I I'm very familiar with it also. It's almost like the opposite of your problem. I wasn't exploring anything other than the language. And, um, my experiences were very positive. I, I also, and this was a little while ago, I also hit the compiler is slow issue. But then I, I know that it has improved a lot since when I was, uh, writing this particular bit of code with, um, and I was able to crack out something that I was pretty happy with. And then, uh, where I fell over, um, was trying to get it working nicely with, with multi-threading. And maybe that was just my inability to express to the compiler that what I was doing was quote "Okay". Uh, because I couldn't convince at the time the borrow checker that the way that I was sharing mutable state, sorry, sharing constant state and had some things that were mutable that had locks around them. Matt (18:30): I couldn't explain it to it that like, Hey, I've got eight threads here, and they're all doing different parts of the picture so you don't have to worry about them treading on each other's toes. I promise you, again, either maybe I was mistaken than I was actually doing something I that wasn't safe and it was just, but, um, or, or you couldn't explain it at the time or I just didn't know how to do it. But certainly I ended up writing unsafe around just one tiny bit of the code. And that's, again, somebody could probably go and find it on GitHub and tell me what I was doing wrong. But, um, that kind of was like a reminder that there is an escape hatch in Rust for things. Um, and you know, the, on the one hand I was disappointed, I think at the time, was like, Oh gosh, this is silly. Matt (19:09): Can't do any non-trivial program without invoking, you know, unsafe stuff. Which turns off all of the, the, the things that Rust guarantees you, which we should actually talk about. Because obviously if people are listening here, just two us talk about Rust, the things that Rust can do for you is pretty clever, the compiler. Um, but it occurs to me on sober reflection that all of C++ has the unsafe keyword right at the very beginning. That's like the first thing you open, void main unsafe is what C++ is. And so kind of anything, anything that restricts the scope of the unsafety to smaller and smaller parts of your code is gotta be, is gotta be a good thing. Yeah. Um, so, you know, but I think probably that is just something I've learned to carry around with me. And then I trust myself rightly or wrongly not to write code that is unsafe inherently, even though there's no protection in C++ from you doing it, you can easily do the wrong thing all of the time. Matt (20:01): And that's why I turned on all the warnings, have all the sanitizers, all of these things to try and give me a, uh, uh, a, a safe mode light. Um, but Rust has it kind of as the default, which is like a huge, huge, huge boon to Rust. And so one of the things that Rust has is the borrow checker. And this is like a technology, a relatively novel to my knowledge. I don't know where it came from. I maybe a, a research that was done just for the Rust language. But it is a way for the compiler to track in the type system the kinds of references that objects have. And so you can pass an object to some other function by reference. And the contract there is that the lifetime of the objects from the passer to the passee, um, the lifetime of the, uh, uh, the, the caller effectively has to be longer than the lifetime of the callee. Matt (20:56): Right. The callee can't hang onto it, unlike say in C++, where you could just go, Oh, thank you for passing a pointer to me. I'm gonna store it in a, in a member variable now inside my class. Like that would be an error in Rust. Cuz it's like, no, no, no, no. I can't prove now that you aren't gonna live longer than the person who called you. So you can't do that. And there are ways and means of explaining when it's okay. One of the ways it's okay is like, actually I'm not passing you the value. I'm not giving you a copy of a reference to the value. I am giving you the ownership of that value. It's yours now. I can't see it anymore. I can't use it anymore. And now you have it. And now again, that's fine. That's safe there. Matt (21:33): You, the lifetime now lives with you and, and I, I can't see anymore. That's great. And there are all sorts of ways of dealing with, uh, mutability and non mutability. So you can pass multiple references to multiple objects for an object, that are read only, uh, if the compiler can prove that the caller, again has a longer lifespan than all of the things that it's passed to, but you can only pass out one. Um, sorry. You can only pass out one mutable reference where, and you can't have any read, like read only references at that point. So kind of a bit like, um, I suppose like locking, you know, you got optimistic read locking, you know, everyone gets, gets a read locker lock, but the writer's lock, uh, requires all the readers to go away. And then you are uniquely the person with the reference to that object. Matt (22:16): And that's done again in the type system, which is really, really clever because that means that there's a category of bug that you just can't write. You can't express it exactly as you were saying with the test that you are writing. Um, any test that says, Am I using the, am i is the lifetime of this object Okay. Is moot because it just won't compile if it's not right. Yes, exactly. And that's amazing and powerful. But because programs are complicated and obviously it is in general impossible to determine the flow of a program statically, um, there, there are limitations of what the borrow checker can do in, in code. And that also takes a while. It's a part of the reason that the, the compilation process is a little slower is it's gonna do this kind of tracking. So that's why that's my experiences with Rust was trying to explain to the borrow checker what I was doing was okay. Matt (23:05): And then more recently I wrote a little command line tool to replace like 25 lines of Python and it was about 25 lines of rust. And it just worked and it was really easy. Um, I found it quite like the, the command line parsing library was, was there and easy, and we should say Rust has an amazing community of, of libraries that are easy to install using cargo, which is like the one size fits all executable that is like, build the code, download the dependencies, um, package the code, send the code up to, um, to, to be shared. It's just great and it, it does everything the right, the right way by my, my own personal biases of how things should be done. Ben (23:48): Yeah. Yeah. Matt (23:49): So, um, yeah, that was a really good experience writing a little command line tool. And as a pleasant surprise to me, almost everything that is built by default is statically built, bundled into the executable, the resulting executable. So as long as you have a somewhat contemporary libc and a couple of other like very core libraries that you are likely to have on your, on your system, you can pretty much just copy that executable around. Yeah. And that's exactly the use case that we had, um, was to give, be able to give people a little, you know, small binary that they can just run and get, um, a simple output. It was just a a like a log parser. Yeah. And that was great. So that was a great experience. I like that. Ben (24:26): Yeah. I dig that model a lot. I mean, that's part of the reason I, I think we've talked before on, on the podcast about like, I've never taught myself go, cuz I feel like someone should pay me to do it because it's just so useful for that category of problem that I, I just know at some point in the future I'm gonna have to do that. And I'm just like, ah, I'll do that on the o'clock. Yeah. Matt (24:45): Yeah. Yeah. Go was go was the sweet spot for me before. Yeah. And then actually, so recently I hit an issue where I had, um, in fact, people can't see this obviously on the podcast, but behind me, I have a little scrolly device. It's like a physical device I plug in and it has, uh, 64 by 32 LEDs or something like that, maybe a bit more than that. And I can put arbitrary scrolling pictures on there and it just literally, they're animating gifts. I can post to a web server and it ends up on, on there. And so I have, you know, like stats and things like that that appear on it and it's great, It's fine. It's called a tidbit there. You can still buy them. Um, but they're more, more expensive than you think. But anyway, the little program that you can run to like write a little script to push particular images to it that provides, you know, like here's a, a framework for doing scroll texts and, um, wipes and all that kind of stuff. Matt (25:35): It's, um, it's written in go. And so it's just a binary. They say, Hey, yeah, just download this binary. And so you do and you get it and that's great. And I, you know, in my mind, go binaries are just static-al, static static-al God go binaries are just static executable as you run and they just work everywhere. Right. As long as you're on the right architecture and roughly the right operating system, you're great. But this was not true. Um, for this particular I thing, it was linking with like libwebp, which is some, and the, the logical successor to animating gifts is the webp format. And that was dynamically loaded. It just so happened that I had it on my system, so it worked, but I upgraded my operating system and it no longer worked. And I actually actually go and download it and build it from source so that I could get it working again. Matt (26:20): I'm like, this is not what I expected of you go, what happened? And maybe it's just a, a mistake on the part of the people who, who packaged the, uh, the system. But I, I had never experienced this before, so it obviously can happen. And then actually I run ldd on a few, um, binaries that are Go and I realized they are actually dynamically linking with something. So it's, it's more like the same as as Rust in this system. So maybe Rust and Go are equivalent in this space, which is great if there are choices. Ben (26:45): Yeah. Interesting. Yeah. Yeah. Kinda, um, you know, reflecting back on and you know, what you were saying about the, the borrow checker and, and how it works and how it's sort of safeguarding things for you. I really felt, and I don't like this, but it's, this is like, this is on me. Uh, when I was working in Rust, I have distinct memories of like feeling like I was just, you know, driving down the street, bouncing off the guardrails, um, because I didn't really fully understand what was going on. And, uh, I was just trying, basically just being empirical and experimental with the compiler to figure out, like try to figure out like what the, the language was trying to do. And what I was trying to tell the compiler to do. Matt (27:33): This is like, um, the sort of like the C programmers, you know, someone who's new to C programming and putting ampersands and stars in until they get the value out from the pointer or not pointer, or did you need a pointer to a pointer? I don't understand it star star? No. That didn't compile kind of feel for it. You know, like, do I need to make a ref of this? Do I need to box or unbox it? Which of these magical things do I need to do to make it get to the next thing? And whether I really say when I am saying that. Yeah. Is that not true most languages though? Ben (28:00): Well, I mean, it, it can be true in any language, but anytime I'm in that state I, it just feels icky. Right? Yeah. Like, I feel like I'm just, I'm, I'm literally making it up as I go along, which is not the kind of thing that I want to do. And so it was, it was hard for me. Um, and maybe this is because more about, not Rust in particular, but just the sort of programming style. Cause you know, like I said, I, I had done some Scala before, but I kind of got a little bit of that vibe in Scala too, not nearly as bad. Um, so it's maybe just like that programming style in my brain just don't, don't fit. Or maybe I just haven't done enough of it. I don't know what, um, but it, it, it just sort of like, I really don't like a world where I'm like, All right, I wrote a bunch of code, let's see what happens. Right? Like, there's always a little bit of that. Matt (28:52): Of course. Ben (28:52): There's, I'm not gonna make the assumption that I did this right. But I at least want to have some level of confidence that like I'm attempting to do the thing that I'm trying to do. And I'm not just basically just, you know, voodoo chicken coding where I'm like, I don't know, let's Matt (29:08): Programming by coincidence. Like Ben (29:10): Yeah. Right, Matt (29:11): Right. In fairness though, Yeah, I think there is a little of that in anything you do. And, and if you were in the middle of a, a novel code base as well, the, it's exem, you know, it's exacerbated by the fact that you not only didn't know the language, you didn't know that maybe someone had made a call that wasn't necessarily the right call about how something should be done. And then you are suffering the consequences of it. You know, you get to that point where you can have a strong opinion about like, this is just being done wrong and that's why I can't do this thing. That should be obvious. Right. So maybe a bit of that in there. Plus I think there's just that mastery feeling. And if you've been working in languages for a while that you feel you've mastered, you know, if you can bang out 20 lines of code and know that it will compile and run and be probably right. You know, that's, that's, you'd realize you're in that, that uh, uh, that that sort of, um, that uh, level of, uh, uh, uh, expertise and then it's kind of difficult to go back and very frustrating. Right. To be in a situation where you aren't able to just do that. Ben (30:06): Yeah. Yeah. Matt (30:07): So maybe anyway, but Ben (30:09): But yeah, overall, I mean, I love cargo. I love the ecosystem. I love the, so the theory behind the language, um, you know, I, I haven't found a problem yet where I'm like, the right answer to this is Rust, but you know, as you were pointing out about Go, maybe maybe that's the language I should be thinking about when I do. Yeah. Matt (30:29): Next time you want a little command line thing. Ben (30:31): I, I need something command line. Matt (30:34): Just need to like copy somewhere and have it work and run on like a bunch of computers. That's not, you could go far, far wrong. Right? So who do we know who is using Rust? Because famously Mozilla has sort of backed away from it. And the Rust Foundation was born separate from Mozilla to sort of carry on the torch of, um, of the language. Um, the only people I know of that are seriously involved in Rust are some, some acquaintances and pals at, um, uh, at Amazon. Who, um, Amazon picked up quite a lot number, uh, of the, the Rust Core team after the Mozilla, um, announcement that they were not continuing with it. And, um, I mean, to me that makes some level of sense. I mean, uh, Amazon would've hedged their bets for a lot of different use cases. And so one of the many languages they support or could support is Rust. And so maybe they're looking in that particular direction, I don't know. But, um, what, who else is using Rust? But, you know, everyone, everyone knows someone who wants to use it and it's like, Oh, for my next project I might use Rust, but no one I know is actually writing it that much. Ben (31:38): Uh, I'm, I'm googling something real quick, cuz I remember from when I was looking at this more deeply, there was a guy that was way into Rust for embedded software. Matt (31:47): Oh, neat. Ben (31:49): And I'm trying to remember this person's name and Google is failing me here. Um, but that was, that was an area that I thought, um, like he had, uh, gotten, uh, the Rust Compiler working on these like little ARM chips and Oh God, I really wanna like track this guy down. Maybe I'll see it. Maybe if I can find this and I'll just put it in the show notes. Matt (32:18): Put it in the show notes so we find it. Yeah. Ben (32:20): Yeah, yeah. But, um, it was really interesting and this was, this was definitely one, this was like the classic example of like, wow, this is a solution that I really wish I had a problem for. Matt (32:30): . Right. . Ben (32:32): Cause this stuff looks so interesting, but it's just like, I, I don't know how I would use this right now. Matt (32:36): I gotta drawer full of things that look like that just right down here. Various things like, Oh, this will be cool and then never got anywhere with it. Ben (32:43): Yeah, yeah, yeah. So yeah, I will, uh, I'll track that down and put it in the show notes. But there was a guy, one person in particular who was just like very committed to this and like, trying to put it on as many, um, put it on as many platforms as he could. Matt (32:57): Embedded systems and like tiny systems because it's a native thing, It has no run time. It's kind of sweet spot for this kind of thing. Ben (33:04): Right. And the guarantees that it provides, I, you know, I mean, nothing's more terrifying to me than the idea of, I mean, block blockchain smart contracts also have this property and they're equally terrifying. Whereas like, I'm gonna write this code and I'm gonna put it out in the world and there's no take-back-sies. Right. like this is it , this is it, it's gonna be out there and it's gotta be Right. Matt (33:26): Yeah, Yeah, Ben (33:27): Yeah. Yeah. Matt (33:28): That's an interesting one. Yes. Ben (33:31): Um, Rust has, you know, a lot of, I'll be a lot more patient with the slow compiler if I'm in that, in that situation. Matt (33:37): If you're like, Yeah, writing an embedded system for a brake micro controller or in a car or something. But it's different. I mean, they're already, Yeah. Those folks are already in the world of like writing MISRA-C, which is like a subset of things in C. So maybe, yeah, Rust could take over from there. But I guess actually talking of things that are using it that we know of, obviously then you mentioned blockchain type stuff. So the, the Ethereum node that you were writing, uh, modifying was obviously Rust. Is there other aspects of, in the crypto world perhaps, or is is it got more traction in crypto than somewhere else? Ben (34:10): Not that I am aware of. I'm trying to remember the name of that Ethereum node Parity. Parity is the name of the Ethereum node. Um, and is in Matt (34:21): Parity. Ben (34:23): P A R I T Y Matt (34:24): Not parity as in like, like a parrot. Ben (34:26): Right. Parrot-y Matt (34:28): Or parody, like Weird Al Yankovich. Ben (34:30): Right. Oh yeah. Matt (34:31): You Americans and your, your unclear diction. Ben (34:34): Uhhuh, uh, you want some water? Matt (34:36): Uh, ooh, , Ben (34:39): Why'd you leave the D out of water? Um, Yeah. You know, looking at Parity, Parity might not be alive anymore. I'm sort of looking at, all right, this repo Matt (34:52): A project that that was around at least at some point in, in Rust. That's cool. Ben (34:55): Yeah, absolutely. So yeah, I don't, I don't know if there's other places in in the crypto world that's uses it. Matt (35:00): But Rust sort of has the, always the bridesmaid, never the bride kind of feel to it. Everyone likes, wants to, it's the, the language you wanna kind of look at next. But if we just get a one cool problem that will fit it and you know, we haven't quite got there yet except for like a little log parser in my case. And so now, now defunct Ethereum node. Ben (35:21): Now defunct blockchain software. Yes, exactly. Exactly. Matt (35:25): Well before we, um, further show up our, our ignorance really as to the current state of Rust, maybe we should leave it there with our, with with that, that. Ben (35:34): Yeah this is what I'm hoping we get a lot of, uh, you know, Twitter responses and people being like, Oh, it's used here. It's used here. Matt (35:40): Yeah that would be cool. Maybe that would push us over the edge as well of like, uh, of using it ourselves in our day job. Because I think that's where it really starts to matter, isn't it, is where someone will pay you to do that work is when something becomes, uh, worth talking about. At least. Obviously, obviously learning it for your own sake is also very much worthwhile. I mean, I was writing JavaScript long before someone was paying me to write a JavaScript. Ben (36:01): Right. Matt (36:02): But, um, it definitely helps justify, uh, the investment of time to learn something if, if it's your primary or a primary responsibility. Ben (36:10): Yeah. I mean, cuz then you get to do it every day. Right. And it's like Matt (36:13): How you get better at something. Cool. Well, Ben (36:17): All right. You wanna call it there? Matt (36:18): Let's call it there. All right. Until next time, my friend. Ben (36:21): Until next time.