# 2026-03-04 Interop + Lang

Attendees: Jack, Niko, teor, Connor Horman, Taylor Cramer, Joel Marcey, Josh Triplett, Devin Jeanpierre, Tyler Mandry

Here are some things it might be useful for us to discuss:
* high priority / easy win interop use cases
* missing use cases (or missing problems in existing use cases)
* next steps for high priority use cases
* how can I help make progress? For example, writing or reviewing RFCs, implementing, reviewing, or testing compiler features
* I'll be expanding the use cases and problem summaries anyway, but if I'm ever waiting on those tasks, I'm happy to jump in on other work.

Interop initative repo: https://github.com/rustfoundation/interop-initiative

## Minutes

Introductions
* [teor's background description in Zulip](https://rust-lang.zulipchat.com/#narrow/channel/427678-t-lang.2Finterop/topic/Short-term.20Contractor.20Opportunity.20for.20Interop.20Initiative/near/574637156)

Jack: "What do you want to get out of this meeting?"

Teor: Writing down interop use cases, and problems that would make those use cases easier. Want to fill in any use cases that are missing. At the stage where it would be useful to focus on high priority or easy wins.

Teor: Contract is not just defining problems, but working on them.

Taylor: Do you have a timeline in mind? What do you view your role as?

Teor: Throw to Joel. My role is to be here to help out.

Joel: Current scope is to come up with as many problem statements as possible. 3 months could possibly be extended. Sometime around all-hands, May/June, agreed upon set of problems statements to look for solutions to.

Joel: Teor can do technical side, or do Project management side

Devin: Given that, I might be wildly off course. I'm tech lead for interop at Google, we work on crubit, cramertj is dev lead. crubit is aimed at solving interop problems. For example, "you should be able to use std::vector from Rust". From my POV, those are solved problems, we can do that, or we know how to do it. But there are things that nobody can do, that can't be outsourced, because of fundamental limitations in either Rust or C++. For example, the issues with pin ergonomics, or overloading, instantiating templates in general (not std-vector in particular).

Devin: I know tmandry has done a lot of work in terms of cataloging all of these, but I think that's the directions that seem interesting from my POV working on an interop tool.

JoshTriplett: One of the things that interop most commonly gets held up-- I'm personally very interested in the use case of "I have a codebase and I want to add Rust to it" (or much less commonly, I have a Rust codebase and want to add C++). The amount of friction involved in "open a new file and start writing code" when adding another cpp file is trivial, but to add a rs file, there's a lot of steps. Seeing interop not just through FFI/libraries/components but "I have a codebase that I want to incrementally migrate to Rust" is a lens that'd be useful for many projects out there. That has different possible tools and solutions compared to something with a long-term trajectory of staying integrated. It's something where you control the whole codebase so you can pick tools/choices to make interop easier but you need the tools to help you with that.

Jack: On my side that sounds good I think it'd be good to talk to the crubit/cxx folks (*cramertj waves*) to see what are the things not working at the lang level and how could they be prioritized. I know tmandry/cramertj gave a great talk at RustConf, haven't heard so much from other companies. I don't know if there are any *easy wins* here, except that, if there's something everyone needs, maybe that's the place to start.

cramertj: That's a good point. To Josh's point, if you haven't thought about it already, consider who your customers are. Are you trying to unblock people like me + Devin working at a large company with ability to make our own investments or are you targeting somebody who wants to throw a couple of lines of Rust into their open-source cmake project. Depending on the answer is might change what the right next steps are. I will say there are some things common to everyone that would be helpful to solve. From the crubit side we would love to see over time our tools become more accessible to people in that lower layer who aren't necessarily willing to build their llvm+rustc from scratch whenever they want to do anything. We've been investing in that direction and I'd be happy to talk about it but in the meantime I'd like to know who you think your customers are.

teor: I don't think it's my role to pick winners if that makes sense. I agree that if we can find things that would benefit almost everybody than those are good things to work on.

jackh726: The other side of this is for the things like making a project easy to setup to add Rust to it, these are things that maybe the Rust project or Rust foundation can maintain if there's some standard setup you can add to your C++ build and it just works. That could be a useful first step, if there's something easy that we can just *start* to build on... I don't know, it's a balance, having the set of problems in mind to do at the language/library level, but how do we find a path to making those a reality?

joshtriplett: Disclaimer, I'm not trying to open the rathole of solution space. I think it's worth bifurcation of use-cases and tooling. What kinds of tools would make things go from possible-but-hard to easier? Sometimes that's *integration* of tooling. There may be a lot that is tooling compilers and distribution to make that easier. Can we have a version of clang distributed as part of the project? LLVM linkable libraries? Going all the way to "can we get a C compiler integrated into rustc because there's a bunch of possibilities that unlocks" (niko: gasps in horror). Some part of the problem is that the tools are just fiddly and hard to setup.

tmandry: Along those lines, I totally agree, there's a lot of progress to be made in terms of standardizing tooling. I know there was a push to put clang in rustup ([RFC link](https://github.com/rust-lang/rfcs/pull/3847) added by cramertj). I don't remember the status of that. Making that be an actual supported workflow for people where not only do you have clang that you can link to rustc, you can enable sanitizers across the language. BorrowSanitizer is another piece of research that we are funding but we are actively working to get that code upstreamed into LLVM.

On the language design, as someone mentioned, I've been doing a lot of connecting dots from "things crubit can't yet do" to "project goals upstream". The problem space mapping could fit into that, we could write a roadmap for better C++ interop.

Devin: on the topic of picking a winner, I didn't mean to say crubit should be the winner, but there's a lot of problems that tools can solve without any action in Rust upstream. You can let a winner materialize. But there are a lot of things that crubit/cxx/bindgen can't do at all. Some is language but Josh's focus on toolchain is interesting, it's not something I normally worry about, it's all packaged in our monorepo. Even for distribution, aside from a C++ compiler, making it easier to distribute the *interop tools*, we have a big problem just integrating with Rust -- you need to use unstable Rust, etc, any interop tool following a similar strategy will have that same problem. Only other category that's *really* interesting to solve centrally is "vocabulary types". Speaking of std-vector, if there was a crate in crates.io that was for std-vector, guaranteed to have the same layout as your local std-library's version of std-vector, then anyone building any interop tool could use it, things would be compatible with each other, etc.

jackh726: one thing that has been said is that finding who the customer is is good, not just "orgs vs individuals" but also "if a company is already using C++ and they want to add Rust, likely they have some build system, so if we just make it really easy to add cargo to build the Rust side of things, is that going to be enough for them?" Part of defining the problem space is -- who does the problem solve for? I really did like Devin's point though, that it's possible these solutions will live outside the language, and we need better ecosystem for things. Good thing to think about.

joshtriplett: One other aspect worth covering, as much as the phrase C/C++ is a bit of a misnomer, it's worth capturing aspects of C because as much as they are commonly used for different purposes, they still have common vocabulary, common types, etc. There are things we can do that would specifically make C++ better and there are things we can do that would make both C and C++ better. There's a certain degree where we need to keep the end-goal of supporting C++ in mind so that we successfully reach interop with hard things like std-string, std-vector. Those are harder than anything you'll find in C. But there are things we could do that would help across the board. C can be a testbed for anything involving toolchain or similar. If you can do C there, you've gotten a large part of the way there. Then you have library + language interop problems. You can solve a lot of tooling problems by prototyping with C.

niko: We have had outreach from the Yocto project, we should talk to them about toolchain issues

connor: to add to josh's point, linking I have had some fun linking with Rust. Not with C++ but C, I imagine the stories are very similar, definitely a scope that would cover and effect both. You fix one and you get both very close of the way there.

jackh726: Teor, thoughts or questions, something else beyond what's been said that you are curious about?

teor: Yeah, I think it would be helpful for us to identify use cases with high/broad number of users, and things that can only be done in the compiler. Would give an idea what to focus on.

Josh: One other aspect worth covering: sometimes we get into the mode of analysis paralysis. Long-term planning is a good thing - also worth looking at how well we can do fast iteration and prototyping. E.g. `std::vector` in Rust. Looking at how we can get pigs to fly is okay, but sometimes the quicker/easier things are useful. Would be good to get vibe checks from various teams involved.

Devin: The issue I have with that is that it's a lot of work. We have at least 3 different impls of `std::vector`

Josh: :+1:, ack for tools that exist. We should either do things that haven't been done, or catalogue things that have. Want to avoid the mode where we admire the problem and don't do either of those two.

Taylor: One thing that happens a lot: people get confused between C++ calling Rust, and Rust calling C++. Calling Rust from C++ is more of a solved problem from design space, but less of a solved problem from tooling/ecosystem space. Small/medium sized projects may be able to keep dependency unidirectional (C++ to Rust). Ironing out story of builds, linking, static libs, etc.

Niko: I want to ask two questions. First, why shouldn't we bless crubit - more to the point: we're really scaredy-cats in the Rust orgs. Would be great to tell you that there's a great tool to use. Next question: when we talk about who are customers are: help people help themselves, or help them ourselves. We're more about building out the building blocks. We built Cargo, not a thousand package managers.

Josh: Two things: direct, we do have a fear of picking winners. We're really good at doing the right thing when we're opinionated. Cargo is good, because of opinions; it would be bad if we tried to do everything for everyone.

Josh: Regarding the idea of having vocabulary types. There are different ways to be compatible with types. E.g. hashmap: I know how a hashmap is laid out, vs I how to call functions on an (opaque) hash map, which is probably the only thing that will work when there are multiple Rust standard libraries in a project. Along the same lines, worth looking at the family of solutions that are data layout solutions. ABI stability: C++ is more stable now, but would be nice to insulate ourselves slightly in that regard. Would be nice to put some stuff in Rust std - reasonably confident that not

jack: same problems as the CPython people, static libs. Already covered in the Rust issue tracker. Struggle to keep track of all the problems historically

Taylor: respond to why not crubit: We care about getting into the state of making something open-source, but (it's) not open-source enough to be used widely. Cargo makes open-source projects tractable for a lot of people, because of a unified language for it. Not everybody wants to opt-in. At some point, I can get an overview of what's left in the stable interface. At Google, a bunch of people hack together things that are not necessarily stable b/c not willing to drive to stabilization once needs are met.

Tyler: We would all benefit from a set of use cases that everybody uses. The team is working on a subset of users to be able to use crubit. That could be one focus point. In the long run if we want to move in the direction of e.g. clang in the Rust compiler, will need to build on something like crubit.

Devin: I'm in favor of blessing crubit - don't care if it isn't finished. Large differences in philosophy between crubit and Zngur. Blessing something big is scary.

Jack: anything else to discuss, Teor

Teor: We've talking a lot about the problem space at a high level. If we could quickly go around and pick one thing to focus on next, problem/use case/solution. Just one thing, if you had time.

Jack: skip
niko: skip
Connor: build system integration Rust / C / C++
Joel: skip
Josh: build system integration, swap out C compiler and instantly start writing Rust, almost zero overhead. Un-mothballing crABI.
Taylor: On the C++ calls Rust side, finalizing tooling and integration pieces. CMake and Bazel support (Connor: autotools + make). Rust calling C++ side, overloading.
Devin: Specialization. (Taylor: and tractable). I want language features.
Tyler: +1 for overloading, I did say specialization looks tractable, Jack said no.

Josh: I think the noticable different comments from Taylor and Devin are an interesting dichotomy of what's there. On one side, there exists a tool. On the other, how to get a project from "it's working" to "it's working and sucks less"

Devin: I would have said toolchain integration if nobody else did. "Making it really easy" (that is, it isn't easy) is a blocker for some people.

Josh: It does make sense in both directions. I'm impressed projects can go grab crubit. Creates two tier system: those who put in a bunch of work, those who don't.

Teor: What kind of work needs to be done to make these things possible. Problem defintion, RFC stage, etc.?

Josh: for different problems, different things. For things involving language work: experiments, RFCs. Overloading in progress. Specialization is making non-zero progress. For things involving toolchain, prototyping an implementation, talk to compiler, talk to toolchain people. For the vocabulary type, some libs, if that's too painful, language.

Connor: My thoughts about toolchain thing: two ways to do it: either create a new build system, or make a new one. Don't know if modifying cargo will go well. (Jack: working out why modifying cargo would not go well?)

Devin: The difficulties when working on crubit, is so many people do different things. Not just that you depend on a thing, but so many different flags, allocators, standard library, etc. To make someone that doesn't really care: the idea of just bundling of "here's just the support tools for a given configuration". Can make *one thing* easy.

Tyler: On overloading point: well-scoped lang experiment that someone can implement. Don't have anyone to implement. Basically just an attribute to put on a function. That plus inherent trait functions.

Jack: What would work for you for continued support, Teor.

Teor: Another month would be good, but earlier I'll message you.

Niko: Taylor, you said you're looking to document all the things you could do. We're also talking about customer. Going into all-hands, would be good to be able to segment who is doing C++ interop.

Teor: Having a list of problems is not particularly useful without knowing who they're for. Not prioritizing myself.

Josh: Raising one other item: when we do next round of meeting, very lang heavy. Light on libs-api. Would be nice to pull in libs and compiler. We had a particular flavor.

Thanks Joel!: \/

## Chat Discussion

Taylor (cramertj@)
Taylor (cramertj@) says:Sorry, I missed the thread-- do we have a hackmd?

13:02

NM
Niko Matsakis
Niko Matsakis says:
https://hackmd.io/@jackh726/BJdKaGIY-l

13:02

DJ
Devin Jeanpierre
Devin Jeanpierre says:The toolchain integration frustration is a very good point!

13:13

me says:FYI - I have an action item to get teor and David Tolnay together for a discussion.

👍

13:14

me says:around cxx

13:14

J
Jack
Jack says:create-rust-app for

13:18

Jack says:Rust

13:18

Jack says:and C++

13:18

TC
Taylor (cramertj@)
Taylor (cramertj@) says:I'd also love to chat about Corrosion and who it is a good fit for

13:19

Taylor (cramertj@) says:
https://github.com/corrosion-rs/corrosion

13:19

Taylor (cramertj@) says:OVERLOADING

13:22

J
Josh
Josh says:There are problems you don't see if you work in a large functional organization with enough spare capacity that you can dedicate people to tooling.

13:22

TC
Taylor (cramertj@)
Taylor (cramertj@) says:^100%

13:22

J
Josh
Josh says:And props to such organizations, to be clear, but we should make it so easy that you can do it without needing that.

👍

13:22

TM
Tyler Mandry
Tyler Mandry says:...and making it so the workflows they support directly (e.g. cross-lang sanitizers) are supported broadly in the ecosystem helps everyone

👍

13:23

J
Josh
Josh says:Or Rust, because not everyone uses Cargo, and I say that as someone *on the cargo team.

13:24

me says:I think have a comprehensive list of problems that currently exist and matching those against a set of criteria that we come up with to tackle, maybe from low hanging fruit to hardest to implement (work towards solving the 80% problem) - you can imagine that a common problem that doesn't require a Rust language change would be something we should focus on because of its low hanging fruit and we can see if current tools (crubit, cxx, zngur or whatever) want to help implement the solution to that problem - or if it is some new tool maybe?

13:24

TM
Tyler Mandry
Tyler Mandry says:+1 that overloading is very high-impact for interop and it's relatively easy to make early progress; we have alignment within lang team on the first steps

13:26

J
Josh
Josh says:(enqueuing but I'll wait)

13:28

TM
Tyler Mandry
Tyler Mandry says:*never*

13:29

me says:lol

13:34

J
Josh
Josh says:❤️ for that distinction

13:35

DJ
Devin Jeanpierre
Devin Jeanpierre says:I love the huge stream of hands up after that one

😂

👍

13:36

TC
Taylor (cramertj@)
Taylor (cramertj@) says:well *we* couldn't be the ones to say it 😉

😂

13:36

CH
Connor Horman
Connor Horman says:"concept methods" what is this concept?

13:38

TM
Tyler Mandry
Tyler Mandry says:who's next

13:39

CH
Connor Horman
Connor Horman says:Concepts are just nice syntax (with nice diagnostics) for expression a group of duck typed constraints on template arguments.

👍

13:39

TC
Taylor (cramertj@)
Taylor (cramertj@) says:some of us have just hacked around those

13:39

J
Josh
Josh says:@Connor: Not a "modern C++" expert, haven't used C++ since pre-C++98; just aware that concepts are a thing and vaguely similar to traits, so I thought they might have the equivalent of a dyn.

13:40

DJ
Devin Jeanpierre
Devin Jeanpierre says:They used to be similar to traits, they are now bools. 😦

👍

13:40

me says:I think we sit at a tension between two high-level problems - if we could solve Rust/C++ interop all at the language level effectively making current (competing) external tools obsolete, some might say that is the nirvana state but also the state that could take years, decades, or never to get there given the time it takes to get one language change landed, let alone a bunch. Then the other tension is that we could maybe well solve the most common cases that people will need in tools, but then you have a lot of tools that are effectively doing the same thing and which one wins (if any) (similar to what Niko said)

13:40

CH
Connor Horman
Connor Horman says:Yeah, they're just fancy `constexpr bool`s that get nice diagnostics from the compiler

13:40

J
Josh
Josh says:(Was that the issue of having "Open Source" projects where non-employees can't contribute?)

13:41

Josh says:(re pybind11)

13:41

CH
Connor Horman
Connor Horman says:(Plus nice syntax sugar for std::enable_if_t on those constexpr bools)

13:42

DJ
Devin Jeanpierre
Devin Jeanpierre says:Josh: also zero marketing, difficult toolchain integration, and potentially "weird" googleisms and the like. I do not remember for what reasons PyCLIF failed exactly though

👍

13:42

NM
Niko Matsakis
Niko Matsakis says:(what is "Zengar"?)

13:45

TC
Taylor (cramertj@)
Taylor (cramertj@) says:zngur

13:45

TM
Tyler Mandry
Tyler Mandry says:
https://github.com/HKalbasi/zngur

13:45

me says:
https://github.com/HKalbasi/zngur

13:45

TC
Taylor (cramertj@)
Taylor (cramertj@) says:
https://github.com/HKalbasi/zngur

13:45

T
teor (they/them)
teor (they/them) says:
https://hkalbasi.github.io/zngur/how_it_compares.html

13:45

TC
Taylor (cramertj@)
Taylor (cramertj@) says:Adobe has adopted it (at least to some degree)

13:45

DJ
Devin Jeanpierre
Devin Jeanpierre says:the exact pronunciation is beyond me but someone told me it was pronounced like zengar 😦

👍

😂

13:46

TC
Taylor (cramertj@)
Taylor (cramertj@) says:OVERLOADING

13:47

Taylor (cramertj@) says:Connor: what build systems do you use today for cross-language builds? (Cmake, Bazel, Buck?)

13:48

J
Josh
Josh says:(if I could do *two* things: un-mothballing crABI.)

13:49

CH
Connor Horman
Connor Horman says:Currently autotools + make is my most common because cmake doesn't make doing Rust easy (or sharing deps).

13:49

Connor Horman says:make works the best IME, which is a bad sign IMO.

😂

13:49

J
Josh
Josh says:> Connor Horman says:make works the best IME, which is a bad sign IMO.

Mood.

13:49

NM
Niko Matsakis
Niko Matsakis says:Niko says tractable.

🔥

😮

13:50

Niko Matsakis says:"The only thing we have to fear is fear itself. And lcnr."

🔥

13:52

TC
Taylor (cramertj@)
Taylor (cramertj@) says:RE build systems / getting off the ground: tell me what x-lang build system you use pls

13:53

J
Jack
Jack says:To be fair, my specialization comment was *before* RustNation - now potentially

👍

13:53

J
Josh
Josh says:> Taylor (cramertj@) says:RE build systems / getting off the ground: tell me what x-lang build system you use pls

I love how you optimistically say "system", singular, rather than "systems", plural. 😉

13:54

TC
Taylor (cramertj@)
Taylor (cramertj@) says:I mean, I can't build a plugin for *your* custom python script

13:55

DJ
Devin Jeanpierre
Devin Jeanpierre says:I actually had similar thoughts when you were talking about the C++ standard library

👍

13:55

TC
Taylor (cramertj@)
Taylor (cramertj@) says:but we can make ones for CMake, Buck, Bazel, etc.

13:55

J
Josh
Josh says:I mean if you're building a plugin for my build system you're doing it wrong. 😉

😂

13:55

DJ
Devin Jeanpierre
Devin Jeanpierre says:the really scary thing is one can have two

13:55

TC
Taylor (cramertj@)
Taylor (cramertj@) says:right, lol, which C++ stdlib

13:55

J
Josh
Josh says:Fair enough. "gcc or clang, whichever people have installed when they build my project".

13:55

Josh says:"whatever version they have, because that's not my choice, as an Open Source project maintainer"

13:56

TC
Taylor (cramertj@)
Taylor (cramertj@) says:there are multiple variants of libc++ 😉

😮

13:56

Taylor (cramertj@) says:(or libstd)

13:56

J
Josh
Josh says:I don't get to check my tools into a VCS somewhere, I need to run with *everything* reasonable.

13:56

Josh says:Recognizing a noticeable bifurcation here, between projects that have control over their toolchain and environment, and projects that don't.

13:57

Josh says:The latter partly motivates my "what if we just use trait objects for everything and don't get to care about data layout".

13:58

me says:At some point I would like to ask (maybe not today) who would be interested in an interop discussion at the All-Hands in May. I really think that timeframe would be a good pivot point on potential work here.

👍

13:59

TC
Taylor (cramertj@)
Taylor (cramertj@) says:@joel we had good conversation at the all-hands last year, though at least one critical person (David Sankel) can't make it

14:00

me says:Yes, that would be unfortunate. I am not sure he could even make it even if we offered a virtual option into the room. But we/I could potentially get ideas from David a priori to at least have those.