Polybdenum

Fabrice, if you're reading this, please consider replacing Rust instead with your own memory safe language. The design intent of Rust is a powerful idea, and Rust is the best of its class, but the language itself is under-specified[1] which prevents basic, provably-correct optimizations[0]. At a technical level, Rust could be amended to address these problems, but at a social level, there are now too many people who can block the change, and there's a growing body of backwards compatibility to preserve. This leads reasonable people to give up on Rust and use something else[0], which compounds situations like [2] where projects that need it drop it because it's hard to find people to work on it. Having written low-level high-performance programs, Fabrice Bellard has the experience to write a memory safe language that allows hardware control. And he has the faculties to assess design changes without tying them up in committee. I covet his attentions in this space. [0]: https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-ru… [1]: https://blog.polybdenum.com/2024/06/07/the-inconceivable-types-of-rust… [2]: https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

this article has several examples: https://blog.polybdenum.com/2021/08/09/when-zero-cost-abstractions-are…

While it's not a study, https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing… gives a real-world example of a bug in Go Rust would have prevented. Also, bear in mind that it's not just Rust's type system directly that prevents bugs, but also the patterns it enables. For example, the typestate pattern and its use in things like turning misuse of the HTTP protocol into a compile-time error in Hyper. https://cliffle.com/blog/rust-typestate/

Not just C, any language with mutable aliases references/pointers, which is pretty much every modern language. https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing…

Is Rust really "fearless concurrency" ? Considering the number of deadlock issues encountered by folks using async Rust, I think "fearless concurrency" is misinformation by Rust evangelists. Deadlocks in production Rust microservice: https://blog.polybdenum.com/2022/07/24/fixing-the-next-thousand-deadlo…

One interesting aspect is that if the language has any sort of implict type conversions/coercions, then type annotation can change program behavior in possibly surprising ways. For example https://blog.polybdenum.com/2022/04/25/when-type-annotations-are-code-…

Rust only supports & and &mut references. This was a deliberate choice early in the development of the language. &own, &pin, and &uninit are proposals for additional pointer types. They don't actually exist in the type system right now, but other parts of the compiler do have to care about them. Another blog post that floated around here about a month ago called these "inconceivable types"[0]; adding them to the type system would allow formally extending these behaviors across function boundaries. Like, right now, implementers of Drop can't actually move anything out of the value that's about to be destroyed. The Drop trait gets a &mut, but what we really want is to say "destroy this value over there". Rust's type system cannot understand that you own the value but not the place it lives in. What you need is an "owned reference" - i.e. &own, where the borrow checker knows that you can safely move out of it because it's going to get destroyed anyway. Rust also can't support constructors, for the same reason. What we really have are factory functions: you call them, they return a value, you put it somewhere. This is good enough that Rust users just treat factory functions as if they were constructors, but we can't do "placement new" type construction with them, or partial initialization. At least not in a way the type system can actually check. &pin is a first-class version of Pin<T>. Rust was originally designed under the assumption that any type can be memcpy'd at any…

I used to use Rust for work, and I use Zig in my new job. They're both fine. It was a good-faith smattering of examples, and it's pretty easy to keep pulling such examples out of a hat. You seem to not like any of them much, so I'll just briefly address a few of your points: > Of course it’s not any less safe than any other language that exposes atomics so it’s weird to imply this as something uniquely negative to Rust That wasn't the implication. Off-the-cuff, when you ask your average rustacean what they think "no data races in safe Rust" means, do you honestly think they will tend to write code treating atomics with an appropriate level of respect as they would in another language? > Actually most memory safe languages don’t have issues expressing data structures (eg Java) That was sloppy writing on my part. I left the implicit "without runtime overhead" in my head instead of writing it down. > Memory leaks This first one isn't a leak per se, but it's about the same from an end-user perspective [0]. Here's a fun example of that language complexity I was talking about (async not being very composable with everything else) as an example of a true leak [1]. Actix was still only probably/mostly leak-free starting from v3 [2]. Rust makes it easy to avoid UAF errors, but the coding patterns it promotes to make that happen, especially when trying to write fast, predictably performant data structures, strongly encourage the formation of leaks -- can't have a UAF if you…

I came across this post [1] in which the author discovers an undocumented feature in the JVM. "Although the first stable release of Java used bytecode version 45.3, the JVM will actually accept classfiles with versions starting at 45.0. Furthermore, there’s an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2. In a normal classfile, the stack, locals, and code length fields of the Code attribute have lengths of 2, 2, and 4 bytes respectively, but in a pre-45.3 classfile, the JVM expects them to be 1, 1, and 2 bytes instead. Normally, this means that a pre-45.3 classfile produced by ASM will just crash when run on the JVM because the JVM encounters garbage data while parsing and rejects it. However, if you are very careful, it is possible to construct a classfile that is valid when parsed with the 2,2,4 widths, and also valid when parsed with 1,1,2, but parses as different code in each case. This means that it is possible to craft a classfile that executes one piece of code when run on the actual JVM and displays a completely different set of fake code when viewed with reverse engineering tools" TL;DR JVM contained an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2. The stack, locals, and code length typically has 2,2,4 bytes rspectively; in pre-45.3 classfiles, the JVM expects them to be 1,1,2 bytes instead. [1]…