21–30 of 88 posts
I built a PDF text extraction library in Zig that's significantly faster than MuPDF for text extraction workloads. ~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 Why it's fast: - Memory-mapped file I/O (no read syscalls) - Z…
Now we just need Python bindings so I can use it in my trash language of choice.
added python bindings!
I built a PDF text extraction library in Zig that's significantly faster than MuPDF for text extraction workloads. ~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 Why it's fast: - Memory-mapped file I/O (no read syscalls) - Z…
What’s the fidelity like compared to tika?
excellent stuff what makes zig so fast
Not being slow - they compile straight to bytecode, they aren't interpreted, and have aggressive, opinionated optimizations baked in by default, so it's even faster than compiled c (under default conditions.) 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…
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.
Earlier quoted context omitted.
> Are you using LLMs for parts of the coding? 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.
Hard disagree. Initial commit was 6k LOC. Author could've spent years before committing. Ill advised but not impossible.
74910,74912c187768,187779
> myconv;
> [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> myconv;
> std::string mbstring = myconv.to_bytes(L"Hello\n");
Earlier quoted context omitted.
Hard disagree. Initial commit was 6k LOC. Author could've spent years before committing. Ill advised but not impossible.
Why would you make Claude write your commit message for a commit you've spent years working on though?
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
- First commit 3hours ago. - 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.
excellent stuff what makes zig so fast
It makes your development workflow smooth enough that you have the time and energy to do stuff like all the bullet points listed in https://news.ycombinator.com/item?id=46437289
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.
74910,74912c187768,187779 > myconv; > [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 > myconv; > std::string mbstring = myconv.to_bytes(L"Hello\n"); Is indeed faster but output…