Algorithms + Data Structures = Programs - Episode 240: Thrust, Rust vs C++, Python & More (Part 2)

Episode Date: June 27, 2025

In this episode, Conor and Bryce chat with Jared Hoberock about the NVIDIA Thrust Parallel Algorithms Library, Rust vs C++, Python and more.Link to Episode 240 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: Twitter | BlueSky | MastodonBryce Adelstein Lelbach: TwitterAbout the GuestJared Hoberock joined NVIDIA Research in October 2008. His interests include parallel programming models and physically-based rendering. Jared is the co-creator of Thrust, a high performance parallel algorithms library. While at NVIDIA, Jared has contributed to the DirectX graphics driver, Gelato, a final frame film renderer, and OptiX, a high-performance, programmable ray tracing engine. Jared received a Ph.D in computer science from the University of Illinois at Urbana-Champaign. He is a two-time recipient of the NVIDIA Graduate Research Fellowship.Show NotesDate Generated: 2025-05-21Date Released: 2025-06-27ThrustThrust Docsiota Algorithmthrust::counting_iteratorthrust::sequenceMLIRNumPyNumbaIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

This is such a C++ programmer thing to worry about. Because I used to worry about what to name things. Because in C++, C++ is a very paranoid language. Because you have to think about all the things that can go wrong on any given line of code. Like you could call the wrong function, or the type the thing gets instantiated with is we'll be missing something or we'll have the wrong thing in it. And so you have to take this very defensive stance when writing any C++ code. Now that I've been using Rust for a while now, I don't worry about these things at all.

I don't worry about what to call things. I don't worry about how the code looks because I can be confident that it works. I don't have these problems just don't exist in Rust, I guess is what I'm saying. Welcome to ADSB the podcast episode 240 recorded on May 21st, 2025. My name is Connor and today with my co-host, Bryce, we interview Jared Hobrock. This is part two of a four part interview. In this episode, we continue our conversation about thrust, rust versus C++, Python, NumPy, Numba and more.

Pi, Numba, and more. I believe Bryce and I have a ton more questions to ask you on the roots of Thrust. I mean, I've been holding on to this question for a long time. The last time I was in New York, which was in April, we're recording this tail end of May, we got into a discussion of the different names for the OG name is iota from the I guess technically it was the C++ 11 standard but it comes from APL. Iota is a integer sequence where you increment by 1, 1, 2, 3, 4, 5, 6. In thrust there are two different names for this. There is the counting iterator and there is also the thrust sequence. And this has been up for much debate between Bryce and I of what is the correct name. But our first question is, do you recall,

Jared, where the names for both thrust sequence as an algorithm and thrust counting iterator as a fancy iterator, do you recall where those came from? Sequence in particular, because it stands out. I think we were aware of iota and just like we couldn't name it, we couldn't give it that name. That is ridiculous. We were going to, you know, it's going to be used in every example. We can't use this stupid name that doesn't mean anything. So I think that's where sequence came from. And maybe we sort of justified it by saying, well, the interface isn't exactly the same, so we have to change the name. We can't

use iota. And counting iterator, I think just came straight from boost. I think there was a boost counting iterator that we just took. If you want to talk about names, I can tell you the story of how Thrust got its name. Yeah, yes. I would love that story. Yes. So, uh, I think when I was working on it in grad school, maybe its name was STD Kuda, like, Stood Kuda, just as like a

I don't know, a placeholder name. When I got to Nvidia, you know, maybe someone made the comment, it's not standard and it's not Kuda, so this is not a good name. So we said, okay, fine. And Nathan had just gotten back from a tour of Asia. So he had spent a few weeks touring Asia and touring like post-Soviet communist countries. And he had this picture of a Soviet worker from a mural or something like that. And I don't know, for some reason it appealed to him. And he

decided we got to call this library Comrade, with a K, K-O-M-R-A-D-E. And we're going to use this picture I took as the avatar when we release it. I didn't really have a strong opinion about it. And I believe the, so for some reason he wanted to give the library a communist theme and he's not like a left-winger or anything like that. He just thought it was funny. And I remember the, so we released it on Google code under the name Comrad and the, the tagline was own the means of computation.

And we're really proud of ourselves. We just released this library that we were really proud of. We gave it a hilarious name or so we thought. And then like the next day, we, after announcing that we've released this library to some mailing list at work, we get a response from someone who was very important and influential at the time at Nvidia saying that communism isn't cute, it isn't funny, you can't name it this. And so we were sort of shitting our pants because this guy is very important. We had to save face somehow and think about a different name. It was my

task to come up with a new name after Nathan had failed and gotten us in trouble. What I did was I looked through every English word between four and six letters ending in ST. Since we were stealing everything else from Boost, we thought we would steal the name as well. So I saw Thrust and I said, how about Thrust? And originally I think people were like, Originally, I think people were like, you know, we were going from this, you know, left-wing tinge name to some sort of sexual innuendo for a name, but we stuck with it and somehow the name was stuck and now it's, you know, it's just firmly, firmly means this library's name and nothing else, but that's where the name came from. Just another thing we stole from Boost. I was going to say is I always thought that thrust and boost, like they share the same

one syllable ST ending and that was intentional and it turns out that is the case. I had no idea. I had no idea that that was intentional. I knew about the guy wearing the thrust t-shirt, which we haven't mentioned until now. At one point, Bryce left the Microsoft Teams meeting to go and disappear and he came back with a Thrust t-shirt. I shouldn't say this for a variety of reasons, but I had these t-shirts made like right when I first started Nvidia And I believe that the only other person who has a thrust t-shirt is Jared because I think I gave you one

at like a committee meeting in 2018 or something, but I I I have like five of them made and I think I have like five of them made and I think like one of them got like faded in the wash and so I tossed it and I think I gave one to Jared and I guess I must have misplaced one because this is the only one that I have left. Yeah, they're collector's items now. Yeah. It is very sad because I can my my my what is it autistic tendencies or OCD can Tell me that it is the same logo that is misaligned the left or I guess Bryce's right side of the logo Is slightly thinner than the left side of the logo in?

one of the other painful things So the painful things I did with Thrust was one deal with the version control, two revitalize the docs twice, and then three I had to reconstruct this logo and I don't remember if I eventually, I think I may have gotten like some form of source image from Jared, but I remember there was something where like the fonts or something were missing and I ended up having to like, like I spent like a week on getting the the remade logo a little bit more correct. But then you know what I realized the other day was why didn't I fix it so that the thrust part fits all the way in the box?

Like I got this S and this T out here, like even on the updated one, it's not all the way in there. So I'm so bummed at myself because I don't think I can push through another logo change. The real question is, I mean, thrust has within the name of it a programming language, aka Rust. I mean, which is our fantastic transition point to what is the future of parallel programming, parallel algorithm libraries. I mean, if you could restart today knowing everything, you know now I mean back when you were in the The genesis of what became thrust you didn't know about reductions

You grew into it and it's like looking back on it It it seems obvious that you would know that stuff, but you didn't at the time and and that is so true of like so many Things that they teach in not just computer science, but mathematics It's like like they teach you the artifact but they don't teach you the path to it and the path is very nonlinear. How would you if you were starting today like redesign a thrust library because you mentioned a couple times that you know it's kind of messy the internals. messy, the internals, and you don't need to divulge anything about your current work. But if you were doing thrust 2.0, maybe with a better name, with a better implementation, what would you do? Would it be in Rust? Would it be in C++?

Tell all. I know what I would do. There's not a language, there's no current language that I think is sufficient, unfortunately. But there's three things that a language would need to do something like Thrust or just GPU parallelism really well. One is asynchronous. Thrust just fails at asynchrony for various reasons, but I'd start with a model for asynchrony. Hydrogeneity is important, by which I mean you really have to care about the fact that you're targeting more than one machine,

and they have different architectures, and the differences in the architectures matter. Even CUDA doesn't really have a good way to deal with this, unfortunately. And I base it all around tensors, not one-dimensional sequences. Tensors and multi dimensionality is sort of really important for parallelism. And it's important for sort of vital to everything that people do with GPUs, maybe aside from video games, I don't know how much tensors are important for video games, but everything else you do with a GPU involves tensors in some way.

Even the implementation of Thrust today implicitly revolves around tensors, because you have these... I'm pretty sure the video games are just like, you know, one out of every 10 frame is real and the other nine are AI. So I think it's all just tensors these days. Yeah, I agree. But I think a good language for doing something with, for doing GPU parallelism really well would have to tackle at least those three things. And, you know, as I was saying, whenever you write a kuda kernel, you're implicitly doing tensor stuff, because every GPU is sort of shaped like a tensor in the architecture. So if you're doing something like a thrust reduce, whether you know

it or not, when you take that input sequence, you have to sort of fold it into a shape that matches the shape of the hardware and inevitably that's some sort of multi-dimensional shape. So having a language where that was more explicit and can be taken advantage of would be really valuable for implementing libraries like Thrust. So those are some things I would do differently. I mean, there's a whole lot of problems with Thrust that are there for C++ reasons. And, you know, people have various different opinions on how to solve C++ problems, but really a better language would be better to work with. Unfortunately Rust is not that language.

Rust, I write in Rust every day. I really like it. It's good for single threaded code, but I don't think it handles parallelism that well. And I don't think it knows what to do with GPU parallelism at all. It's sort of at odds with GPU parallelism, unfortunately. Interesting. Like the way that borrow checking works sort of assumes that you've got a single thread and it's going to call functions in sequential order and the borrow checker works really well when you're doing that but on a GPU we have a group

of threads and they want to communicate and they maybe they want to mutate different parts of a shared array and no one knows how to make that work with the with barrow checking but what what if you don't program the threads and the parallelism directly what if the way that you express the parallelism is by like performing operations on arrays that get paralyzed. And then you're... Yeah, so... Yeah. So what if you just threw out mutation?

That's something you could do. Yeah, that's the other way to do it. Let's just not mutate the data or, you know, let's let the compiler decide how to parallelize collective operations on tensors or something like that. That's great. You don't need Rust for that. Rust assumes you're going to mutate very carefully and you're going to think very carefully about sharing, but if there's no sharing and there's no mutation, you don't need a borrow checker at all. Ah, that's an interesting point. That's a very interesting point. I had not considered that. That if you're in a purely value based world, like, why use Rust? Why not just there's dozens of options for that?

Yeah, we've got armies of people working on different MLIR dialects, right? Yes. So, we need to leverage those armies in a way that makes sense in a high-level language. At least, that's my opinion. And I would definitely start with just value semantics, just not necessarily functional, but like SSA sort of semantics. That's what MLIR gives you anyway. I think you could get really far with that,

especially for the kinds of algorithms that are in Thrust. If you sort of assume that you have at your disposal operations that might look similar to what you would see in Cub, but they're sort of, instead of mutating arrays in a shared memory, you're instead just performing collective operations on values. You could easily build a thrust library, or a thrust-like algorithms like that.

You just need a language to express it in. I guess another thing we need, one really bad thing about libraries like thrust or cub or cut lists is that they are locked in CUDA C++ templates, right? So to get access to them and reuse those implementations, you need to generate C++ templates, right? So to get access to them and reuse those implementations, you need to generate C++ code and then you need to find a C++ compiler to instantiate that code. Think about what we do from Python libraries that want to use the GPU.

Inevitably, they generate some C++ code at runtime, compile it, and execute it. But what if, you know, they didn't have to do that, what if those implementations were in a more portable form than C++ templates? What if you didn't need a C++ compiler to use to get access to fast algorithms like, like Rincub, for example, that's something we need. So I guess the question is, what is preventing us from having the world that you are describing right now today? Obviously, Python, I think the three of us in this meeting can agree. And the folks that have the prerequisite knowledge to also agree with us can agree that Python is the non-ideal language for targeting GPUs.

It's dynamic. Oh, no, I think I think I think I'll take a contrary perspective here. I think Python's great. I made this. I was for the first time ever. I've been on another podcast, the Talk Python Python to me podcast and I made this point that I will claim that Python is actually a performance oriented language and the reason for this is that Python has very loosey goosey semantics it's a very flexible language and it does not have a ton of rigorous protocol when interfacing with other languages.

And it's very easy to build a DSL in Python. It's very easy to build something that takes Python syntax and kind of Python semantics and lower it down to native code. And it's also very easy for Python to call into native code. I remember a few years ago, I went to this conference at Facebook, this was back when I was in California. And there was this fellow who was a very senior JVM engineer.

And he was talking about, he gave a 30 minute talk solely on all the work that they had to do to make JVM native calls fast. And the reason that they had to do all this work, it was like the calling convention for JVM, the call native code, was like at minimum 100 instructions. Because the JVM had these very very specific you know protocols for like you know relating to like object semantics and

you had to you had to follow all these rules whereas like in Python it can just be like oh you just you just call this function you just call this function you know and like yeah maybe though like if you want to have like two-way interop like maybe the function needs to like use some of the Python APIs but like it's super simple in Python to just call a C function. That makes it easy for Python to call into fast things. Also on top of that, it's easy to extend to Python to build DSLs for Python. Because of that, I think of Python as being more a performance-oriented language.

I think Python's more similar to C++ and Rust in that it is used, I would say, maybe not predominantly, but certainly it's getting closer and closer to that point where Python is predominantly used for performance oriented tasks like machine learning and data science. I've heard you say this three times now that Python is performance oriented and I literally thought the first time you said it I was going to be like oh he said it one time I won't be able to call him out on it. You said that three times. Are you serious?

I am serious. Hey we have free threading now. It's all going to be fast. It's going to be very fast. Jared do you can you back me up? What are we talking about here a non compiled? dynamic interpreted language that treats integers as

Objects what are we talking about here Bryce? What are we talking about here? But the point is that that in the places where you care about performance you can use it yet Like if you if you write wait wait, wait, wait. You just said it was performance oriented and now you're saying in the places where you care you can use it. It treats integers as opt in the base language. Like if you want performance, it's better to use numpy instead of the baked in lists to Python. Like as soon as you're over a thousand... Not if you're using JIT. What do you mean JIT? One second, one second. I'm pulling up some... The reason Bryce can say this is because Python has had...Python is backed by Google and has

been for the past 20 years and Google is the ones that have been paying to make all of these libraries fast through Python, right? But as soon as you need to do something that one of these libraries doesn't have a C API for, you're screwed, right? Exactly. That is true. Exactly. And that's the thing is that in general, if you...

I've said this before on the podcast that if you want performant code in Python, you shouldn't use Python, you should use NumPy because NumPy is implemented in C and as soon as you're doing anything serious, and by serious I mean greater than 1000 elements in a list, it's faster just in any library that's dispatching to C code, which means how is Python performance oriented?

That means that Python is a language that facilitates fast libraries that are not actually in Python. Yes, that is true, but also Python has a number of different JIT options that are very good. So this is like we use Numba as the basis of our like CUDA Python device code authoring. And so you can write kernels in CUDA Python that will compile down to the same machine code that you would get if you wrote them in CUDA C++. And you can use abstractions like lists, like you can use all the Pythonic things in this code

because it's just this like little DSL that is, Numba's gonna kind of violate some of the object semantics. You're not gonna have an interpreter. You're not gonna have object lifetimes. It's gonna map everything down to value semantic things in the C++ machine model. And you'll get the same perf. And now you can even use our device side libraries

in something like Numbakuda. So like, yeah, like Python, like on its face is like, you know, can be pretty slow, but Python gives you all the tools to make it very, very fast. And- Right, so you're talking about publicly about how it works? Or is that not publicly acknowledged?

It's all open source. It's all open source, because Numba is just an open source JIT compiler. So what Numba does is it just takes either Python bytecode or AST, and then it lowers it down to this IR called Numba IR. And then all that Numba IR is used for is to do type inference to figure out hey you're calling this function here you know what are all the types and then once you have all the types resolved you'd lower it down to either LLVMIR

or MLIR and then it compiles just like it would native code and there's like two or three like major JIT solutions like this for Python. And, you know, the best analogy I can give is like JavaScript. So JavaScript is another language which JITs very, very well. You can write code in JavaScript which after it's been JIT, has performance that is close to the performance of native code. You can't do that with a language like Java, which has a very rigorous object model that makes it very challenging to really

be able to do that. But with languages like JavaScript and Python, their object models are a really good fit. And in particular, if you're writing this like NumPy type code, like when it lowers things down, if it sees lists, lists get lowered down to just like an aggregate type, the equivalent of like a std tuple. You know, integers, floats, etc., when they get compiled, they're just going to be lowered down to the equivalent native processor types. And something like a NumPy array is just going to be lowered down to like a pointer plus

a metadata, the equivalent of like an MD span. And something like a NumPy array is just going to be lowered down to like a pointer plus some metadata. You know, the equivalent of like an MD span. But yeah, like NumPy, it just goes, takes your DSL, takes your Python AST or your Python bytecode, turns it into this intermediate IR and it does the typing and then it becomes LVM IR or MLIR and number is like the heaviest weight of the Python DSL compilers there's also a lot of other DSL compilers there's some that do transpilation so they take Python code they turn it into C++ this is actually what Kupai does Kupai takes your Python code and it turns it into like it'll it'll spit out like thrust or cub code and then it'll get compile that code and then there's other compilers that will use an approach called tracing where instead of

like parsing the Python AST they essentially just inject mock objects into your code and then as your code executes instead of doing whatever your code was supposed to do it captures a trace and it builds up like from your actual code execution it builds up a representation of your program and then they transform that and they lower it down in whatever way this is how like things like Triton used to work although I think they now have a more proper compiler framework but there's a ton of these different tracing frameworks. One problem that we have at NVIDIA is that it's so easy to make DSLs in Python that we have like 20 DSLs in Python.

Every two to three weeks, somebody's creating a new Python DSL. Yeah, but what if you need to write a kernel? Like none of these approaches have anything to offer. Yeah, yeah, they do. You can totally write kernels in a... You can't write kernels really in Python. Yeah, yeah, you have access to all the tools that you have in access to. No one serious is writing kernels in Python.

I'm telling you... Then why isn't Th kernels in Python. I'm telling you. Then why isn't Thrust written in Python? We could get there. So this is like a Speed of Light softmax kernel written in native Python. You can allocate showed memory. You can allocate register memory. You can use cub. You can use showed memory, you can allocate register memory, you can use cub, you can use like other libraries too. Like people are starting to use this. People are starting to write like serious kernels.

Why is it good for a kernel to look like that? Because one, you get to do, you get to use NumPy style arrays. Like the Python has like de facto very nice... Rank polymorphism. Would you care to elaborate on that, sir? You're saying NumPy like arrays, but the word is rank polymorphism. Like that's the thing that Jerob was saying is if he was gonna do it over again, he would implement it in terms of tensors.

When you're implementing something in terms of tensors, it means if you have a two dimensional or three dimensional array, you don't have to spell map, map, map in order to do an element wise operation over your arbitrarily ranked array. NumPy semantics is array language semantics. It means that if you want to do some element-wise operation, it's just a single character plus a scalar or something like that. So that is one of the benefits of NumPy, which is a poorly implemented array language, is rank polymorphism or broadcasting.

And this isn't even to mention the very cool thing that we announced at GTC this year, which is Kutile, which is a new higher level programming model for CUDA that's entirely array based, where you don't explicitly program threads. And like this is what the speed of light softmax looks like in Kutile. And on like on the left, you're seeing the NumPy code and on the right, you're seeing the Kutile code and they're very close and it's using taking advantage of the rank polymorphous and the kind of talking about but to get to the question why would you want to write a kernel from Python well it is a very

simple answer to that question which is if you can write the kernel in Python then you don't have to deal with having to support both C++ and Python in your application. Then you don't have to deal with having a C++ build system and it solves a bunch of packaging problems for you because instead of having to build a Python extension or a shared library that Python loads, you can just ship Python source code, which is what most Python projects do. So it saves a lot of headache that people have. Sure. I'm not here to defend C++.

I'm just defending the idea of an ideal. What is the platonic ideal of GP programming language? I wouldn't begin with Python, I guess is what I'm saying. I understand people have, people like Python and they have requirements to use Python. I just like to imagine what the perfect GPU language would look like. I would agree, and the reason I would agree is that

there are, well, I think that the NumPy ecosystem and its prevalence in Python is a huge improvement over C++. Having these like rank polymorphic arrays that are, it's a vocabulary type. It's not like part of the language, but it's in such wide usage that like every library that does anything with tensors supports the NumPy semantics. And that's great. However, NumPy is a little bit old, 20, 30 years old, and it does have like a number of words to it. One of the things...

Whoa, whoa, whoa, whoa. Let's back up. Python is 30 years old, not NumPy. You're getting your languages and your libraries confused. Python was created in 1993 or 94. NumPy was not. When was Num Numpy created? Numpy, I think it became popular around 2010. And I agree completely with Jared. Like if I'm designing a GPU language from scratch, I'm not starting anywhere close to Python. The fact that Python has become the lingua franca of in 2005.

But yeah, Travis Ollifont was someone I I hope to it was 20 years ago I said 20 years that is I 50 no no no you said 30 30 was the genesis of Python dinner with or we were at the same the same dinner table at the pilot ease charity auction with with Travis all of us last week very nice fellow fantastic fantastic my point being is that I agree with Jared. Python was created 30 years ago, numpy halfway through the lifetime of Python, and a dynamically quasi-strongly typed language with all this great FFI.

That's not, the reason that Python today is the language that folks use to target GPUs is not because it's a good language for targeting GPUs. It is okay, but it's not where I would start. And that's, I think that's what Jared was trying to say is that it, I think Python gets in the way of what we would like from a language in terms of trying to eke out max efficiency

and performance from GPUs. And it's just an artifact of history that it's become the lingua franca of data science and machine learning and deep learning, et cetera. I don't know. Maybe Jared, you could add if you disagree with what I just said. When I, so I picked up Python recently

because I was considering using it for a project and whenever I use Python, I feel like I've lost, like I've gone blind, like I've lost a sense because there are no types. And even when there are types, they're not really there, right? Like they don't do anything for you. So I feel like, I mean, even if you use the type descriptions, they don't, they're not

helpful. So I don't know, I just feel like I have brain damage or something when I'm writing or reading or writing Python code. I like Rust because once a cargo check is happy with the program, I'm confident it's going to work. I can do enormous refactors to a code base and be confident that they were correct. And nothing like that is possible with Python. I know it's important. I know it's probably the most important programming language,

but there are some things that Python is inadequate for. There's a particular wort of NumPy that I want to highlight. If I highlight that wort, it rapidly leads into the really cool algorithm that I want to show you. And I suspect that Connor may have a couple, a couple of topics he wants to discuss with Jared before we get there. So no, no, I mean, we can go down this rabbit hole. I would just like to go on record saying that Python is the most popular language in the

world at the time that LLMs have come of age Which makes you think that the rich are just gonna get richer. I am willing to bet my life on the fact that Python will not be the actual language that LLMs target because it's it's not a language like Rust that is statically typed has more linting etc is Better to target than a dynamically typed language. And so anyways, I'm just going on record saying Python is popular now and will die before I die. And that's also keeping in mind

that I will upload my brain to the cloud and live forever, at which point we will now transition to Bryce's segue into his algorithm that he wants to talk about. So before we get there, a quick thing on LLMs. So I've been thinking a little bit recently about this question about what language will the LLMs write code in. And one thing that's come up is this question of coding conventions. In particular, what coding conventions should we as programmers follow to make it easier

to use LLMs in our code bases? And one particular piece of this that's come to mind to me has been around naming conventions. I think typically, at least me, I tend to prefer, earlier in my career I would use very long and verbose names. But now I primarily write code for slides and I've got a limited number of characters that I can use in the slide. And so I've found myself using shorter and shorter names as my career goes on. But it seems to me like you probably want to use quite descriptive names in your code base if you're planning on using LLMs to help you write your code. Maybe even you want to use

names that are you know more verbose than would be comfortable for a human. Because that's like, if you use very short names that could be ambiguous or misinterpreted, it might be more confusing to the OOM. Whereas if you use very clear and concise names that are unambiguous, that's going to probably give you better results with using OOMs. This is such a C++ programmer thing to worry about. probably give you better results with using LLMs. This is such a C++ programmer thing to worry about. Because I used to worry about what to name things.

Because in C++, C++ is a very paranoid language. Because you have to think about all the things that can go wrong on any given line of code. Like you could call the wrong function or the type the thing gets instantiated with will be missing something or will have the wrong thing in it. So you have to take this very defensive stance when writing any C++ code. Now that I've been using Rust for a while now, I don't worry about these things at all. I don't worry about what to call things. I don't worry about how the code looks because

I can be confident that it works. These problems just don't exist in Rust, I guess is what I'm saying. These things I used to get paranoid about in my T++ template codes, there's usually only one right way to write the Rust function according to some LLM. And if it compiles, then it's correct. And you move on. These ambiguities just simply don't exist. It's a very relaxing way to write code.

And I can echo that. When you write Rust code, I am more of an expert in C++ than I am in Rust by two orders of magnitude. Like I've written a couple thousand lines of Rust. That doesn't make me an expert, but like I know the inner details of the special member functions and all this stuff.

And I have so much like cognitive weight in my brain when I program C++ and I'm like, oh, I gotta, am I using an initializer list? Well, I've got a special set of rules for that. And it's just like, I have all these voices talking in my head when I program in C++. When I go to Rust, I'm kind of just like, I don't really know what's happening here,

but the compiler like holds your hand and is like, don't worry, I'll be the expert. You just program the way you want to program. And all I'm saying is, the future of generated code targets a language like that. Not like C++ where you have a matrix of special member functions where depending on the subset that you implemented, you will get a certain other set generated. It's anyway, so I mean, and that's C++. You're trying to say that Python, dynamically typed,

et cetera, et cetera language is gonna be the, no, it's in the short term, that's what's gonna happen. In the long term, the more compiler up front, static analysis guarantees that you can get. That's what's gonna be the future, in my opinion. But Bryce has a story to tell us about some algorithm and potentially refuting everything we're saying here. So we'll let Bryce speak now and convince us.

Be sure to check these show notes either in your podcast app or at adspthepodcast.com for links to anything we mentioned in today's episode as well as a link to a get up discussion where you can leave thoughts, comments, and questions. Thanks for listening, we hope you enjoyed, and have a great day.