AFAIK this was not a clean room reimplementation. But since it was rewritten by hand, into a different language, with not just a different internal design but a different API, I could easily buy that chardetng doesn't infringe while Python chardet 7 does.
I've worked on a system where ULIDs (not UUIDv7, but similar) were used with a cursor to fetch data in chronological order and then—surprise!—one day records had to be backdated, meaning that either the IDs for those records had to be counterfeited (potentially violating invariants elsewhere) or the fetching had to be made smarter.
You can choose to never make use of that property. But it's tempting.
The current amount of typechecking might be a net efficiency improvement AFAIK. It provides a hard runtime guarantee that variables are certain types while Python has to check whether something is supported at the last possible moment. But I don't know how much use the optimizer makes of that.
Python managed to do this by not actually checking the types at runtime. If you declare a list[int] return type but you return a list[string] then nothing happens, you're expected to prevent that by running an offline typechecker.
PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)
The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.
I don't think this shows deep thought on his part.
By Stallman's own telling a free Objective-C frontend was an unexpected outcome. Until it came up in practice he thought a proprietary compiler frontend would be legal (https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c...). So his stance in this email is a reaction to specific incidents, not careful forethought.
And the harms of permissive licensing for compiler frontends seem pretty underwhelming. After Apple moved to LLVM it largely kept releasing free compiler frontends. (But maybe I'd think differently if I e.g. understood GNAT's licensing better.)
rustc is only loosely tied to LLVM. Other code generation backends exist in various states of production-readiness. There are also two other compilers, mrustc and GCC-rs.
mrustc is a bootstrap Rust compiler that doesn't implement a borrow checker but can compile valid programs, so it's similar to to your proposed subset. Rust minus verification is still a very large and complex language though, just like C++ is large and complex.
A core language that's as simple to implement as C would have to be very different and many people (I suspect most) would like it less than the Rust that exists.
- C# is bytecode-first, Go targets native code. While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it. Go also has somewhat better control over data layout. They wanted to get as low-level as possible while still having garbage collection.
- This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style. This suits Go well while a C# port would have required more restructuring.
One core difference seems to be that references are checked at runtime. In Rust you have to be able to prove that a reference to a value can't outlive the value, but Vale is more trusting, and simply crashes if a reference outlives the value in practice.
You have constraint references, which crash the program if they still exist when the value is freed. And you have weak references, which turn into null. Constraint references can optionally be compiled into raw pointers.
AFAIK this was not a clean room reimplementation. But since it was rewritten by hand, into a different language, with not just a different internal design but a different API, I could easily buy that chardetng doesn't infringe while Python chardet 7 does.