My feedback is that both the motivation and the language looks like someone who is confused about several concepts in programming languages.

Safe Rust cannot cause undefined behavior ... static systems do not need to predict all runtime paths, presumably referring to the halting problem and Rice's theorem (or whatever the author intends this to mean, the writing is unclear): these systems prove properties for all accepted programs under a conservative model, which covers all allowed programs within the subset admitted by the model.

The guarantee that Rust provides are sound, and the claim depends on trust in compiler implementation and any `unsafe` code involved in used APIs, etc (which is not uncommon: the same thing is true for Lean's kernel, for instance).

As Pauli said, much of the writing is not even wrong ... many of the language critiques read like transcriptions of vibes derived from AI discussion: "C++ smart pointers with extra steps" -- this is not a serious statement. I'm not even a serious user of Rust, but I know enough about the language design to understand how stupid this statement is.

So the goal seems to be: Java, but without nulls, erased generics, OOP, or the JVM.

Best of luck.

Is there a story behind the hash-like Github username [1], email address [2], and HN usernames [3]?

[1] https://github.com/3WyUFvDOdCbBw7gOZHwcfgKF

[2] IZ1zPtHyDX5b3s7iLYS2zRoz5 @ proton.me

[3] https://news.ycombinator.com/user?id=bOZbfU4YdRnJQ

I'm not sure most systems programmers would agree that a language with GC is suitable for their work.

"No syntactic sugar" and "no macros" sounds like a recipe for boilerplate that will be offputting for many.

Please consider adding some code samples to the front page of documentation, as syntax can be important to people.

I disagree with some other details, but I do think that a low level GC language that doesn't have some of Go's particular warts (particularly nil and error checking) is worth pursuing.

Writing the initial compiler in Typescript is an interesting choice but I suppose that won't matter after it's bootstrapped.

Ultimately it's hard for me to take the project seriously at such an early stage but I don't think it's fundamentally flawed. Good luck

Vouched. This looks like an interesting project noteworthy enough for HN.

Now that are some scary looking file names :D https://github.com/3WyUFvDOdCbBw7gOZHwcfgKF/ironwall/tree/ma...

Also first confused the name with Ironwail, the Quake 1 source port

I feel like your charactization of Rust is based on a misunderstanding. Safe Rust does not rely on predicting every future execution path, nor on understanding all runtime states. Safe Rust relies on making it provably impossible to take an execution path or reach a runtime state that is unsafe. This is a completely, entirely distinct approach and is not anything like existing static analyses e.g. of C. In fact that very drawback of being "forced to change otherwise natural data structures and API designs" is exactly for when you cannot sufficiently prove they are Safe Rust.

Since you are not a fan of that, of course Rust may not be for you. But to pose it as an issue of unattainable static analysis is incorrect. Safe Rust achieves the analyses it does because it simply does not have constructs that require knowing every execution path or every runtime state. Its safety does not depend on that. You can choose to depend on it in Unsafe Rust, but then the soundness of that will depend on you, the programmer, rather than on the language.