David Sankel – Rust and C++ Interop

Intro

Tim: Welcome to Compose, a software development podcast featuring the Rust programming language and how it interacts with the world.

This episode features interoperability with C++ and how that might progress over the years and even decades ahead.

To talk us through it all is David Sankel from Adobe.

David is an invited speaker at this year’s Rust Forge Conference. Rust Forge itself is happening in Wellington, New Zealand, and you’re still very welcome to come.

For those of you who would even like a discount, try visiting rustforgeconf.com/compose.

Welcome to David

David Sankel: I guess I’m at heart a a computer nerd. So I’m sitting here and in front of me is like these little microprocessors, right? That I’m just programming for fun. But I guess who I am probably of interest to this community, I am a principal [00:01:00] scientist at Adobe and I run Adobe Software Technology Lab. And that is a team which is focused on what is going to be happening in the next 10 years with software development. And we’re very much, our heads are in that space and we have to figure out how we’re gonna have Adobe align with that future. And also how can we help steer the industry so that it can better support what’s going to be happening going forward.

So that’s my day job. And I’m also very involved in C++ Standardization committee, and now more recently involved in Rust and specifically Rust Interop and doing that at Adobe. So that’s

Tim: I feel like for many people that kind of sounds like a bit of a dream job, look, basically.

David Sankel: It is a dream job. Let me tell you a story about that because it’s funny. So Sean Parent, who is known in the C++ community, was running this team. And he invited me to, to join it. And he said that this is, she sold it pretty much as a dream job. And it was like, this is my dream job. And I got there [00:02:00] and he convinced me to swap positions with him. So I would run the team and he would have my dream job. And he managed that. And I was like, I see what you did there. You created the dream job and then you took it for yourself and made me the manager of the team, which is, slightly less than the dream job of actually being on the team.

But yeah …

Tim: It is, it takes a certain amount of humility to humility is possibly the wrong word, but to be really, and supportive of others and actually sharing in the facilitation of others’ success. And so the being a manager is, I actually think that’s a better paid, let’s say, but also a slightly underrated career track.

People look down on management in some ways as no longer being technical or something. But I think that it it is in some sense, gracious that you are able to give that up and just to enable, let’s say, multiply your own thoughts by X. So that’s a good thing [00:03:00] too, in my opinion.

David Sankel: Oh yeah, definitely. And I say this mostly in jest and as lead of software technology lab, I’m still very much involved in doing the actual technology. ‘Cause it’s a very small team. There’s only four people in the team. So yeah, I get to stay hands on and do all the crap work that Sean was doing before.

So I’m happy to have him spend his time not doing that crap work and take that

Tim: Yeah,

look, some people have to be professional, meaning goers, now

David Sankel: Yes.

Tim: anyway, we’re gonna need the like the actual chip number or like the part number of the microcontroller that you’re playing with at some point because I’m sure that the,

David Sankel: This is the STM32C011J4M6.

There you go.

Tim: For anyone that is coming to Rust Forge in, I guess it’s six weeks time from this recording, Espressif is actually donating several dozen microcontrollers.

We haven’t actually announced this, so this is the big reveal, but it should be the case. I hope we’re getting at least one for [00:04:00] everyone that it turn, that, that turns up.

Yeah, no, so there, there’s a segue in there as well, but that’s really great

and.

David Sankel: I am gonna be first in line for that thing.

Tim: Awesome. Awesome.

Adobe’s Rust Adoption Story

Tim: The the next thing is, so it, you are looking at the next 10 years of programming, let’s say, in a very broad way… rust is part of that story.

David Sankel: Yes.

Tim: When do you think large companies, such as Adobe or there are many billion dollar companies, let’s say, when do you think large enterprises would’ve really started to notice rust?

David Sankel: I think it’s already started. And I can tell you

Tim: Please do. Yeah.

David Sankel: from the beginning. Back in 2024 they created this memory Safety tiger team. Okay. And it included reps from security, the software technology lab developer experience, and legal reps. And the reason that it was created is because there was all this discussion of legislation [00:05:00] related to memory safety. And they wanted to figure out like, what is this? What are we gonna do about it? And you had the NSA you had, cisa, you had the White House even chiming in on this stuff. And at one point there was even a bill, I think it was like a defense spending bill, like a typical bill that, that when it was in the House of Representatives, the Congress they had like creating a memory safety plan for the Department of Defense.

And this little line got removed when it went in the Senate. So it didn’t actually end up in the final thing that got approved, but the fact that it was there was like huge. And so this team got together and we’re like, okay, what do we need to do about this? And we investigated and we looked at what was going on with like the published data that people were having.

So you look at the numbers, it’s okay, the number of exploits in software that are due to memory safety versus all the other exploits was like 70%. And you look at Microsoft’s numbers, it’s 70%. You look at Google’s [00:06:00] numbers at 70%. And then we looked internally and it’s yeah, it’s also right around that number too.

So there, there’s like something to this and the idea that you can switch your technology and get rid of 70% of your memory safety vulnerabilities like that. That was a big…

…my recollection of those papers as well, it’s not just 70% of bugs, let’s say, but 70% of severe and critical, severe use. So it’s like these are the. The majority of the worst cases of security problems. And yeah and we, and so this was a, so I guess it sounds like there were probably engineers thinking, ah, for the last multiple decades, and I’d be interested in C++ has had this in front of mind for a long time.

How do we deal with buffer overflows and how do we deal with memory safety in a way that is strongly backwards compatible, which I suppose is the C++ mantra really. And then [00:07:00] we have this new programming language, which somehow is able to offer memory safety without imposing garbage collection or some sort of other form of runtime checking to be able to allow things to work.

But it was really the, it sounds like it was really the fact that it had started to introduce legal risk that really started to motivate internal people to say, okay, we’re gonna fund something, at least some sort of discussion to make a decision on how we’re gonna proceed.

David Sankel: It, for us, like the legal risk was why upper level management got involved and they said, can you investigate this? When we investigated it, it wasn’t like, oh yes, there is significant legal risk. We’re looking at these, laws that are coming out. It was more. What about

Tim: Yeah. actually.

David Sankel: want our customers to [00:08:00] use safe software. That’s totally in our interest. And that’s actually our driving motivation in the, in this group, is we want to produce the most safe software that we can for our consumers. You imagine, if somebody comes out with a PDF that exploits your computer, how many people are using Acrobat?

We, look, there’s more people using, have Acrobat Reader on their computer than people that use Firefox,

like in total. So it’s a huge swath and if you take state actors or whatever yeah, if you wanna, get into people’s computers, you’re gonna try to get in the software that most people use.

And we’re definitely in that space.

Tim: Yeah. and PDF is not a simple format to protect against really. I don’t mean this, I don’t mean to cast any shade, but we’ve got multiple programming language interpreters. There’s at least a JavaScript runtime plus there’s two other languages, right? It’s own little macro language as well as Postscript in there too, I think.

but.

David Sankel: It is extremely complicated.

Yes. And the fact that it can embed a [00:09:00] JPEG or something like that and

Tim: Oh yeah. ’cause now every single codec that you support also has decompression. And you’ve also got inter essentially, like you have these baby interpreters for file formats, which are also exploitable as browser vendors have discovered multiple times. Yeah. And, okay. So that would be good to be able to defend against these kind of poisoned PDFs, which of course this is, that that’s a horrifically big vector of problems because of course you’re going to double click the PDF and open it.

When you get that via email.

David Sankel: Yeah. But like on the flip side, so from a software technology lab perspective before memory safety became something that everybody knew about and was talking about, we were already trying to figure out what’s going to be the future of programming languages. Is it going to be C++?

Is it gonna be one of these other languages?

And from our perspec perspective on that team, the memory safety wasn’t [00:10:00] actually the most interesting thing about rust, as a language to move to.

It’s just, flatly better tech for most applications, even if you didn’t have the memory safety aspect, if you look at like enums pattern matching traits, like all the procedurally macro driven libraries that are in there.

And there’s a lot of stuff like that just made it interesting. Hey, we want people to develop in these languages because they’re gonna be more productive and the code they’re writing is gonna be more maintainable and it’s gonna be easier to hire developers because it’s easier to get them to learn the language and be able to work on it.

This, these are like other big drivers that I think stand on their own without even looking at the memory

Tim: Yeah, I have been in very similar discussions where people look and say, oh gosh, we’ve got this huge problem. And that’s the motivating factor. But it turns out that rust is also a very good programming language and it has lots of nice things. We have Iterators, for example, that compose and just chain together quite [00:11:00] nicely and also get optimized quite well.

and then, from the point of view of comparing rust to, let’s say a Java C Sharp or even a Python or something, and my background is primarily in web services and so forth, but we would also say that we could probably reduce memory by, I don’t know, 90% and the cost of running an application.

Suddenly we only require 80 megabytes of RAM at steady state. So we don’t need giant instances with lots and lots of heap. So actually we are able to produce applications that run faster, serve users quicker, and or also more secure. And yeah, and by the way, yeah, also rust is quite a nice programming language.

And now we’ve got this other problem that, you are advocating for a programming language or at least saying to the rest of the company, by the way the grass is greener over there. How, but at [00:12:00] some point, the immune system of the organization responds to you and says, ah, we have a lot of other languages.

We don’t want to add another one to the mix.

David Sankel: Yep.

And we’re definitely see those really healthy immune system responses just like any, anywhere else. And I think that a lot of what’s been useful.

Responding to suspicions of Rust

David Sankel: To dispel some of the concerns that people have has been the great data that’s been put out there. So one of the concerns someone might say is oh, but Rust is really complex, right?

It’s a hard language to learn. We can’t wait for people to spend three years learning this language to be able to be productive in it. And then for that point out to the Google study that came out where it was like, I think it was after three months of development and rust from someone that has no experience at the beginning, two thirds outta people felt like they were very confident and productive in this language, right?

[00:13:00] So that you just point to the data. It’s like you can go with your anecdotal, feeling about it, but why do that when we can look at the data when there’s been like, good studies that have been put out there. And so a lot of things like this it’s just like getting the right information in front of people so that they can. They don’t have to go based on their gut. They can go based on something more solid and tangible. I think that’s been extremely helpful.

Tim: I’ve never worked at Google, but I’ve got lots of friends there.

And one of the things that makes me believe that research is that Google has full control over its build system and the developer experience as well.

Hiring Rust Developers

David Sankel: Mm-hmm. of the things that I would really like to pick up on was another claim around hiring. ’cause I’ve heard that hiring rust developers is really hard.

So one thing I can say is that hiring C++ developers is incredibly hard.

And for us I can’t share with you the data, but I can say that it is astronomically harder than hiring for any other language that we have [00:14:00] especially in the us. And that is another one of the motivations as to why we’re looking at. Other languages that we can bring on developers because if you’ve got a new project and you can’t staff it then, but you can change the language and staff it better. You may just change the language based on that alone. And so we looked a lot at the adoption of Rust in the wider community and we looked at again, we’re like, let’s see the data. And so there was a Stack Overflow survey that that came out. I think if you look at the 2024 Stack Overflow survey we crunched the data and we looked at the number of developers that are C++, and we looked at what portion of C++ developers right now. Are also rust developers and it was 20%, kinda blew our mind. 20% of all C++ developers are also developing rust. And this is like the question was asked like, have you programmed this seriously, like in the past year? And that’s huge and, but maybe that’s Stack Overflow could be weird. Only [00:15:00] weird people flow out that survey. But we also looked at the data from GitHub and one for every five C++ PRs on GitHub, there’s one Rust PR.

So again, like similar kind of number.

There’s just a lot of people programming Rust it turns out. And I’ve asked this question at conferences that I give talks at what, how many of you are programming Rust as well?

It’s like similar number everywhere. It seems to be right around 20%. And that’s changed from 16% like five years ago. It’s just been like a drastic increase in the number of Rust developers. So I, I. Do not have concerns of hiring Rust developers. If you say you got a rust position, you got like a bunch of people going wild because they would love to do rust full time. Just because it’s, you just feel better programming in that language.

Like going from Rust back to C++ kind of hurts a little bit. You die a little bit inside when you come back to that C++ project, and so there’s just enough enthusiasm for it that’s, that isn’t a concern, although people raise it. [00:16:00] But look at the data again. It, it really isn’t in actuality a concern.

Tim: Yeah, there is a lot of I forget the term, but it, there’s a particular psychological bias where we are afraid of change because of its loss aversion, I think where it’s will, people are hesitant to take on change or risk even when the. The outcome is likely to be positive. The other thing that I have found people resisting is this idea that Rust is as good as it sounds.

People make this claim around, oh, it’s a really lovely programming language to use. We finally have a genuine type system. We have no, we now, pointers don’t really exist in the language.

And it’s like, where’s the catch? and I guess the next thing to chat about would be when so Photoshop sounds like there are changes happening. What’s [00:17:00] happening?

David Sankel: Yeah. We are we are at the stage to where we’ve done a couple of pilot projects of where we’re doing rust inside of Photoshop, and we’re seeing how that’s going. Like what exactly happened? So we took a team, we said, okay, we have a project here. We want you to do this in rust for Photoshop. What is your experience of that? And it came out what you would expect, the people who use the language loved it. They’re reticent to go back to like a C++ kind of thing. Um, after that, um, they saw the productivity gains, uh, especially being able to use cargo.

I mean, one of the most powerful experiences you can have is when you’re like, Hmm. I think it’d be nice if we had a, a, a JavaScript interpreter in this program, and you just add a JavaScript interpreter with like one line, uh, in your cargo thing. But coming from a C++ background that is black magic, that should not be that

Tim: I look who doesn’t love tinkering [00:18:00] with sea make or whichever build systems that you feel like creating today. Why even have one build system when you could have four in your project or something? I don’t mean to be too rude, but Rust has definitely benefited from being late essentially, or learning from the experiences of the past and oh, that’s, so that’s really validating.

So you’ve got this public research, we’ve got this Google study, we’ve had other kind of language other wider bits and pieces. And now internally you’re validating that yourself and you’re not proven, you are that then able to demonstrate that not just the language is okay, but it would work well inside the build system or inside the context of of the rest of the environment within, inside the company.

David Sankel: Yeah. There was one thing that the experience pointed to that was. Bad for rust. Okay. ’cause they [00:19:00] give outta how many stars? Three, four outta five stars. Everything’s great. Hunky dory. But when you get to the C++ interop, that was where it was like that’s a problem. And so what we used was c bin gen. So essentially you’re writing these, the C functions in rust, right? But that you can call from C and that’ll generate a header, which we’ll call those C functions. And then the implementation of those functions will call your underlying rust code. And this involves a lot of unsafe, it also involves a lot of cism stuff that, that C++ people aren’t familiar with, right?

If you go back to the. Back in the day when you were writing C callbacks, you have a callback pointer function that you function, pointer that you pass in, but you also have to pass and avoid star for the context of that callback. And that’s just like this idiom that you do in C to do callbacks. But if you want to have a interop layer in C you have to do this and you have to [00:20:00] understand it. And so what we found is that when you take somebody who’s like C++, you know, expert or very familiar with the language, and the first thing they need to do is go to the most gnarly, awful part of rust, which is unsafe.

Weird stuff with pointers, like that experience is not

Tim: so let me paint the picture. So what we would like to do. Is basically pass objects around and their interfaces in some sort of ideal, essentially extend C++ or like bolt, either graft rust onto C++ in some way. Or graft C++ into rust or whatever. So that a rust programmer could just interact with methods from C++, uh, as though they were essentially native.

But we don’t have anything like that because the two compilers don’t know any really, we [00:21:00] don’t know enough. They don’t know enough about each other. They it’s a, you would need to teach Rust, all of C++ in order for that to work in that way.

maybe I should also chat a little bit about this concept of passing function pointers around for anyone that’s although maybe you can correct me here, David, because I’m sure that this isn’t technically precise, but essentially the C++ and Rust worlds, they need to talk to each other through symbols in the binary.

So they, when they lo the linker creates things and all they really have is text strings to match on. It’s or memory addresses. That void star is a memory address. And then C C doesn’t really have a strong type system. So you can basically say that any chunk of memory is any given type.

So what you’ll typically do is if you’re calling some external function or trying to call one of its functions is get the symbol, find, de resolve this. The, you ask the linker to resolve the. Memory address, what have you, [00:22:00] and then call the function with a buffer that you have allocated and then expect, just hope that the function does what it says, and then you need to reinterpret your buffer as the result type.

So essentially this void star just means any type at all. How correct was that? It was that ish.

David Sankel: Yeah. Yeah. That’s. That’s generally correct.

Interfacing between Rust and C++

David Sankel: So when interfacing between C++ and Rust, if you want to do something higher level than C right, you’re usually have a C intermediate layer and the C intermediate layer.

Let’s say you want to pass a C++ object over to Rust

Rust doesn’t have a idea of what C++ objects are. So you get a void star or you get a pointer, just a, an address and memory. And so when you wanna call back into C++, you just pass that pointer back and hopefully it [00:23:00] does the right thing and then do that. But it’s not just for the object, it’s for any argument, for any return type. All this is going through some like void stars under the hood. But I ideally you want to be better than what we did with that project, which is using like cbindgen, you want to have something which is richer.

And get this kind of interop working between C++ and Rust in a more seamless way. And so a lot of my work has been how do we make this happen? And how do we get this to work?

And I can go very deep into that subject if you’re interested, if…

Tim: Hit me because the this is something that lots of people are thinking a lot about, and if you wanna share, they would love to listen.

David Sankel: Sure. So to start out,

C++ Object Model and the Differences to Rust

David Sankel: the model of objects is very different between C++ and Rust.

If you have a Rust object at some place in memory, you can always just copy the bites from that place in memory to another place in memory.

And that effectively moves the object and the [00:24:00] object is valid in this other spot.

So if you do assignment in rust, like A equals B, um. You know, it, the, the way to think about it is, is basically taking the memory that or b was pointing to and, and make that the memory, the A is pointing to, right? It’s just moving the memory around.

Um, so in, in C++ that’s not how things work in general, if you have a, an object, like let’s say you have a, a, a stu list, like a link list or something along these lines, and the stu list is implemented this way, uh, in, in many compilers.

Tim: Oh, there is another,

David Sankel: lists.

Tim: because obviously in C++ we’ve got, we don’t have one compiler. We have a standard which is implemented by many vendors

David Sankel: yeah, and in this case the standard library, the implementation of standard lists is different. Now, one, one implementation that Microsoft has I dunno if they still have it, but they had for years, is that the end node of the list is [00:25:00] in the class itself. So you create a stud list the end nodes in the class itself.

It doesn’t have to allocate when you first create a stud list because it just has the start node, pointer point to an object in the class itself. Now the problem is if you take the memory of a stud list and you just put it to a different location and say, okay, now the object’s over there, that end Noe is now pointing back to where the original stood list was, right? So you don’t actually have a well-defined object if you just copy the memory to somewhere else.

The way that you move things in C++ is through a like a move constructor or a move assignment operator, where you by hand say how to create the object in the new location, which is equivalent to the old location. And that works totally fine with the stood list example, because you just. Update that end node to the right spot. But this mis mismatch turns out to be a really big deal when you want to interact with Rust, because everything in [00:26:00] Rust is mem-

Just copy the memory from one place to another, and if you put a C++ object in Rust and you just assign it to something else, now all of a sudden you cata catastrophically broke your objects.

And so that, that’s like a major problem. If you want to be able to talk about C++ objects when you’re operating within Rust.

Tim: Wow. Yeah, no, that makes a lot of sense. And it’s a pretty gnarly problem because you’ve got essentially two worldviews and that, and I was thinking, oh, couldn’t you just overload the copy trait for particular bits and pieces, but then not really no. That sounds tricky.

David Sankel: It’s very tricky because Rust gives you this guarantee. A bunch of generic code is out there, which will directly mem copy things around, and that’s totally

valid for every type that you give it. And so [00:27:00] what do you do?

CXX

David Sankel: So like the ways that people have been working around this issue one is through pinning. So if you pin and type in Rust or an object in Rust, you’re basically saying this object cannot move from this piece of memory.

So assignment and all this kind of stuff just doesn’t work with that as you would expect. ’cause it’s just pinned in memory. And if you use a pinned interface, the drawback is it’s very not ergonomic and Rust.

It’s like you work with a pinned object, you’re just like, oh, great, now I’m gonna have a bad day because this is just not friendly, good rust code anymore. And so the CXX crate, which is one, one way to do C++ Rust in a wrap follows this method. And then you have to deal with that as a drawback.

Zngur

David Sankel: Another option, and this is what Zengar does, so Zengar, Z-N-G-U-R, it’s not very well known yet. I’m trying to get more awareness to this c plus interop solution ’cause it’s it’s very good in many ways. But anyway, Zengar, what they do is they [00:28:00] say, okay, we will. Just allocate every time we create a C++ object.

So it always creates a C++ object on the heap. And that way when things are assigned, you’re just copying that pointer, back and forth. But then you’re paying a heap allocation, right? And that we lose our high performance there.

Tim: At least. At least. Yeah. So

just, and this may, this is probably obvious to most, but I’ll just reiterate it for my own ignorance perhaps, but mem copy is a ridiculously trick, which I like sub, like single digit cycles time probably. Whereas, and so this is, a millionth of a second a nanosecond scale.

And then a heap allocation, is anywhere, 10 to a hundred and 150, let’s say. It’s it’s a lot of time if you’re creating a lot of objects or if you’re just doing assignment a lot like sort of updates and you have to pay that cost every single time. That would be annoying.

David Sankel: Y Yeah. If I recall correctly, it’s a thousand

times [00:29:00] slower. So it’s a substantial thing, especially if you get a vector of these things. Now you pay that for, big ON,

Tim: Yeah, although references I guess which are just pointers really can, obviously they’re just the, in the rust world or we call this like the U size or the size of the bits of the SCPU architecture. They’re instantaneous to copy around anyway. So this is a, one of the advantages of like plunking things on the heap.

You pay, you amortize the cost of that allocation once because you can now mem copy as many times as you require later on.

David Sankel: Yes. Yep.

 Trivial Relocateability Addition to C++

David Sankel: Um, so there was a new feature that got added to C++ 26. We’re in 25, so it hasn’t come out yet, but it’s in the latest C++ draft, um, called Trivial Relocateability. And what this does is it identifies. The types in C++ to a rough [00:30:00] approximation, that can be me copied around because it turns out that stood list example, like that’s, that’s an outlier. Most things like a Stu Vector, most classes that you would write, you could actually just move the memory to new location and it would work. Okay. It’s technically undefined behavior, but it works because that’s just how it is. So the idea behind Trivial Relocateability was to see if there’s a way to make this carve out of types that support this and make that defined behavior. And so the thought was, oh, okay then maybe any type, which is trivially relocatable in C++ 26, we can put this on the rust stack and do stuff with it. If

Tim: did note that this was in the past tense.

David Sankel: Yeah. The problem was there’s a new architecture that Apple’s coming out with is called ARM 64 E, and it’s a security a BI [00:31:00] change primarily created for security purposes. And what they did is you, if you have a polymorphic type in C++, so something that inherits from something with a virtual function, um, that needs to have a V table in C++ to, to, in case you cast it to a base class, you need to point to the right function and so on. And so there’s a pointer in every polymorphic object to the V table, right? And this pointer is transparent to users. You don’t actually see that it’s there or whatever. Me copying objects with a V table is totally fine up until. Arm 64 E. And what they did for security purposes is they said, look, the V table pointer is a great way for hackers to, to own your process because they can just take that pointer and point it to their own code.

And next time you call a virtual function, you’re going into the attacker’s code. So they said what we’re gonna do is we’re gonna take the V table pointer [00:32:00] and use some of the extra bits in it because nobody actually has two to the 64 memory. So they’re gonna use these upper level bits and add some data in there that ties that V table pointer to the object, which contains the V table pointer, right? So that way if an attacker changes the VT pointer to something else, if it tries to execute that V table pointer, it’ll be like, Nope, can’t do that. You lost the signature, which

Tim: So the CPU will essentially fault because the yeah we’ve, it, I’m just going to use naive link. Maybe this isn’t, but it sounds a lot like a capabilities model where the original or some sort of providence back to the original memory address, let’s say. And if you Yeah, change the destination, those parity bits won’t work and therefore, or let some sort of checks sum, and then, oh. Your program will crash, which is probably better [00:33:00] than having some un foreign code execute until you want to do

something fun like interrupt with rust.

David Sankel: Yep. Exactly. And so in the C++ world, they solve this problem by saying, okay instead of saying, you can mem copy all these types to move them around, you can call this trivially relocate function and that will do it for you. You trivially relocate, it does the mem copy and it does all the V table pointer fix ups, and that’s all fine and dandy in the C++ world.

But now you go back to the Rust interop, Rust isn’t gonna do any vtable pointer fix ups for you, right? It’s literally copying the memory. And so that kind of broke that idea.

Extending C++ to Enable Rust Interop

David Sankel: And so what we’re trying to do now is add a new feature to C++, and this is primarily for Rust interop.

And what this will do is instead of having the primitive copy thing [00:34:00] from location A to location B, and then do the V two table pointer, fix up, it’s going to get a pointer to where it used to live. And a pointer to the current location and do the fix up that way.

So, essentially separating the movement of the memory from the point, the v table pointer, fix ups, if you have that. Then on the rust side, if you get an object, and this is hard to explain it, a podcast

Tim: yeah.

David Sankel: I’ll do my best.

Tim: It’s not the best,

not

it’s not the universal medium, let’s say.

David Sankel: Yes. You create your object on the, your c plus object on the rust stack. But you add a little bit at the end, which is enough for a pointer. And so when you initially create the object, you have all your data for the object and you have a pointer, which is just happens to be set to where the object’s location is. Now on the rest side, you can assign, you can move things around. Now the [00:35:00] object is in some other location somewhere else. And that pointer is still set to the original place that object lived. The data for that object is the data that we’re what it used to be, but it’s just in a new location now.

When you call a c plus function, you need to make sure this is all fixed up. So when you call your intermediate C layer, which eventually calls your C function, that intermediate C layer will call that special new function that got added to the standard, which says, Hey, here’s the pointer to the old location.

Here’s the data at the new location. It’ll fix up all the pointers for you, and now it’s valid. And define behavior to call that c plus function that you were calling.

Tim: That sounds innovative. Well done. It’s have you unlocked the puzzle? Have you solved the puzzle, do you think? Or at least

David Sankel: I, think.

Tim: okay.

David Sankel: we may have, there are still some open questions on how to deal with this on the rust side because that works fine and dandy for, uh, C++ objects [00:36:00] you create in Rust. But what if C++ gives you an object or a reference to one of those objects? Now that one doesn’t have the little

space at the end with the pointer, so that might be a different type.

You might want to convert it to one with the pointer thing at the end. I don’t know. There, there’s some, some thought

Tim: So if I was a, although but yeah, no that, that seems like a decent enough chunk of the problem to be a good step forward because I presume that if I was importing a C library, sorry, c plus library from rust, most of the time I would be initializing the objects rather than essentially receiving an object that was created in the library itself.

So no, that’s really interesting.

C++ Standards Committee

Tim: How does it change like that happen? It must be. This is a little bit about how the committee works, but there must be years of deliberation for things like this to make [00:37:00] progress.

David Sankel: With the committee there’s a lot of formalisms and structure and all these kinds of things, people frequently get defeated by it because it’s just like too overwhelming, too complicated. But if you understand it, there are tricks that you can do. So here’s the trick that we’re gonna do or we’re gonna attempt, we’ll see if it actually works.

So right now, no new features are allowed for C++ 26,

right? It’s already been stamped. It’s going out to the national

bodies for ballot at this point. And now we deal with what’s called National body comments. So every national body can say, okay, we released this, we got this spec, and we have a comment about this, a comment about this.

And these are usually comments about bug fixes. You can never say add a new feature with a comment. And and this is a new feature in c plus 26 is trivially relocatable thing. And so what I’m planning on doing is making a national body comment for the us, which says that we got our primitive wrong. The trivially [00:38:00] relocate function is not actually the simplest way to express this primitive like basis operation for trivially relocatable types. It’s this other thing, which is called start lifetime. At and through this bug fixing process, I’m hopeful we’ll be able to say, oh yeah, that was a mistake. And so before se LS plus 26 ships, we’re going to have this new basis operation and that will unlock this rust interop thing, but also solves another problem that people had with the feature, which was that

it didn’t work with re alec where you basically have an existing buffer that you’re expanding and sometimes it can expand at the same place. So I’m hopeful that we can get this to happen, but yeah we’re using this national body comment process to, to slip it in. Otherwise we’re gonna have to wait for C++ 29.

Tim: I am curious. I’ll watch. I think it’ll be fascinating because especially it’s almost, there’s always a meta discussion as well, but the committee processes are [00:39:00] challenging. A lot of people don’t really have, the stamina or it, ’cause everyone is so emotionally involved because they wouldn’t be there if they

didn’t think that things could move forward or improve.

And they’ve got this great idea that they’ve been working on for years. They have a working implementation before they even start proposing it. And now you’re telling me you gotta, I gotta wait. Like I gotta get, it’s, yeah. I can just imagine that if I was. Doing this out of love or something that there’s no way I would be able to last a five to 10 years to get new things through.

I was looking at one time, or I think it was concepts, how there were multiple implementations and different ideas about the way that could work. And but then again for something as impactful as making a change to one of the most fundamental programming languages in the world maybe waiting five years isn’t very long.

Like, I mean, [00:40:00] uh, C++ is, um, is everywhere. And so it’s extremely fundamental and it’s extremely important. The stakes are very, very high, and so it makes sense to take things slow.

David Sankel: I, I think so. And I think that’s one of its particular charisms is that. It is generally a slow moving language, not as slow as C although C is speeding up. But you only can take on so much new stuff at a time. And I think actually in my opinion, c plus has grown too fast for its own good. We’ve hit some kind of tipping point to where the complexity is more of a problem than it was a solution. And I don’t know how to reverse that

Software Complexity Grows Over Time

Tim: I think may maybe, human bias or something, but it’s much easier to add an extra feature, like an extra box to the checklist or like the feature list.

But, taking things away is really is much harder.

Just imagine saying, actually we’ll cut that out.

Is [00:41:00] essentially impossible. More generally than C++, but it’s like any sort of product, for example, software things, software products in general, I think have this tendency to grow until they collapse under their own weight.

David Sankel: Yeah, I think so. Also if you look at it from like a company perspective let’s say you’ve got a huge code base. I think the last quote I got from Photoshop was like 79 million lines of code, right? So we’re talking a lot of code and somebody from a standardization body says, Hey, you need to change, a million lines of your code because we found a better way to do something. And the response is does that add any value to my product?

Tim: Do the customers care? no, not really. Yeah.

David Sankel: Okay, so somebody up in the ivory tower has decided there’s a better way to do something and now I have to pay a buttload of money for, that’s not gonna actually have any tangible benefit.

Nah.

Rather keep the existing code. You wanna do something new with the new codewe [00:42:00] right? Great.

But like that old code, if it’s working and it’s doing its job like please don’t make me have to do anything with it. ’cause the

scale is too big. It is just way too much.

Lessons for Individuals

Tim: Are there any lessons for individuals that you think if, who are navigating, while we come we’ve talked about Rust language, C++ language, you know, companies, but what about, uh, people and their own careers?

David Sankel: Yeah, I think that’s a really good question. I think I can speak in particular for C++ developers.

For someone who’s a C++ developer, they’re an expert in it. You know, they feel very powerful in that language. And the idea of going to any other language, you’d feel very weakened, right? Because you’re just so used to this language. If you’re a c plus developer you have a choice, right? You will definitely, no matter what stage of your career, be able to program c plus for the rest of your career.

This is not going away. There. [00:43:00] Jobs are gonna be there. But it will be with a legacy language, especially towards the end of your career, it’s gonna be like, there are some FORTRAN people today and they do their thing.

There are some COBOL people. I don’t think it’ll be that bad in 20 years, but it’ll be in that space, right? But just be okay with that if that’s what you want to do. If you’re looking, if you wanna be. Where the innovation is happening, then you’re gonna have to take a different approach and you’re gonna have to look at things like Rust and Rust in particular right now, I think is really important to look at. And don’t be threatened by it. See, I, something that’s not talked about a lot is that rust is an outgrowth of C++. C++ is almost its granddaddy.

People hate it when I say that, but it’s true. So many lessons that were learned from C++ were incorporated in a rust, whether it’s acknowledged or not, it’s just obvious in the design.

And if you look at it like that, it’s, you can be proud of [00:44:00] it, right?

You’re a C++. Look at all the stuff that they learned from C++. That’s great. All the stuff that I did to help grow C++ or, or build C++ knowledge in the community of people that I’m, I’m, I’m with. This is a consequence of that. It’s a benefit of it. And if you look at it like that, it’s not as threatening.

It’s not like an us versus them. It’s more like. You know, good for them. You know, like, let me look into this because this is the next step in C++’s growth is actually Rust it’s the, you wouldn’t say next step in C++’s growth, but next step in growth for a systems engineer is using the latest tech. And the same is true for AI, right? It’s like another one of these things is it’s gonna be here, right? You’re not gonna change it and make it go away. But you can be part of the future and what it’s going to bring. And so I would recommend to people to be open-minded about it.

Check it out, try it in a real project. You want to seek that feeling that so many people report that. Oh, I went and I used rust and I really don’t wanna use c plus anymore after that. You [00:45:00] wanna seek that experience, right? Because then you can get it and you can see where they’re coming from and then, see where that takes you.

But you gotta be open-minded, right? It’s just gonna, you’re gonna have to try out some things and get past some biases and just say like, all right, I’m gonna, I’m gonna give it a whirl.

Rust’s Origins

Tim: I think of Rust as a bit of a spiritual successor to C++.

The one funny thing actually is and Rust has learned so much from systems programming experience over over several decades, and it’s as though we have taken the lessons around initialization and destruction and just encoded that in the type system or into the compiler. There is this liberating feeling, knowing that you are never going to need to worry about, I don’t know, deleting an object twice. It’s just, oh, that’s not a, that’s not a concern that I need to have perhaps.

But another thing is maybe they front load the concern because [00:46:00] you know your design needs to be correct, but also, isn’t it so much better that you get told that there’s a problem early before you get told by your users that there’s a problem or worse they don’t tell you ’cause they don’t know.

And they’ve got introduced some sort of horrendous bug by the way that a lot of that stuff around C++ was accidental. I don’t, I am not gonna be able to find the reference, but grad whore is was talking I think it might have been on Twitter that or saying that was not the original intent with Rust.

The original intent was something much more closer to go where you or I guess much more with a much greater focus on concurrency. But then when it was adopted by Mozilla, the Firefox group really wanted to essentially be zero cost abstractions all the way down and had this very heavy, [00:47:00] practical focus on being as lean at runtime as possible.

Because if Rust was to ever compete. It needed to be able it needed to shed. Its its runtime, which it had at one, very pre 1.0 like it’s now over a decade ago. But it’s a slight accident of history, but also really positive that the language was incubated in production. The idea that we could, we were creating a programming language to be able to work in the context of a c plus program to enable multi-core.

And that was a very, like a multimillion lines of code base with built by many teams. And so all of those features were like part of, it’s, part of it how, part of how it grew up out of a hobby project originally. I think it would be [00:48:00] like, this has just been such a really nice arc all the way.

And thank you so much for sharing your thoughts. Has there been anything else that’s popped into your mind as we’ve been chatting that you’re like, oh, I should tell people about that?

Final Thoughts

David Sankel: I guess probably the biggest thing is check out Zengar for doing c plus interop. The, it’s way less known than it deserves as a c plus interop layer. Like very interesting. That’s probably the biggest thing that

Tim: Okay.

Fantastic. I am so looking forward to your talk in New Zealand next month. I am just, I feel so incredibly honored that you have decided that you accepted our offer to, to come down here. And I hope that you have a very. Enjoyable experience in the country. Until then, I hope that you also actually enjoy the process of preparing for a talk.

I know that you’ll have a very receptive audience, so thank you both for sharing your time and sharing your expertise. So thanks, David.

David Sankel: Oh, thank you so much. I am [00:49:00] so psyched about the conference, so I can’t wait to be there.