It's a shame though, that Wirth's philosophy was, imv, ditched from 90s-00s (where we get: python, js, ruby, ...scala).
It seems now language design is rediscovering Wirth and his techniques (see, eg., google's carbon which iirc, seeks to be ast-free single-pass).
Multiple passes allows you to break down the problem into separate orthogonal components. To support the same functionality in a single pass, you have to jam an enormous amount of functionality into one place which can make it very difficult to see the forest of the trees as well as introduce unintended coupling. It also is difficult to implement certain recursive features in a single pass (though this could be considered an advantage depending on how powerful you intend the language to be).
Ideally, a compiler can also provide apis that will expose the ast at different phases. It is somewhat sad to me that tree-sitter has emerged as an LCD solution for syntax highlighting and semantic analysis. If a compiler could export e.g. a json representation of the ast after parsing, that could be used for syntax highlighting rather than tree-sitter.
It makes sense - tree-sitter is in large part a reimplementation of many, many parsers, and supporting a new language means duplicating yet another parser. The tree-sitter grammars are doomed by nature to forever chase the latest features in any evolving language, and reaching full compatibility turns out to be a ton of effort in many cases.
That said, language design being the freewheeling "if you can dream it, you can make it" thing it is, though, I doubt it's realistic to expect every language to have a fully-reusable, standardized parser - people just won't ever be that consistent, IMO.
Those who want consistency will need to provide it themselves, in the form of tools like tree-sitter.
Or in the form of radical simplicity. For the purpose of the parents discussion Lisp is the ultimate minimal language. Since, the syntax is its own AST. Other aspects of most Lisp are certainly not so simple.
I haven't used Swift, but hear it may be a bit of a compromise in that it compiles (albeit not in a single pass I don't think) and using it is not that much more verbose than Python. I know Nim and Crystal are similar attempts, but Nim doesn't seem as easy to use to me.
Then I think you can do it. The compile-time is "a Wirth" and the runtime is "a Wirth".
You get 95% the benefits of a python, since 95% of the dynamics you want are actually just static transformations of the program.
for python-style apps, theyre all die quickly
Hm... Can you elaborate why? For me, Nim is the easiest language to work with. It really feels like Python with static typing.
This one is probably a hot take, but I believe that static typing is vastly superior and easier to think about than dynamic typing. In languages like Python or JS, Lua, etc. it's not like they don't have types, types are merely hidden, you still should be aware of types. They just move responsibilty for handling type errors from compiler to the programmer.
Or maybe because Nim is extensible? I know that big point of Nim is macros, and macros in general are hard. But in my experience I've never felt that I need to write one, when using Nim.
Carbon’s (mostly hypothetical) frontend is actually 3 passes: lexing, parsing, and a semantic analysis pass, each with separate IRs. One of their arguments is actually that they are more efficient as separate passes operating on packed data structures rather than e.g. a parser that calls into a lexer for each individual token. In a way, this is a claim that Wirth’s approach is inherently inefficient on contemporary CPU microarchitectures.
So you have linear scans on top of linear scans.