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.
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.
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
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
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
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