Yes, that was my initial reaction to this post. I like the framing a lot, and the references to copy-and-patch, Umbra, and so forth are great. But my suspicio

Yes, that was my initial reaction to this post. I like the framing a lot, and the references to copy-and-patch, Umbra, and so forth are great. But my suspicion is that rather than trying to make the hard tradeoff, it may be less effort to implement the slow simple interpreter (I actually like tree interpreters), and also the compiler which can take a long time. I'm doing a similar experiment right now, as sort of an offshoot of https://www.oilshell.org/ https://www.oilshell.org/ I don't know how easy it is to develop the interpreter and compiler in lock step, but I think it's worth exploring. I think you can probably reduce the effort with simple code organization, and by making the interpreter slower to run, and the compiler slower to compile. It's indeed very easy to design a language with an interpreter, and then find out it can't be compiled to fast code. So IMO it's worth some design up front to avoid that fate. --- I also think OCaml (mentioned in the post) proves the strategy: they had a bytecode compiler first, then a native compiler. (Though TBH I don't know how it plays out in practice for users) And WASM also proves it -- there are multiple implementations of the same spec with different tradeoffs. I think it's almost more of a UX / DX issue of how to put these things together. I noticed node.js starts too slowly for my taste, but deno starts faster? $ time nodejs -e 'console.log("hi");' hi real 0m0.111s $ deno run hi.ts hi real 0m0.030s I guess node.js is doing a bunch of stuff that isn't v8 starting up? But I guess this doesn't prove the point, because deno still has the unpredictable v8 code generator. (Related comment on "failure of JITs" for certain problems: https://news.ycombinator.com/item?id=35045520 https://news.ycombinator.com/item?id=35045520 )