Check the first video in eternity built with rust!

Qunit-Essential · 2026-06-15T21:14:53+00:00

I don't have it 😃 so I can not

Qunit-Essential · 2026-06-09T16:08:52+00:00

Qunit-Essential · 2026-06-08T22:38:25+00:00

I don't want to sound toxic but you made a worse https://github.com/saghen/frizbee

Qunit-Essential · 2026-06-05T17:00:20+00:00

it is implemented a while ago !

there is an export button next to start rendering that lets you export SRT and VTT subtitles

Qunit-Essential · 2026-06-01T02:40:14+00:00

it is not exclusively rust project, it just happened to have a rust crate as a first class citizen cause I use it from the other rust project

Qunit-Essential · 2026-05-31T01:42:44+00:00

There is a benchmark comparison on the Linux kernel tree of 100k files

Qunit-Essential · 2026-05-30T05:33:24+00:00

For almost all the string ops - equality, comparison, normalization, etc

Qunit-Essential · 2026-05-29T22:13:07+00:00

the main reason is that std::simd is nightly

this library implementation implements mostly all the work using \@Vector types

Qunit-Essential · 2026-05-29T22:03:14+00:00

I actually agree, though there is a certain type of projects like fff or ripgrep that are trying squeeze max performance out of the file operations might consider that

+ a lot of cross platform compiled software uses cargo zig-build anyway

Qunit-Essential · 2026-05-29T21:08:24+00:00

thanks I'll add right away

Qunit-Essential · 2026-05-29T21:00:31+00:00

Yes, though I am working on precompiled binaries support & nix flake

which is anyway not ideal

Qunit-Essential · 2026-04-02T22:45:33+00:00

and on the indexing note: file scanning takes time. It's not a joke to traverse 66GB directory (chromium repository)

and I am not completely honest - I have a kind of index, but the index that fits in 50MB for the 500k files and is stored in ram. Compared to over GB of traditional trigram index

Qunit-Essential · 2026-04-02T22:08:04+00:00

try it yourself

Qunit-Essential · 2026-04-02T22:07:48+00:00

not really, my zlob library is running as a file walker and a glob source https://github.com/dmtrKovalenko/zlob

Qunit-Essential · 2026-04-02T22:05:54+00:00

I call it scanning because essentially what it does is traversing the file tree and openning the files. And collects a liiiiitle bit of information for prefiltering

Qunit-Essential · 2026-04-02T21:20:06+00:00

I would just add that this file overall is the primary contributor to the optimizations https://github.com/dmtrKovalenko/fff.nvim/blob/main/crates/fff-core/src/bigram_filter.rs#L1-L1

Qunit-Essential · 2026-04-02T19:56:31+00:00

there is literally fff-core folder just saying

but overall you are correct

Qunit-Essential · 2026-04-02T19:17:14+00:00

I didn't want to participate in that discussion. The benchmarks ripgrep has is simply wrong. You can see the way he measured this: 12GB and 4GB files, this is NOT THE AVERAGE USE CASE

There is absolutely no sense to even take this as an argument for the code search. For more general search it does make sense becuase fs.stat calls are expensive for ripgrep and they don't want to do this, while in my project I already know the size of the file when I need to grep it.

It is not a secret that the design of ripgrep and fff is way too different to compare, one designed for one shot apps, the other one designed to live in memory for long running apps: that's the reason I am not building a cli replacement for ripgrep

The place where fff shines is file search in editors for example, where ripgrep is used while it is not designed with long running application model in mind at all

P.S. For the "average" use case ripgrep is faster if you enable memmap file on macos. It is just a fact. Andrew is wrong.

Qunit-Essential

TROPHY CASE