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.
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 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
I feel like for many people that kind of sounds like a bit of
a dream job, look, basically.
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 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
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 too, in my opinion.
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
Yeah,
look, some people have to be professional, meaning goers, now
Yes.
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,
This is the STM32C011J4M6.
There you go.
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 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.
I am gonna be first in line for that thing.
Awesome.
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.
Yes.
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?
I think it's already started.
And I can tell you
Please do.
Yeah.
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 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 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
And
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 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.
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
Yeah.
actually.
want our customers to 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.
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.
It is extremely complicated.
Yes.
And the fact that it can embed a JPEG or something like that and
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.
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
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
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
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 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.
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.
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?
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.
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.
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 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 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.
But look at the data again.
It, it really isn't in actuality a concern.
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 happening?
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
I look who doesn't love tinkering 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.
Yeah.
There was one thing that the experience pointed to that was.
Bad for rust.
Okay.
'cause they 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 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
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 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, 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.
Yeah.
That's.
That's generally correct.
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 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...
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.
Sure.
So to start out,
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 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.
Oh, there is another,
lists.
because obviously in C++ we've got, we don't have one compiler.
We have a standard which is implemented by many vendors
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 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 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.
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.
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 what do you do?
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.
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 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.
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.
Y Yeah.
If I recall correctly, it's a thousand
times slower.
So it's a substantial thing, especially if you get a vector of these things.
Now you pay that for, big ON,
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.
Yes.
Yep.
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 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
did note that this was in the past tense.
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 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 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
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 than having some un
foreign code execute until you want to do
something fun like interrupt with rust.
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.
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 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
yeah.
I'll do my best.
It's not the best,
not
it's not the universal medium, let's say.
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 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.
That sounds innovative.
Well done.
It's have you unlocked the puzzle?
Have you solved the puzzle, do you think?
Or at least
I, think.
okay.
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 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
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.
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 progress.
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 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.
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 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, 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.
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
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 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.
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?
Do the customers care?
no, not really.
Yeah.
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 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.
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?
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.
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 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 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.
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 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, 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 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?
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
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.
Oh, thank you so much.
I am so psyched about the conference, so I can't wait to be there.