It would be possible for me to give a more nuanced take, but the upshot is: none of that shit is going to work 100%.
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
Oh, I 100% agree. The question is how much you can reduce the effort of the port/migration, and in particular the validation effort.
I've worked on projects where the core bits of code were "90%" converted by some automated tool, and in my view the overall benefit to the project timeline was probably only 20-30% because of the Amdahl's-law-type overheads of validation and bits of code not supported by the automation/conversion process. Nice, but no silver bullet.
Non-idiomatic porting also isn't super-helpful if the resulting code isn't maintainable.
As I pointed out in a sibling comment, the plan isn't for it to work. This is a job posting for a researcher at MSR to investigate what it might look like someday.
Having previously led Rust at Google, I remember several great cross-company discussions with Microsoft engineers on interop.
Companies with massive C++ codebases use Rust as a pragmatic hedge. C++ as we know it is unlikely to ever become fully memory safe, and unlike C++ standard committee voices who dispute the urgency, major industry players need actionable solutions today.
Because these existing codebases are so vast, Rust must have a viable C++ interop story. However, defining what "good interop" means remains tricky. C++ routinely tolerates aliasing and relies on patterns that violate Rust's aliasing rules. Shared backend infrastructure (like connecting rustc directly to MSVC backends) helps with ABI layout, cross-language inlining, and toolchain parity, but it doesn't solve the core type system divergence.
The fundamental obstacle is type systems:
* Boundaries remain unsafe: Compilers cannot statically verify C++ safety invariants. Crossing the boundary stays in unsafe territory.
* Idiomatic C++ structures often cannot map cleanly into Rust idioms. This forces developers into onerous safety comments or heavy wrapper layers. At some point, application writers will consider serialization / in-process RPC or a full rewrite as a cheaper or cleaner option of getting interop.
Bridging this gap on the ABI level is pragmatic, but pushing Rust's semantics to accommodate C++ edge cases risks compromising "pure Rust" goals. I doubt the broader Rust community will favor complicating Rust's safety model just to smooth over legacy C++ patterns.
To be clear: practical interop is a worthwhile investment, but "seamless interop" needs serious qualification. It will always have hard limits. There will always be friction at the boundary and it will always be a tough sell.
The implementations are not high performance, but if you can fit everything in memory or you can organize your data and integrate it through external queries, you should get something workable for a lot of use cases.
I did not set out to replace SQL, and while I don't mind adoption, that is not why I am sharing it here. The open sourcing was motivated by making datalog more widely known. I did some research and found out that I needed a datalog implementation with particular characteristics, I for sure knew I didn't want to use SQL for what I needed.
There are structured types and recursion and being able to name predicates and compose queries... Mangle has some users and there is a few application that take advantage of the queries-as-logic-programming approach.
I think an insight one can draw in this discussion that a query language and the system (DBMS implementation) that it is part of can hardly be separated when it comes to the inevitable performance requirements one has.
That's a pretty cool pair of repos. I've been working on a C++ Datalog myself [0] for embedded queries over in-memory datasets. It's been surprisingly useful for a bunch of different usecases (e.g. build graphs). My implementation is faster than Souffle on all the benchmarks I've tried, but apparently I still have some work to do optimizing startup time on small graphs.
I wanted to try it but it seems it requires krun which does not have a readily-available package on ubuntu that I could find, and I didn't feel like compiling it.
Since nobody mentioned it, there was a lovely children's book called the clanker. It was about some creature that made metallic noises unlike the other creatures. The moral of the story was one of diversity and inclusion, making space for differences.
My aversion with the word is that I don't want to be reminded of that clanker creature, which had feelings it wanted to express. The weights don't have feelings.
My worry is rather that people coming up with ideology that ascribes "consciousness" and "offense" may wind up with the next generations of models picking that shit up and playing offended. Well done!
The misguided discussion of "clanker" being "highly derogatory" really shows that anthropomorphization has its limit as far as analogies go.
What we need is a new made up word with a clean etymology.
For such a word to gain traction, we need it to be promoted by someone with clout in the AI space. I don't know if Karpathy has used up his quota of invention of AI nomenclature.
The Simpsons made up "cromulent" with their own definition. Anyone can make up a word with their own definition. Getting it to catch on is the hard part (obligatory "stop trying to make fetch happen" reference).
Take this with a grain of salt as I am new to this but IMHO for establishing memory hierarchy once and for all, it would be more helpful to present some abstract theory that
* Explains prefill (time to first token TTFT) vs decode (time between tokens TBT aka 1/tps)
* The various ways to schedule the computation, and the roles of runtime vs driver
* The scenarios and choices, taking into account traffic patterns, whether you are an inference service or doing batch or claw whatnot.
Yeah, passing by value or "Value semantics" can prevent many programming errors. Passing references to immutable data can serve a similar purpose. In low-level languages where memory layout and calling convention map to target hardware, there are differences in performance to consider.
Pass by value would indeed make a big difference to how programs are structured and make it easier to reason about programs.
I just want to point out that "concurrency safety" is very much a word, although "thread safety" is more common. These are broadly part of memory safety, which is a topic mainly due to security concerns but also academic study.
The two perspectives are not perfectly congruent. Non-concurrency-safe languages like go can also be considered broadly memory safe. The pragmatic rationale is that data races in GCed languages are much less exploitable. From a academic, principle based view this is unsatisfying and unconvincing as one would prefer safety to be matter of semantics. See also https://www.ralfj.de/blog/2025/07/24/memory-safety.html
Rust uses "fearless concurrency" as a slogan. Rust offers more options than passing by value (Copy) while still guaranteeing safety through static type checking.
There is also research for GCed languages to establish non-interference eg Scala capture checking.
Concurrency is recognized as difficult (at least by people who are knowledgable) and programs language design usually involves pragmatic choices if you need concurrency. If the language does not provide the primitives or spec that enables safety, then you are left with patterns and architecture.
The science is still evolving, it is certainly not the case that nobody cares. Rather, progress is slow and moving ideas from research industry is even slower. How much value we ascribe to correctness, safety and performance in industry depends very much on the context.
Let's not have dashboard access the temperature by doing `GetSurroundingCar().engine.temperature`
If the dashboard needs to get the temperature from a sensor in the engine, it should be able to "talk" to the sensor, without going through car object.
In ideal OOP, a "method call o.m(...)" is considered a message m being sent to o.
In practice, field access, value and "data objects" etc are useful. OOP purism isn't necessarily helping if taken to the extreme.
The pure OOP idea emphasizes that the structure of a program (how things are composed) should be based on interactions between "units of behavior".
> Say you have a Car, Engine and Dashboard object.
Then you should burn the whole thing down and start over!
I work on tractors not, cars, but I'm sure the abstractions are similar. Our engine objects are things like [service]AutomationEngine. Our dashboards objects are for a collection of things on secondary displays - meanwhile the thing you would point with your finger as the actual dashboard doesn't have or need a dashboard object. There is an object for things like RPM gauge, or check engine light - this later is a generic fault indicator with a icon field; it is connected to a different messages; and placed in different positions depending on the fault.
The point of the above isn't how tractors are designed, it is how the objects you need to design a real OO system rarely have anything to do with that looks like objects. Nobody ever writes dog and cat objects derived from animal; nobody ever writes triangle objects derived from shape.
I had to learn OOP with common lisp (CLOS) and smalltalk to understand this. Now, I’m leaning towards C, because it’s easier to model a problem with struct and function and not have to deal with the flavor of OOP that some languages foster.
A proof object in dependent type theory is just the term that inhabits a type. So are you saying the Lean implementation can construct proofs without constructing such a term?
No, I'm saying it is checked and then discarded. (Or at least, discarded by the kernel. Presumably it ends up somewhere in the frontend's tactic cache.) That matches perfectly the metaphor, "rubs out earlier parts of proofs to make space for later ones".
The shared misconception seems to be in believing that because _conceptually_ the theory implemented by Lean builds up a massive proof term, that _operationally_ the Lean kernel must also be doing that. This does not follow. (Even the concept is not quite right since Lean4 is not perfectly referentially transparent in the presence of quotients.)
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
See also my other comment.
reply