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.
I only spot-checked the section "Problems with Scheme" in the motivation doc and got a similar impression. The last three short paragraphs were reasonable on why not Scheme for this, but they were preceded by a greater bulk of confused or vague complaints. (E.g. "nil being mixed with '()" -- what nil?)
> like transcriptions of vibes derived from AI discussion
I was wondering whether a human wrote it too.
Quite possible this section was unrepresentative! I hope so.
ETA: Turns out ryanmerket is associated with runtimewire.com, and is likely posting this as self promotion.
Please verify your sources; the linked article is unfiltered LLM output. I assume whatever model hallucinated this has confused one person[0] with another[1] because they share the same name, but there is otherwise no indication that they're the same person.
no model. that was me. i should have confirmed they were the same before posting. when i assumed they were the same, the real Wei's credentials made the language much more exciting. apologies. i'll do better next time.
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
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.
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.
I only spot-checked the section "Problems with Scheme" in the motivation doc and got a similar impression. The last three short paragraphs were reasonable on why not Scheme for this, but they were preceded by a greater bulk of confused or vague complaints. (E.g. "nil being mixed with '()" -- what nil?)
> like transcriptions of vibes derived from AI discussion
I was wondering whether a human wrote it too.
Quite possible this section was unrepresentative! I hope so.
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
Besides, the commit history[0] also looks very special:
- 1a0a9b3e9831d9bdbc9d8eba601aa2fa5e9d2708: 4
- 277d6c85c8fd27581c245940e91a40ad2a9114da: may26-3
- 2d2e56ab6228b4814b4a0bc06864e46a68bb40ea: may26-2
...
- d5c117af131c6140f08325882f6b368d91ab6ae8: May 20 2026 - 1
- 715d5250e4bb65cecc7a5c4aa082fc95b717c449 (root): ironwall compiler
[0]: https://github.com/3WyUFvDOdCbBw7gOZHwcfgKF/ironwall/commits...
deleted until identitly confirmed
ETA: Turns out ryanmerket is associated with runtimewire.com, and is likely posting this as self promotion.
Please verify your sources; the linked article is unfiltered LLM output. I assume whatever model hallucinated this has confused one person[0] with another[1] because they share the same name, but there is otherwise no indication that they're the same person.
[0]: https://scholar.google.com/citations?user=eWow24EAAAAJ&hl=en
[1]: https://ironwall-lang.dev/en/about
no model. that was me. i should have confirmed they were the same before posting. when i assumed they were the same, the real Wei's credentials made the language much more exciting. apologies. i'll do better next time.
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.
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.
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