Contrasted with python, which is interpreted, has a clunky runtime, minimal optimizations, and all sorts of choices that result in slow, redundant, and also slow, performance.
The price for performance is safety checks, redundancy, how badly wrong things can go, and so on.
A good compromise is luajit - you get some of the same aggressive optimizations, but in an interpreted language, with better-than-c performance but interpreted language convenience, access to low level things that can explode just as spectacularly as with zig or c, but also a beautiful language.
It may be easier to write code that runs faster in Zig than in C under similar build optimization levels, because writing high performance C code looks a lot like writing idiomatic Zig code. The Zig standard library offers a lot of structures like hash maps, SIMD primitives, and allocators with different performance characteristics to better fit a given use-case. C application code often skips on these things simply because it is a lot more friction to do in C than in Zig.
Don't disagree but in specific case, per the author, project was made via Claude Code. Although could as well be that Zig is better as LLM target. Noticed many new vibe projects decide to use Zig as target.
the licensing is a huge blocker for using mupdf in non-OSS tools, so it's very nice to see this is MIT
python bindings would be good too
also, added python bindings.
as others have commented, I think while this is a nice portfolio piece, I would worry about its longevity as a vibe coded project
- commit message: LLM-generated.
- README: LLM-generated.
I'm not convinced that projects vibe coded over the evening deserve the HN front page…
Edit: and of course the author's blog is also full of AI slop…
2026 hasn't even started I already hate it.
If it's really better than what we had before, what does it matter how it was made? It's literally hacked together with the tools of the day (LLMs) isn't that the very hacker ethos? Patching stuff together that works in a new and useful way.
5x speed improvements on pdf text extraction might be great for some applications I'm not aware of, I wouldn't just dismiss it out of hand because the author used $robot to write the code.
Presumably the thought to make the thing in the first place and decide what features to add and not add was more important than how the code is generated?
74910,74912c187768,187779
< [Example 1: If you want to use the code conversion facetcodecvt_utf8to output tocouta UTF-8 multibyte sequence
< corresponding to a wide string, but you don't want to alter the locale forcout, you can write something like:\237 D.27.21954
\251ISO/IECN4950wstring_convert<std::codecvt_utf8<wchar_t>> myconv;
< std::string mbstring = myconv.to_bytes\050L"Hello\134n"\051;
---
>
> [Example 1: If you want to use the code conversion facet codecvt_utf8 to output to cout a UTF-8 multibyte sequence
> corresponding to a wide string, but you don’t want to alter the locale for cout, you can write something like:
>
> § D.27.2
> 1954
>
> © ISO/IEC
> N4950
>
> wstring_convert<std::codecvt_utf8<wchar_t>> myconv;
> std::string mbstring = myconv.to_bytes(L"Hello\n");
Is indeed faster but output is messier. And doesn't handle Unicode in contrast to mutool that does. (Probably also explains the big speed boost.)
lulzx•3h ago
~41K pages/sec peak throughput.
Key choices: memory-mapped I/O, SIMD string search, parallel page extraction, streaming output. Handles CID fonts, incremental updates, all common compression filters.
~5,000 lines, no dependencies, compiles in <2s.
Why it's fast:
What it handles:tveita•1h ago
From https://github.com/Lulzx/zpdf/blob/main/src/main.zig it looks like the help text cites an unimplemented "-j" option to enable multiple threads.
There is a "--parallel" option, but that is only implemented for the "bench" command.
lulzx•1h ago
I haven't tested without SIMD.
cheshire_cat•1h ago
Are you using LLMs for parts of the coding?
What's your work flow when approaching a new project like this?
littlestymaar•1h ago
I can't talk about the code, but the readme and commit messages are most likely LLM-generated.
And when you take into account that the first commit happened just three hours ago, it feels like the entire project has been vibe coded.
Neywiny•47m ago
littlestymaar•27m ago
Neywiny•15m ago
2. Be not good at or a fan of git when committing
Not sure what the disconnect is.
Now if it were vibecoded, I wouldn't be surprised. But benefit of the doubt
lulzx•1h ago
jeffbee•1h ago
jonstewart•44m ago
lulzx•32m ago