595 karma · joined May 5, 2018
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.
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.
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.
* 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.
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".
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.
"Compiling regular expressions to sequential machines" (2005) ACM Symposium of Applied Computing https://dl.acm.org/doi/10.1145/1066677.1066992
(Note that there is a small mistake in the paper due to ambiguity, found by Vladimir Gapeyev. So the result does not hold in the generality stated but only for a special case when there is no ambiguity at "the end". There went my first PhD student publication...)
The two pass technique used to be implemented in the Scala compiler at the time (building DFAs upfront) , which could do regexps over lists and other sequences, but the approach would not work for top-down tree regexps so I did not pursue that and it got ripped out later.
It is good to see derivative regular expressions, Brzozowski/"position automata" used and discussed.
MIT plus a condition that designates OpenAI and Anthropic as restricted parties that are not permitted to use or else?
In my experience there is a C++ mob that hates Rust. These are the people who declare statement of facts as ideology. No good faith dialogue is possible.
There are also competent C++ programmers who misunderstand or don't know how static checking works.
I also witness normal people who are completely surprised by a statement like "C++ is all unsafe" and find that too strong. Using the word "safe" with a technical meaning throws normal people off because, sadly, not everyone who writes code is an academic PL researcher.
"Safe", in Rust and much PL research, means "statically checked by the compiler to be free of UB". If you are pedantic, you need to add "... under the assumption that the programmer checked all conditions for the code that is marked `unsafe`" for Rust. That is all there is to it. Scientific definition.
C++ in its current form is full of gross design mistakes, many of which could be corrected at the price of breaking backwards compatibility. Mistakes happen, aldo to world leading PL researcher (the ML language and polymorphic references) which is why the field embraced mechanically checked proofs. The difference is the willingness to address mistakes.
Academics use "safe" in exactly the meaning the Rust community uses. If you don't understand this, go and educate yourself. Academics need to communicate effectively which leads to technical meanings for everyday words or made up words and jargon.
Maybe a statically checked safe low-level language is marketing genius. It is also a technical breakthrough building on decades of academic research, and took a lot of effort.
Bjarne and friends chose a different direction. Safety was not a design goal originally but doubling down on this direction means that C++ is not going to improve. These are all facts.
Backwards compatibility is a constraint. Constraints don't give anyone license to stop people who don't have those constraints.
We don't have to feel any moral obligation to use statically checked languages for programs. But claiming that static checking does not make a difference is ignorant, and attaching value to one's ignorance certainly seems like an indicator for ideology and delusion.
If you are into this type of modelling, you may find value in Mangle, a datalog-based logic programming language and deductive database library. You do not need to invent dozens of DSLs but can do it all in one. And without all the RDF trouble.
https://github.com/google/mangle
HN discussion https://news.ycombinator.com/item?id=33756800
Talk at REBASE 2025 "From Facts to Theories" https://youtu.be/UjOEHSZDBH8?si=qAjnkBQfPKMVaOPW
* Depending on how WASM is used, one gets safety guarantees. For example, memory is not executable.
* Privileges are reduced as a WASM module interacts with the environment through the WASM runtime and the embedder
Now, when one compiles C to WASM one may well compile things with bugs. A memory access bug in C is still a memory access bug, but its consequences can be limited in WASM execution. Whether fail-stop behavior is guaranteed actually depends on the code the C compiler generates and the runtime (allocation/deallocation, concurrency) it sets up.
So when we enumerate immediately available security options and count WASM as sandboxing, this is not wrong. But WASM being an execution environment, one could do a lot of things, including a way of compiling and executing C that panics when a memory access bug is encountered.
There is art and there is science. What both have in common is that their protagonists do not intend to become obstacles of progress.
I'm afraid GC'd languages have been around for a very long time and yet we continue to talk about memory safety as an urgent problem. Now what?
How does pretending that low-level memory safety is not its own complex domain deserving of its own technical definitions help with anything?
I believe everyone who cares about memory safety appreciates that certain bugs cannot occur in Java and go, and if the world calls that memory safe, that is ok.
There are hard, well-defined guarantees that a language and implementation must make, and a space of trade-offs. We need language and recognition for the ability to push the boundary of hard, well-defined guarantees further. That, too, is memory safety and it will be crucial for moving the needle beyond what can be achieved with C and C++.
No one has a problem with applications being ported from low-level to GC-ed languages, the challenge is the ones where this is not possible. We need to talk about memory safety in this specific context, and mitigations and hardening will not solve the entire problem, only pieces of it.
Small nit: As someone curious about a definition of memory safety, I had come across Michael Hicks' post. He does not use the list of errors as definition, and argues that such a definition is lacking rigor and he is right. He says;
> Ideally, the fact that these errors are ruled out by memory safety is a consequence of its definition, rather than the substance of it. What is the idea that unifies these errors?
He then offers a technical definition (model) involving pointers that come with capability of accessing memory (as if carrying the bounds), which seems like one way to be precise about it.
I have come to the conclusion that language safety is about avoiding untrapped errors, also known as "undefined behavior". This is not at all new, it just seems to have been forgotten or was never widely known somehow. If interested, find the argument here https://burakemir.ch/post/memory-safety-the-missing-def/
The context here is formal specs though - adequately and precisely capturing the intended meaning (semantics) in a way that lends itself to formal verification.
Interactive theorem proving is interactive because proof search is intractable; a human articulates the property they want to prove and then performs the "search". Apart from the difficulties of getting to that proof, it can also happen that all goes through and you realize that the property is not exactly what you wanted.
Prove what? The author is well versed in the problem of specifications as the aliens-demand-gcc-correctness-or-else post. I also enjoyed the other post where they say "no one cares about correctness" and "people care about compliance".
It is safe to say, most people are not experts and will never become experts.
Being proficient in the business of coming up with suitable specification that can be implemented and getting assurance that an implementation meets the spec will most likely need all the kind of formal training for humans that the AI hype industry assures us is no longer necessary.
So it doesn't much help that LLMs are good at manipulating the tokens when used by experts, at least not in a big way. It can be hoped that they change cost-benefit balance in good ways, but the bigger problems of the industry will simply persist.
What would need to change for a more fundamental shift is getting a lot more people to understand the value of specifications. This is an education problem and paradoxically I could see AI helping a lot... if only there was enough interest in using AI to help humans become experts.
I have a little post that explains this using a few more words, if interested: https://burakemir.ch/post/memory-safety-the-missing-def/
Typestate is a bit closer: it communicates some property where an operation (typically a method invocation) changes the property and hence the typestate. But there isn't necessarily a mechanism that renders the value in the old typestate inaccessible. When there is, then this indeed requires some linearity/affinity ("consuming the object"), but typestate is something built "on top".
There is a dual nature of linearity and uniqueness, and it only arises when there are expressions that are not linear/not unique. At the same time, they have a lot in common, so we do not have a situation that warrants separate names. It is even possible to combine both in the same type system, as the authors demonstrate.
Taken from the paper:
"Linearity and uniqueness behave dually with respect to composition, but identically with respect to structural rules, i.e., their internal plumbing."