burakemir

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.

See also my other comment.

Congrats to the folks involved!

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.

Looks like Addy Osmani is leaving, too.

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.

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.

Say you have a Car, Engine and Dashboard object.

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".

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?

This article is full of gross mistakes. For example it claims that Caml is "Cambridge ML" which is ridiculously false. Fact check every sentence. Really sad.

You could build something like this using Mangle datalog. The go implementation supports extension predicates that you can use for "federated querying", with filter pushdown. Or you could model your dependency graph and then query the paths and do something custom.

You could also build a fancier federated querying system that combines the two, taking a Mangle query and the analyzing and rewriting it. For that you're on your own though - I prefer developers hand-crafting something that fits their needs to a big convoluted framework that tries to be all things to all people.

Looks mildly interesting, but what's up with the license?

MIT plus a condition that designates OpenAI and Anthropic as restricted parties that are not permitted to use or else?