Posted by gplane 1/15/2026
In fairness, I don’t think we predicted just how large L1/L2 caches would get over the coming years.
Why isn’t there already some parser generator with vector instructions, pgo, low stack usage. Just endless rewrites of recursive descent with caching optimizations sprinkled when needed.
1. Consuming tokens.
2. Recognizing the grammar.
3. Producing AST nodes.
Steps 1 and 3 are heavily dependent on the data types that make the most sense for the previous (lexing) and next (semantic analysis) phases of the compiler. There is no one Token type that works for every language, nor one AST type.
The recognizing the grammar part is relatively easy, but since so much of the code is consuming and producing datatypes that are unique to a given implementation, it's hard to have very high performance reusable libraries.
chumsky (parser combinator): https://github.com/zesterer/chumsky
LALRPOP (LR(1)): https://github.com/lalrpop/lalrpop
grmtools (YACC) https://github.com/softdevteam/grmtools/ re: Other parsers: https://softdevteam.github.io/grmtools/master/book/othertool...
antlr4rust: https://github.com/rrevenantt/antlr4rust
Isnt it more about the grammar than the prog lang?
I don't know if this does semantic analysis of the program as well.
Maintainer of Winnow here. I wish there were more details on this. I switched `toml` / `toml_edit` to being hand written and got some performance boost but I feel like the other things listed would have dwarfed the gains that I got. I wonder if there were sub optimal patterns they employeed that we could find ways to help better guide people.
For anyone going on about "hand written is always better", I disagree. Parser combinators offer a great way to map things back to grammar definitions which makes them much easier to maintainer. Only in extreme circumstances of features and/or performance does it seem worth going hand-written to me.
Just about nobody uses WebAssembly. It first appeared almost ten years ago. This is snail-speed evolution at best.
In its current scope, WASM is a way to port existing code or accelerate certain computations, which only some applications need. Most websites don't need it, like how most sites don't need to use webcam capture; that doesn't mean it's not useful for those that do
And yes wasm is used wildly. On the web for expensive computation (Google earth, figma, autocad, unity games) or server side for portability and sandboxing (Cloudflare workers, fastly, …)
The whole "it's not meant to replace JS" thing was just to reduce pushback from JS devs.
It was born at the same time as webgl, at the time of Jit optimisation for js engines. As a subset of js first, then as wasm as we know it. It was originally for games and performance on the web.
At no point there was a conversation about "replacing js", but more like, "js can't do these stuff. let's have something else".
There absolutely was. This famous talk was made even when it was still Asm.js:
https://www.destroyallsoftware.com/talks/the-birth-and-death...
All I can tell you with certainty is that the people who designed and funded webgl/asmjs/llvm efforts at Mozilla (Alon, Vlad, Brendan, …) clearly understood that wasm was a needed companion alongside JS (and its DOM&co bindings). Not a replacement. I was part of these conversations.
I understand why people would think it was a JS killer, but that's a naive way of looking at it.
Yes, tons. Obviously not all, but large parts of these are WASM: https://itch.io/games/platform-web
Tools like Figma are only performant because of WASM.
1. creating plugins that get executed in the browser to render files like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, GIS related files and many more, where C libraries are almost always the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM
2. creating plugins that get executed in the server to generate your own endpoint or middleware while being sure you can't start exfiltrating data (which can be other people's files, and other sensitive stuff)
3. in the workflow engine to enable people to run their own sandboxed scripts without giving those a blank check to go crazy
From what I can tell WASM is mostly being used to run big libraries from other languages in web apps. That's not a particularly common thing to need, so it's not commonly used. That doesn't mean it's moving too slowly.
there is also games, stuff to do with video (ffmpeg built for wasm), ml applications (mlc), in fact it's currently impossible to use wasm w/o js to load the wasm binary
as a result, the web stack is a bit upside down now, w/o the seemingly "low level" and "high performance" parts over the slow bits (javascript)