- Author
- Posted by g0xA52A2A, with replies from many commenters
- Published
- 5 April 2026
- Kind
- Hacker News discussion thread of about 56 comments
- Original
- news.ycombinator.com/item?id=47650312
- Subject
- Compilers and interpreters
- Themes
- Close to the machine
What it is
g0xA52A2A posted the link to Matt Keeter's blog post and drew 194 points. Commenters discuss tail calls, bytecode interpreters and Rust language design. The article itself was not fetched for this record.
What it says
- Mananaysiempre says serialization formats keep rediscovering bytecode interpreters. Examples named are Microsoft, Protocol Buffers and Swift.
- Gavinray doubts that an interpreter can outperform direct code. After a search, Gavinray cites instruction cache efficiency and branch prediction as the reason.
- Tialaramex says become promises a tail call works or the code will not compile.
- A debate asks why become is a keyword. One answer is that the need belongs to the caller.
- Commenters argue over whether the post's interpreter is tail-call optimized or simply requires tail calls.
- Anematode reports slower tail-call dispatch on WebAssembly in V8 and JSC, not SpiderMonkey.
- Aw1621107 quotes the current RFC as barring become inside async functions.
What evidence it gives
The thread offers opinions, anecdotes and links to RFCs, blogs and code. Anematode describes tests on WebAssembly engines. No benchmarks are run in the thread itself.
Interests and limits
Commenters are self-selected and their claims are unchecked. Claims about the linked post are secondhand, because that post was not read. Rust's tail-call support was still nightly-only when the thread ran. Later changes are not covered.