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/