CppCast - Rust <=> C++

Episode Date: May 18, 2024

Mara Bos joins Phil and Timur. Mara talks to us about her work on the Rust evolution team and how she uses embedded Rust for drone flight controllers. We chat about some of the differences and similarities between C++ and Rust, and what the two languages can, and should, learn from each other. News GCC 14 released Changes Reddit discussion "An informal comparison of the three major implementations of std::string" (updated) - Raymond Chen BugInsight – New memory leak and deadlock finder for C and C++ on Windows Reddit discussion Links "Rust Atomics and Locks" - Mara's book "driveway moment" (Wiktionary)

Episode 382 of CppCast with guest Mara Boss, recorded 14th of May 2024. In this episode, we talk about the new GCC release, different implementations of StdString, and a new tool for finding memory leaks and deadlocks in C and C++. Then we are joined by Mara Boss. Mara talks to us about her work on low-level concurrency and Rust. Welcome to episode 382 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today? I'm all right, Timo. How are you doing? I'm doing great. Weather is good. I'm at home, not currently traveling anywhere, so I can focus on work.

Everything else is going well. Yeah, good stuff. How are you, Phil? Yeah, not too bad. I'm a little bit stressed because I've got another big conference coming up next week. The first edition of my Swift conference. Oh, that's exciting. What is what is that about oh it's about swift what's it called it's called swift craft we've mentioned on the show briefly before but i mean normally we're not talking about languages outside of c++ that may change a little bit today but um yeah it's uh it's an interesting language and maybe we should get somebody on to talk about Swift

from the perspective of C++ sometime as well. Well, that sounds like a great idea. We should totally consider that. Okay, so at the top of every episode, we'd like to read a piece of feedback. This time we got an email from Mike Adams. Mike writes, I appreciate what a struggle it must be

to regularly make C++ seem relatable and interesting in podcast format. But I found the last episode with Neil Sloman to be exceptional. I had my first CBPcast driveway moment. Keep up the good work. Well, thank you very much, Mike, for your feedback. That's very encouraging. But what's a driveway moment? Well, when I read this, I sort of straight away intuitively knew what a driveway moment must be. But helpfully, Mike actually included a link to Wiktionary in the email. So we'll put that link in the show notes. But it's just, if you're out driving, listening to a podcast, and you're so into it, you arrive

at your destination, the podcast hasn't finished, you just sit there and finish the episode before you actually get out of the car. All right. Yeah, yeah. Okay. Yeah, I've done that a few times. Yeah get it that's fun all right so we'd like to hear your thoughts about the show you can always reach out to us on x master on linkedin or email us at feedback at cppcast.com joining us today is mara boss mara boss has been a member of the rust project since

2020 where she co-leads the rust library team and is a member of the Rust project since 2020, where she co-leads the Rust library team and is a member of the Rust Leadership Council. She wrote Rust Atomics and Logs and founded Fusion Engineering, a company making drone flight controllers in Rust. Mara, welcome to the show. Hi, it's very nice to be on the show. Now, there's a lot of Rust in that bio,

and we're going to come on to why we're talking about Rust in a bit. But you also mentioned drone flight controllers writing those in in rust so is that on the drone itself or is it like a remote device or app no we make a small device about the size of a phone that you put on the drone you connect all the sensors and motors to it and it makes the drone fly even in even when the propeller breaks even in heavy wind uh originally in c++ but later later in Rust. Right, so you're writing code in Rust. It really does fly.

Yep. That's really cool. So we'll get more into that in a few minutes. But first, we have a couple of news articles to talk about. So feel free to comment on any of these, okay? The first news for this episode, I would say it's major news, is that there's a new version of GCC,

GCC 14, which has been released just, I think, last week. there's a new version of gcc uh gcc 14 which has been released just uh i think last week it's a pretty major release uh you put the release notes uh into the uh show notes uh there's lots of changes and lots of new c++ 23 and c++ 26 features that they've implemented as well as lots of stuff for other languages lots of backend features as well they have now interestingly pretty much fully implemented the c++ 23 language except for two very very small features which are arguably kind of tweaks that could be uh kind of backwards compatibility breaking which is maybe why they didn't do it yeah they're more like fixes aren't they yeah more so one is the changing

scope of the lambda training return type and the other one is nico's affixed to the range-based for loop like extending the lifetime of temporaries which might actually change the meaning of code so i i don't know so so but like apart from those two minor tweaks or fixes they have fully implemented the language now even though it's you know has the iso standard actually been released even uh already officially i thought it was meant to have done but i've not seen where that it has been okay let me just quickly look up give me a second so so the css20t has not even been officially publicly released yet like the official iso standard is still 2020 it says expected to be replaced by DOS 23 within the coming months. So the new standard hasn't even been officially released by ISO yet.

NGC has already fully implemented it. That's pretty impressive. There's a few library things that they haven't implemented yet, such as mdspan, flat set, and flat map, which are pretty big. So it makes sense that it takes a bit more time. But I think that's rather impressive. Yeah, I think import std as well. span flat set and flat map which are really big so makes sense that it takes a bit more time but i think that's that's rather impressive yeah i think import std as well it's not in yet i saw in the reddit thread that'll be quite nice because that's the one that we mentioned is likely to

drive adoption of modules more at this point all right so uh new gc version very very cool the next uh news item i have for today is a blog post that caught my attention by Raymond Chen, who publishes a lot of blog posts on the Microsoft website, which are usually pretty great. This one is, I think, actually an update of an earlier one.

So it's a new version of an old thing. A new version of an old thing, where he compares the three major implementations of Stoodstring, GCC, Clang, and Microsoft. It's really interesting to see the different trade-offs that the different standard library implementations shows. They're all kind of the same. They store pointer size and capacity

and implement the small string optimization, but all three of them do it differently. And there's all of these little trade-offs, which I think is really interesting to think about. How these decisions affect performance and affect different use cases. For example, when you determine whether the small string optimization is used,

whether the string is inside the object itself or not. On MCC and Clang, that's a single-member comparison. But on GCC, you have to compare a member against the address of another member. So that's going to be an extra instruction to calculate the address. That's going to be slower. On the other hand, the pointer itself is always valid. So it points on GCC either to the internal buffer or to the heap memory where the longest string is. So the data member that gets you the pointer is much faster because it just literally just returns the pointer value, right? So there's a trade-off there.

There's another trade-off, like the size of the object is larger on GCC and MSVC is 32 bytes, whereas on Clang it's 24 bytes. But on the other hand, the small string capacity is bigger on Clang. It's 22 bytes versus 15 bytes on GCC and MSVC. There's all of these little trade-offs, which have different performance characteristics and size characteristics, which I think is really interesting.

Yeah, and also highlights that these are choices, trade-offs that have been locked in place at some point in time, and now we're sort of stuck with them because of ABI compatibility, and mostly you can't really change them. Didn't GCC break their string implementation?

Did they do that with Fawzi with SOS14 that mostly you can't really change them. Didn't GCC break their string implementation? Yes. Did they do that for C++ 14 or something, where they switched? Around that time. Away from the copy-on-write implementation. Yeah. Yeah. Okay.

So that is interesting. I have one more news item for today, which is something I found on Reddit. There's a new memory leak and deadlock finder for C and C++ called BugInsight. What it tries to do is kind of similar to ThreadSan, but ThreadSan is currently Linux only, whereas BugInsight is actually Windows only. It also covers some of what ASAN is doing. So regarding the thread stuff, like the feature set is currently limited.

It detects critical sections, the mutex, the recursive mutex, deadlocks and things like that. And then, yeah, there's some overlap with ASAN. Actually, one person on Reddit even said that it found two bugs that ASAN didn't find, which is interesting. So yeah, a new tool for Windows.

I think that's always good news. Let's hope that it is going to continue to be developed and to prove itself useful. Yeah, and it's interesting that you can use a tool like ThreadSan or BugInsight to detect threading and issues with atomics statically. If only we could do that in the language itself, which might be a good transition into the

main interview right so we did a series uh a few months ago i think mostly last year about the you know successor languages or languages that have been described as successor languages to c++ we did an episode on cpp2 we had carbon we had val which is now called Hylo, I believe. That's right. We did not actually have an episode on the language that kind of is most popular out of all the languages that somebody somewhere has described as potential successors to C++, which is Rust. So we're going to do this completely outrageous thing. We have a C++ podcast and we invited a guest who is mainly known for their Rust work.

So Mara, welcome again to the show. Thank you so much for being here with us today. Yeah, thanks for inviting me. So I came across your name because you published a book last year, which I actually bought. I kind of read it on your website and I liked it so much that I ordered a hard copy. So it's now on the bookshelf behind me it was a great book i learned a lot from it we want to tell you our listeners what the book is about what's in it uh yeah sure so the title of the book is rust atomics and locks but i'm not

sure if the title really captures all the different things that the book brings so obviously the main topic is atomics in rust it explains uh how the atomic types work in rust that if all the different kind of memory ordering we have the same memory model in uh rust and c++ so it's basically relax acquire etc right and it goes through a bunch of different primitives like spin locks and channels like like how to build those from scratch with the atomic types. And near the end, it also goes into like how this actually works at the hardware level. It shows the assembly instruction on x86, ARM64, and a bunch of operating primitives like food taxes.

So basically all of the relevant information in a relatively short book, it's only like 250 pages. But the reason I say that the title doesn't quite capture everything that's in the book is because almost all of the book also applies outside of rust like i said the rust has the same memory model as c++ and the majority of the book would equally apply to c++ or c or some other languages. And in a way, I try to also write the book such that it is readable to people who are not too familiar with Rust. Like maybe I've seen it once or twice,

know a few of its properties, but are most experienced in other languages. One of the reviewers of the book is a C programmer. It's Paul McKinney. He also wrote the foreword. He's a famous contributor to the Lingus kernel. So basically all of chapter one is just explaining the parts of Rust that are unique to Rust, that are relevant for concurrency,

which is a lot of parts of Rust. So basically the book has two target audiences, like beginner and intermediate Rust programmers want to learn about Atomics, but also intermediate to advanced C++ and C programmers want to learn more about how we do things in Rust land. So the book definitely succeeded because I'm not a Rust person.

I know very little about Rust. I have not really used it professionally in any way. I have like a little bit of knowledge, but not really very much. But I found the book to be very readable. There were a few things where I was like a bit confused about how Rust does something, but I got over it relatively quickly. And I really liked that it's not really a Rust book. It's a book about low-level concurrency that just happens to use rust as its programming language and what really blew me away by the book is that you know i've been on the c++ committee for a while now but like i never felt like i fully understood the c++ memory model even though i really should but i never felt like i really did but i did i think i now do after having read your book so so like i

i read a rust book and that finally made me something click in my brain like, oh, this is how the C++ memory model works. So thank you very much. That was massively helpful. It's the best book I read in a long time. Really happy to hear that. I'm excited that that's also working out. I've heard a lot of feedback from Rust people reading the book, but not a lot yet from C and C++ programmers reading the book. So if you are a C++ programmer and you want to know, you want to finally understand the C++ memory model,

read Mara's book. It's great. All right, so you do now work on Rust, but it's clear from your book and from your blog posts and other stuff that you publish that you're also pretty knowledgeable in C and C++. What was your journey like? Like, what languages did you start with? How did you end up with Rust? Let me think.

I think way back when, I think I was like nine or ten or something, I was doing stuff in BASIC. I stayed up very embarrassingly long time in those languages. And at some point I started doing things in Bit and C and assembly, but I didn't like it very much. Couldn't just quickly throw something together like you would in Featured Basic. But at some point I picked up C++ and I just loved the way you could make abstractions, like package something in some type and then build on top of that as far as you like. So I became a really big fan of C++ and I stayed in C++ for, I don't know, many years. And then in

2017, I think, I founded this company you mentioned earlier, making flight controllers for drones. And by then, I still didn't know about Rust. I was doing everything in C++. And so at our company, we mostly had engineers from other fields in computer science. We had people from control engineering, aerospace engineering, mechanical engineering.

And I was teaching them C++ at the time so they could help out implementing things. And that was hard. They were mostly used to Python or Matlab from their studies. And in C++ they kept falling into all kinds of pitfalls, like forgetting

to initialize a variable or cutting from race condition somewhere so I was spent a lot of time teaching and I often felt slightly embarrassed on behalf of like computer science when I had to explain to them like oh actually if you do this then things will blow up you need to do it this way um and at some point I was just experimenting a bit in Rust. And the cool thing about being the founder of a company is that you can just make decisions. So if I'm like, oh, let's use Rust, I can just do that. So I started using Rust for some small parts. I started with some part of the generation of some code. So just the part that I was personally working on, so I didn't have to bother the rest with Rust.

And I started to get the impression that a lot of the things I was glad to explain in C++ over and over again were things I would probably not have to explain in Rust as an experiment. I started teaching one of the control engineers, Rust, and we rewrote one part, the state estimator, maybe the most important part of the time, in Rust.

And after like two weeks of exposing him to Rust, he was actually very productive in it and didn't want to go back. I was like, oh, that's a great sign. And at that point I decided, okay, let's just do everything in Rust. And we rewrote everything in Rust. And we wrote everything. There were some things that got slightly more complicated,

but most things got a lot simpler. And I noticed that onboarding a new programmer was a lot easier. Even doing some complicated things like embedded systems, like someone who had never done it before, they could pick it up in a few weeks and be productive in it. So that was the main thing why I continued in Rust. And then afterwards, I started contributing to the Rust language and standard library.

Very small things at first. And that kind of very quickly grew out of hand because that's when COVID started and I had nothing else to do because my whole social life disappeared because of all the lockdowns. Yeah. Then I ended up writing and I had nothing else to do because my whole social life disappeared because of all the lockdowns. Yeah. Yeah. Then I ended up writing a book and became team lead of the library team

and a whole bunch of other things. So you said that you went all in on Rust. Does that mean you're exclusively using Rust now? Or do you still use C++ at all for anything? There's not a single line of C++ code left at this point. Interesting. Wow. Do you follow what's going on use C++ at all for anything? There's not a single line of C++ code left at this point. Interesting. Wow. Do you follow what's going on in C++,

like the evolution of the language or stuff like that? Or have you just left it all behind at this point? I left it. I should be following it. There have been a few moments where it was kind of embarrassing that something happened in C++ that we should have done in Rust and just no one was aware, which made you realize, oh, maybe we should have done in Rust and just no one was aware which made you realize like oh maybe we should actually stay in touch a bit more

and like not just sit in our bubble so maybe I should be listening to your podcast more often one example of that was the related to memory ordering so it's a very small example but

in C++ at some point, you all realize that for compare-exchange, there were a few restrictions on memory ordering that were unnecessary, so it was relaxed, and now you can have compare-exchange with a few memory orderings that weren't allowed in the past. But that happened after we kind of just took the memory model to Rust. And we just never checked if there were any updates to it, basically. So in Rust, we had these restrictions, even though our C++ was already removed. And I only realized that when I was writing my book, I would explain,

like, oh, you can't use this memory already because... And I didn't know how to finish the sentence. And I looked it up and it turns out we didn't actually need it. And a few of these things happen. So yeah, those moments make you realize that we should probably make sure we stay in touch with the people outside of our bubble because it's very easy to just focus so much on one language at conferences about those languages with people only work on those languages, et cetera. It's easy to ignore what goes on outside of it. Yeah, I think especially if C++ and Rust share the same memory model,

it would be good if we stay in sync as far as reasonable. Because stuff changes, right? So, for example, one of the things I just never understood, actually, until reading your book, is how memory order consume works and why carries carries dependency this weird attribute that i have read the specification of 10 times and it never made any sense to me why is that there and then i read your book i was like oh okay that's why but then also i later found out that people found out that memory order consume doesn't actually work because that's not

how hardware works so now there are proposals to change it and there's other stuff as well right like tomics i think are changing there's like api changes in c++ and there's a bunch of new concurrency stuff that's been added in c++ 20 and you know it's kind of moving and changing and de-deprecating volatile yeah de-deprecating volatile so yeah i think it would be beneficial if the languages stay in sync as far as you know reasonable it's interesting to hear that you say you learned about um consume memory ordering for my book considering that rust doesn't have consume memory order no but you mentioned it you mentioned it you explained why oh then the the the kind of

dependency goes into like a parameter and oh that's why you know you do explain that actually yeah i think it just proves that the book indeed is more than just atomic symbols. But it's nice to hear that you learned about that part from the book. Yeah, consumed memory ordering is an interesting one. I would really like to have it. It's just really hard to properly specify it. A lot of data searches that are used in the Linux kernel

would use or should use console memory ordering, but in C and C++ it's not really implemented. It's just the same as Acquire in most implementations. And in Rust we just don't have it. So yeah, it would be nice to find a solution to that. I thought that's because the hardware

can't really do it in the way it's specified in C++. The hardware kind of does it by default, but it's hard to guarantee that your code will compile to something that results in that property. The compiler might do a few things where it breaks that, basically. And specifying exactly what it means for something to have a dependency is complicated.

Right. How did you get into the concurrency in the first place? You seem to know a lot about it. How did I get started? Oh, right. The drone flight controllers, again. So the it all came from the basic software architecture

we use on those flight controllers. So the flight controllers run Linux, and all the different parts of the control system are different processes. So there's a lot of inter-process communication. The idea is that if one process crashes, then it can just be restarted, while the others just continue. So you can literally just SSH into the drone whilst flying, just kill the status, make it kill the flight controller, just restart and continue flying, which is pretty cool

which is a lot of reliability but anyway, because of that there's lots of inter-process communication and I wanted to make sure that's very efficient, I didn't want all inter-process communication to go through syscalls like writing to a pipe or something. I wanted

it to go to shared memory. But then you need to figure out how to make it work properly with Atomics. I basically came up with this idea that apparently already had a name. I only found out much later the sequence log.

So basically you have a counter followed by some data. So every time in the shared memory. So every time the writer wants updated, it bumps the counter, updates the data, bumps the counter again. And the reader reads the counter, reads the data,

reads the counter again. And if both of those numbers were the same and even, then there was no race and the data is okay. And otherwise just needs to try. But I needed to prove to myself that it actually was correct and that the ordering was right. And then I kind of started hyper-focusing for a while on this stuff, looking at like this assembly of things, reading lots of resources, being annoyed that there are so many resources that only gave me one part of the picture. So then the idea popped up to kind of try to make a place

where all these different parts of the picture were put into a single resource and maybe explain it from a Rust perspective instead of a C++ one, because there was basically no resources about atomics in Rust. All of it was about C++ where you sort of had to translate it to Rust in your head. Right.

So I have a question here. So how good is actually... So I guess a lot of what you do, as you said, is kind of embedded, low-level. How good is Rust for that stuff these days? For example, if I may say one thing, I also co-founded the company at some point and I also had this choice of like,

okay, I can choose what tech stack we use, right? And I looked into Rust. And for that industry, like music production software, none of the kind of frameworks and libraries and middleware stuff that you need was there. And we wouldn't have had the resources to like write all of that from scratch in Rust right so so we ended up not using Rust even though it might have been the better language because the tools were just not there

to do what you want to do is that different and embedded and for this kind of drone stuff that you're doing is is it mature now can you just go ahead and use it or did you have to like invent a lot a lot of stuff um we had to invent a lot of stuff but we also did in c++ so in in the kind of embedded stuff that i used to work on also before the before the drones there were basically no libraries you were using just use c or c++ um maybe maybe some headers for the the exact microcont control platform you're using or maybe some Linux specific things to do syscalls but that's about it. So when switching to Rust there's not a lot you can miss because you just don't really use much from the ecosystem at that time when we switched to Rust there was already

quite a nice ecosystem for embedded stuff, a bunch of grades to try to abstract over the differences between different mic controllers. So we just like types for output pins and input pins and things like that. But it was fairly minimal. Nowadays, it's much bigger. But the one thing I found very, very nice

was how easy it was to, to modularize and reuse codes. So I was used to in a better to just always write everything from scratch. You don't have most of the standard library, right? No allocations and at least for me, I have four of them in my controllers. Yeah. And yeah, you just, every time you need something, you kind of build it on the spot from scratch.

And in Rust, it was so easy to make reusable code that would easily work also on a system without an operating system. So in Rust, you have this tag called no studs, which is kind of like the concept of freestanding in C++. Yeah. And there are a lot of libraries on Crates.io or

the place where people share crates packages that are actually compatible with Nosted. A lot of libraries are not. If you want to run a B3 map or something, you need something that can do allocations, but there's a lot of

algorithms, a lot of libraries on there that are tagged with Nosted, and you can actually just use those right away, even on the Mac controllers. And the Easeit, which you can just use in one of those libraries, because Rust just comes with its own package manager that literally everyone uses.

That made a lot of embedded development actually a lot easier. I was very used to just writing a driver for every sensor from scratch every time. It wasn't that much effort to get a data sheet and to figure out what exactly to send and read. But it took like half a day to get something working. And now, at least for like small tests and stuff, we would just find the package that someone already wrote for that particular sensor and just use it right away. Changing a four-hour job to like a 10 minute job so back over on the c++ side of the world a lot of people saying that c++ is doomed because it's a memory unsafe language and

that's often where rust comes into the conversation as well because obviously rust is doing a lot better in that area but uh i mean is has rust completely solved the memory safety issue um the mass video on your definition of memory safety like rust has a very strict definition of what it means for something to be memory safe um and guarding that border yeah for that it's it's nearly perfect but whether that that concept is is enough to guarantee bug free programs that's not a whole other story right um yeah well let's make it a bit more pragmatic then so the sort of memory safety issues that people would typically experience uh does rust do a much better job at solving those?

I think so. I can't really exactly point out why because like I said, there are a lot more problems with programming than just memory safety, even though it's a really big one. But from practice, I just noticed, like I just said earlier, that when teaching people Rust

versus when teaching people CO+, that they're using in some complicated system like those control systems we developed at Fusion. I just noticed that in CO plus people run into issues all the time. And in Rust, it happens so often that they just get it right the first time it compiles. That's part memory safety. That's part making it easier to make abstractions, having a built-in variant type a lot of other things um but all these things together in practice just often means that i see people getting things right

the first try uh where people almost get this feeling like oh if it compiles it's probably correct which is kind of a magical feeling yeah so it's not just the memory safety side of it that really leads to lower defect rates but it's more the expressiveness of the language being able to fit the solution space it's partially a culture thing that comes from the um from the focus on memory safety it sort of extends to other parts of the language like things in in rest the like variables being constant by default and unimutable if you specify it for the other way around, it's not related to memory safety if you do it the other way around. You can also make memory-safe language.

But this kind of comes from trying to make the safe choices the default choices in lots of features in the library, lots of features in the language. There's a lot of culture around trying to guide people towards doing the safe thing and making that the easy default while still allowing full expressiveness to do everything because Rust does try to be

a language that can be the lowest level language in your stack. So I think this is kind of something that a lot of people think is the biggest problem in C++. It's not that you can't write safe code, it's that it's not the default, right?

So like you can write code without using rule pointers or pointer arithmetics or without calling vector subscript operator that doesn't have any bounce checking. But the default is that all of these things are there. And there are static analysis tools that are going to tell you that you're doing something wrong, but you have to enable those.

They're not there out of the box, right? And so I think a lot of the noise that has happened over the last couple of years in the CSS community was that actually governments are now pushing to migrate the industry, basically, to memory-safe languages. And so people are saying, C++

is doomed, and it's going to be replaced by Rust eventually because it's not memory-safe, and we don't want to do that anymore. So do you think that's a likely scenario? Do you think Rust will that that's like a likely scenario do you think rust will eventually displace c++ or it's i don't think that's a question i can really answer like like we established before i'm very much in a rust bubble where sometimes i've even seen

relevant things go on the c++ world or other worlds so obviously from my perspective my little bubble everything around me is Rust and CF. Yeah, I remember that from some years ago. But yeah, that's just my little bubble. So I don't think I'm the right person to ask what the world looks like from outside this bubble. Yeah, fair enough. You're flipping that all around though if we're making the that the default choice is the safe ones then i mean that's still a trade-off that means it's going to make some things harder

and i have heard that there are certain things that are not necessarily that complex things which are much harder in rust like um uh what's the one that I heard, like node-based containers. Yeah, you don't have random access, right? You don't have, you can't have like arbitrary pointers to like things and do random access. You have to go- You can do all those things, just that you need an unsafe block because then you get to the same situation as in C++

where the user will need to be the one checking that it's right. And there's nothing wrong with that because I mean, people do that all the time. Everyone who's programming in C or C++ does that constantly. So it's not unsafe blocks are not some evil thing you should never touch. If you want to do some data structure like that

and you don't want to deal with like reference counting or trying to come up with some other way to make the world checker understand your structure, then it's perfectly fine to just use pointers. But yeah, you will use an unsafe block every time you reference them because the compiler is not going to promise you that the object you're pointing to is still there. But if you know it's still there, something that you do every single day

when you work on C5+, then yeah, you can just do the exact same thing in REST. Nothing wrong with that. Lots of data structures in the standard library are full of unsafe blocks. Yeah, C++ does have an unsafe keyword, but we spell it ints main. Well, maybe the right thing for C++ is to go the other way around, to have a safe block which of grow slowly or something. Because obviously our problem in C++ is that we have all of this code,

like, I don't know, the Linux kernel. Okay, that's actually C mostly and not C++. But like, I don't know, Qt, which is like a giant framework, or I don't know, the standard library, like all kinds of stuff, right? Which is written in unsafe C++ and you can't just flip the switch because none of the stuff will compile.

And we don't have the resources on the standard to rewrite those things, right? Yeah, the backwards compatibility thing is really hard to deal with. It's something that will over time also become a bigger and bigger struggle in Rust. Because you just start to notice like, oh, this decision that was made 10 years ago, maybe we would have made it differently now. Maybe we would have named this method slightly different. Maybe this language feature would have worked slightly different.

And some things we can still change. We have some cool mechanisms for adding some incompatible syntax with additions. But a lot of things we cannot really change and those things just accumulate you kind of feel those accumulating and so far they're still very small but i don't know i i don't want to see how how hard it will be to evolve for us say like 30 years from now or something um and c++ and c have have a lot of those things accumulated. That makes it very hard to,

I don't know, for example, add any of the bigger ergonomics features that Rust has. If you try to add those to CPath Plus, there's so many existing things that would break because they kind of need to take those things into account from the start

and you can't do that anymore. So yeah, Rust had a very big head start by just starting later. So we talked about all the things that C++ could learn from Rust. Safety by default, we have a great package manager.

It's apparently a lot easier to onboard people. There's all of these other things we talked about. But what about the other way around? Is there anything that Rust could still learn from c++ because c++ is also an evolving language right do you think c++ can be an inspiration for rust as well or is that just kind of this kind of old old thing that like you don't really care about anymore if you're in the rust universe i think yes but i think there think there's a lot of inspiration we take from things that didn't work out well in CO+.

Like, oh, let's try to do this differently. There's obviously also things that work out pretty well in CO+, that we just didn't pay enough attention to that we should pay more attention to, like the memory ordering thing I mentioned earlier. There's a lot of things where we could maybe collaborate. But a lot of development in Rust kind of starts with this idea

like, what if we could do it differently? What if we tried this thing that no one thought was possible? That's how we ended up with the Borough Checker, but also lots of other things, right? Yeah, I think we should be trying to get more inspiration from other languages. Like I said, it happens

so often that people are in a bubble. I am myself very much in a Rust bubble. But I would not want people to just take some feature from another language and just stuff it into Rust. But just use it as inspiration. But yeah, getting inspiration from many sources is always a great idea. So I find that really interesting what you said that, you know, in Rust you can just, you know,

go ahead and say, let's do things differently. I wonder if that also has to do with the different governing model because C++ is an ISO standard, right? So if you come to the ISO committee with a proposal that says, okay, let's just do this thing

that is completely new and different and see what happens, you're not going to get very far, right? The idea of an ISA standard is to standardize existing practice. You have to have, you know, extensive, you know, ideally implementation experience or user's experience with a feature already before it even goes into the language. Typically, it tends to be like relatively conservative, you know, based on things that people have been doing for a while, maybe with a new syntax or something.

But radical new ideas is not necessarily something that the ISO standardization process is known for. Obviously, Rust's governing model is very different. Can you talk just briefly about what the difference is and whether you think that that actually is a big part of the difference between the languages or the different approaches or whether you think that that actually is a big part of the difference between the languages or the different approaches or what you think is the better approach.

Should Rust be an ISO standard as well, maybe, or not? So a very big difference with C++ is that in Rust, it's the same team responsible for the language standard library and the implementation of a compiler

and the standard library. I mean, the different teams within that larger team, it's like the same organization. I mean, that both ships the Rust compiler and the standard library, not just an implementation of it, but just the, well, I don't want to say one and only, there's multiple smaller implementations out there, but basically everyone uses this as their main REST compiler. And that's quite different than in C++, where the committee only decides on like a document,

an abstract version of C++ and there's multiple implementations. And the IC committee is like a place where these different implementers come together together with experts and users to make sure everyone does the same thing, basically. So in Rust, we have, so we have the Rustlang organization, which is depending how you count 100 or 300 people. And in there, there's a bunch of teams. Like we have the library API team,

which is kind of like your LWG, I think. We have the language team, which is kind of like your EWG or CWG, depending on... Yeah, we have a split between design and wording as well. Yeah, we have that less, because we don't have a AVA Rust standard. So, the language theme of the library API theme

would kind of go about the definition of the language in the standard library, and then we have the compiler theme and the library theme, which is more about the maintenance, implementation of the compiler and library and the maintenance of it. And then there's teams for Cargo, Creates.io, and a whole bunch of other things. But yeah, all kinds of different teams. And these teams are generally between five and ten people, maybe. And the library API and language

teams are the ones where you usually go with a proposal for a change to the language or the standard library. And then something that we have embraced that you don't really have in C++ is the concept of unstable features. So when something gets accepted, it doesn't just mean that that's now part of the definition of the language. It means it becomes an unstable feature that can only be used on the nightly version of the compiler and needs to be opted into. And the nightly features, the unstable features, are something that can be removed at any time, can still be changed. And then users of the nightly version of the compiler can report feedback on it. And it usually changes a bit. After some experience reports, you might find out, oh, this feature should be tweaked a bit.

And then sometimes a few weeks and sometimes a few years down the line, it either gets removed or stabilized. So there is a lot more space for experimenting. I'm guessing that a c++ that would happen like in a single implementation like maybe you want to compile implement some feature that's not yet accepted into the standard yeah we have different ways of doing it obviously a compiler can go ahead and just implement a vendor extension and then eventually it ends up in the standard that's you know a bunch of things have been standardized this way uh We have also another thing, it's called a TS, a technical specification,

where you can actually standardize, not really standardize, but like publish through ISO a specification for an experimental feature. We did that with reflection, for example. We published a reflection TS, which had like type kind of template metaprogramming based reflection. And then, you know, we decided that's not what we want to do.

So the new proposal is more like object-based. But publishing a TS is like very slow because it has to go through ISO. So even just getting that document out takes like a year because of the overhead of like the ISO process. So I think you can just be a lot more agile with this stuff. Our process can adapt quite easily for very small features to very big features. So some language features, they take years of drafting

the exact rules and implementing them, experimenting with them, all the discussion. But sometimes there's also super tiny proposals. My very first change to the standard library before I was a team member was to add a constant to the standard library. We had

like pi and a bunch of other constants already and I wanted to add tau, which is something we use at the drone company a lot. So it is two times pi, full circle instead of half a circle ah yeah okay interesting and yeah i wrote a small proposal for that and then the library team discussed that and accepted it as unstable and then a bit later about stabilize and that just

took i don't know maybe a few weeks and that makes sense for such a small feature that it's like not a big discussion or the process of years right and being able to yeah adapt the process a bit for to both work for super small like features just adding a single method to our consensus and library all the way to like some mind-blowing language features that might need to take years is very valuable. In the library API team, which I'm a member of, we very often discuss very small proposals. People just want one extra method on a type like option or something, or just add something small. And it's nice to just be able to say, okay, sure, let's try it out, add it on unstable. And then if on unstable, there's enough users who are excited about it, and a lot of people

who say like, oh, this should be be different then we can just stabilize it relatively quickly yeah a few years ago I was starting a new web project like a personal project so as we were saying before I get to choose the technology stack and I thought I'll try Rust and this was a few years ago and I think the async io stuff was was all very much on the unstable nightly builds at the time and the web frameworks i was looking at were all based on that so and that every day i'd have to sort of pull the latest changes and then fix everything up and then i could start doing some work and it eventually just became a bit too tedious and i decided to use python in the end and then come back to it later. I think it's all matured now,

so I need to take another look. But yeah, with those big features, it can be a bit rough depending on something that's unstable. But the option was there and that's the main thing, I think. Right. So you mentioned that you're a member

of the Rust standard library API team. Your bio actually says that you're the team lead of that team. Yeah, so when I got started in Rust, or started with contributing to Rust, I very quickly was invited to become a reviewer for the library team. I started joining the meetings and then became a team member. But at that point, the library team had been inactive for a while. The previous team lead had

quit the project, I think a year before that. And I was full of energy, very excited about contributing to Rust and seeing that it was easier than some attempts I made in some other languages before. So I was spending a lot of time in Ethnum. And because of that, I quickly started doing a lot of things like actually running the meetings and organizing all our stuff going on, the library team. So at some point,

so back then there was just one library team. And at some point I drove the effort to split the library team into two teams, the library API team responsible for the interface, which people are saying yes and no to proposals, basically. You simplified it. And the library team, which is responsible for the organization and the implementation of the library and maintenance,

making sure there's enough reviewers, all those things. Because at the time, there were quite a few people who were interested in one of those things, but not the other. Nowadays, there's a lot of overlap, so maybe it's time to merge them again. But in that process, I became team lead of the library team and a while ago that turned into me being co-lead because I invited another,

he invited Amelie to also become team lead. He's nowadays doing most of the organizational work. So are you on the implementation side of things or on the API design? Both. Both. All right. Yeah, that's really cool. So how do you decide what goes into this Rust standard library? Is it just whatever people propose? For example, in C++, that's been an ongoing discussion,

what belongs in the standard library, and people have written stuff about it. C++ tends to be very conservative. We have a bunch of low-level stuff and very generic stuff, but we decided that very important things like 2D graphics or audio IO or other things that almost every application needs

are not are not going into the c++ standard library and we also don't still don't have networking which is another basic thing that you know many many applications need so we have this tendency of like saying okay higher level higher level stuff is just not something that is supposed to go in a standard library do you have something like this where you have like, what belongs in a Rust standard library? Because you also have the other advantage that you have over the associate. You have a great package manager, right?

So if something is not in a standard library, it's still pretty easy to pull it in. How do you decide what goes in there? Yeah, we don't yet have a document that actually properly describes what should go into the standard library or not. We tried a few times, and it turns out that all the different members of the library API team had a slightly different idea

of what the standard library should and shouldn't be. So it's still decided on a kind of ad hoc basis. But in general, we also try to keep it minimal, just like C++, like you said, because we have a great package manager there. And things like graphics or something, it's a lot easier to create on Crates.io because packages like that can release some very incompatible versions,

from 1.0 to 2.0 and 3.0. The standard library in REST will always need to be backwards compatible. So whenever we add something, we can never remove it. We can never make a backwards incompatible change. So that's something that is a big reason for not adding something.

If something looks like we might want to change at some point, like you might come up with some graphics API, but then a few years down the road, it would look different. Then yeah,

that shouldn't be part of the standard library. Another interesting question that very much relates is which parts go into core and which parts go into stud. We have these different standard libraries, three actually. We have core, alloc, and stud. Stud is like the full feature thing that you use on any system where you have like an operating system. And core is the part that's kind of comparable to the freestanding part of the standard library in C++, right?

And in Rust, core is just a subset of std. And then you have a separate library called alloc, which is also something that's pulled in by std, which has all the things like box, which is our unique pointer, things like arc, which is our shared pointer, et cetera, which is something that's used in embedded systems if you have enough RAM to actually do memory allocation.

So things like, I don't know, files and stuff, having a standard output and input all go into stud, but things like option and result go into core. And so for everything we add, it's not just a question of should it go into a standard library, but also should it go into core and so for every everything we add it's not just a question of should we go into standard library but also should go into core or or not luckily that question is very often just answered by can it go into core if yes and it should go there and if not shouldn't go into there yeah i guess it's mostly like if you call some operating system api to you know interact with the kernel or threads or memory or something like that then you're not yeah or if you might in a future version like you might have some data structure where today you might not need it but maybe in

the future it would be an implementation of users allocations so then you have to decide if you put it in core then you have to commit to just never doing that oh okay yeah that's another level yeah that's i haven't yeah interesting i haven't uh thought of that like a very very large part of our job in the api team is just predicting the future basically like okay this looks good today but will it look good five years from now ten years from now so how good are you at predicting the future then it's um it's's mostly based on regrets from precious mistakes and not repeating those. I think that's a good algorithm for the most part. Right.

So just to change the pace a little bit as we approach the end, since we are a C++ podcast but there are many of our listeners who are at least rust curious what would you say to somebody today who's considering getting into into rust who's a c++ developer oh that's a very good question let me think for a second it's a very good question i also want to know the answer. If I want to play around with Rust, where do I go? What IDE do I use and stuff like that? What's the entry point if I want to play around with it? So when I first started using Rust or tried to start using Rust,

I just read the Rust book, which is great, by the way. And I read most of it. I got excited about it and then didn't do anything with it and then forgot about rust and then repeated this process where i started reading the book again i was like oh yeah i remember this this was great i'm so excited doing things in there and then just didn't do anything and forgot about it i think i read the book three times in the end and the only thing that actually did work is just start doing something so i picked a small tool something that's generated code at

work and i just wrote it in rust and the code was terrible but at least i got to like you know i finally had reasons actually install the the tools i needed to to start looking up documentation get familiar with the standard library documentation make something work figure out where to ask questions and after implementing the implemented the thing, I was like, oh, this is exciting. I should do more of this. And so, yeah, I guess I don't have a clear hook or point where to start. It depends a lot on the person, but I guess the only advice I do have is just start making something.

It's the only way it actually sticks. Great advice. That's good advice so i have a follow-up question a lot of the time you know especially if you're getting into a new language and you're doing kind of exploring this as a hobby outside of work you don't want to just you know implement i don't know something that prints numbers on a console right you want to implement a game and this is fun like do you is it easy in rust to do things that you know draw things on the screen or you know do something with keyboard commands like all of

this high level stuff or do i then need to go like like in c++ i need to then figure out what application framework to use and what platform to target and then like by the time i figured that out i forgot what was the thing I wanted to develop in the first place. Yeah, so in Rust, we of course have the same, I don't know if I should call it a problem or a luxury, but of having multiple choices for literally everything. So it's not like, oh, I want the button on the screen, so I call the button function. No, you first have to figure out which library to use, and there's many of those. But yeah, Rust is extremely easy to get started with the library, because they're all in one place, they're all in Creates.io. You just type cargo add and then the

name of the library you want to use, and it's added to your project. At some point, I needed to do something that actually had a graphical user interface, and the library I picked for that was eGui. I very much love that library, but there's a lot of options. So just cargo, add eGui, read some documentation, and poof, I had a screen with a button and just went from there. And in like two days, I had actually a working application where I could stare at graphs, and it was for analyzing the data from the drones. So I would say it's fairly easy, but yeah,

you still have the same problem of having to make a choice of which library or framework to use. But yeah, nowadays, there's quite a lot of usable frameworks. If you want to do web server, there's a few obvious choices. If you want to do something with graphical user interfaces,

a few obvious choices. If you want to do game dev, there's a few great libraries. And yeah, just enter Rust with your type of application in Google and see what libraries pop up. Compare a few, libraries. And yeah, just enter Rust with your type of application in Google and see what libraries pop up. Compare a few, make a choice and just start experimenting with it.

That sounds like fun. I should maybe do that. Yes. I think we need to start wrapping up. Traditionally, our final question is, is there anything else in the world of C++ that you find interesting or exciting? But let's just modify that and say the world of C++

or Rust that you find particularly interesting, that, you know, something that's happening right now or in development or coming up. So in Rust itself, there's a few interesting things coming up. We have, we are nearing our 10-year anniversary since 1.0,

which is a very interesting milestone. Like at 1.0, which is quite an interesting milestone. At 1.0, there were not a lot of users, and that has grown exponentially. So that would be a great moment to start reflecting on everything that happened for the anniversary. And also toward the end of this year,

we'll be releasing a new edition of Rust every three years. We've released a new edition, which is three years. We release a new edition, which is the mechanism we use for backwards incompatible changes to the language. It's only changes to the frontend because backend changes, you can't really make backwards compatible,

but for the frontend, you just kind of pick a dialect of Rust for your per package, basically. So those are some big things going on in the Rust language itself. For me personally, something I'm excited about is for the past two years, I've focused a lot on implementation of things

and evaluating specific solutions. So people come to the team with like, oh, I can have a solution. And we have to say yes and no or give feedback. And I am slowly moving towards focusing more on the actual problems people have. So doing more user outreach, doing more language research, I guess would be the right term. And I'm very excited about that because there's,

there's a lot of interesting connections to be made between different problems. Different people are having that they don't see outside of their own bubble. Like maybe two people in completely different areas have a very different problem that actually have a shared solution to them, right? And I'm very excited about focusing more on, yeah, finding those solutions. And because like I said earlier,

as the bigger Rust grows and the longer it's around, the more, the harder it gets to find solutions to find new features that fit into everything else that already exists, which is even harder problem in languages that exist longer like C++. So yeah, we should really try to zoom out a bit more and try to get a bit of overview

of all the different problems that our users are experiencing instead of just sitting there and waiting for people to come to us with their proposals. So that's something I'm personally very excited about to start focusing on that a bit more. Nice. So in a way, you're excited about Rust becoming more boring and sensible? Boring is good. Yes.

Boring is great. Oh, in this case, it is. Yes. Yes. Boring is great. Oh, in this case it is. Yes. Yes. If Rust comes as a really boring language, we have done a great job, right? Absolutely. Yeah. Yeah.

Okay. Well, we're going to have to wrap it up there. Anything else you want to tell us, like where people can reach you if they want to find out more or other things they can look into? Yes. So everything about me is on marapost.com and it's linked to my book linked to my twitter and masterton and yeah if you want to interact with anything in rust you can find everything from us on github.com slash rust dash lang you can just ping me on anything.

Great. We'll put all those in the show notes as well. So thank you very much for coming on the show today, telling us all about Rust and how it compares to C++, so we can make any firm choice about what the future of C++ is going to be when it's doomed. Thank you very much for having me. Thank you. Thanks so much for listening in as we chat about C++.

We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in. Or if you have a suggestion for a guest or topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow CppCast on Twitter or Mastodon. You can also follow me and Phil individually on Twitter or Mastodon. All those links, as well as the show notes, can be found on the podcast website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.