Perhaps I am out of touch, but a project with author/s that have passion for every line, function and purpose, feels more real and worth my trust to spend time using it.

To preempt a question, our team has no knowledge or experience with nix, it was setup before the current team was in place by people who did have knowledge and experience of nix. The current team knows docker much better.

Fully agentic coding is working well for projects like this since no matter how you write the code, the only way to truly know "it's working" is if it passes the test.

With the right skills you can make well designed software with agentic coding too. It's not as easy as a simple "convert this to rust" prompt, at least today.

    codebase   pylint       prylint     speedup
    black      26.7 hr      41s         2328×

Which implies that eventually one can set 'A' to English and 'B' to x86 assembly. Which means LLMS will eventually emit executable code. Whether this will be a party trick or a meaningful shift in software, remains to be seen.

Perhaps for some LLMS, there will need to be some intermediate translation, but this will disappear over time.

> prylint is not "inspired by" pylint. [...] Where pylint has bugs, prylint reproduces them. Where pylint crashes, prylint reports the same crash message.

This looks very strange to me. There's no paper or explanation as to why the output should be identical to the real Pylint. Looking at GitHub, all the commits are by Claude, and otherwise, adamraudonis doesn't seem to have any connection to anyone else.

I don't want to accuse anyone of anything unjustly, but this post seems more like a kind of malware SEO. Is this project legit?

I didn't use Fable (just Opus and Gemini) but I recently ported the `djlint` Python library to Rust, also relying heavily on LLMs (but not trying to one-shot it). `djlint` is a library to lint and reformat HTML and Django template files (and some other formats but I haven't tackled them yet as I don't really have any need). It's currently unmaintained (for a couple years at least) but was part of our CI/CD and the reformat in particular is very slow on a large codebase with thousands of templates. For our code, it took about 4 minutes to run. I generated a Rust port in a similar way, aiming for byte-for-byte output compatability. The Rust version runs on the same code in a fraction of a second; fast enough to put in a pre-commit hook. Some of that was the raw Python->Rust conversion, but a lot was some optimization work that I did afterwards. The Python version was heavily regexp-based, basically running a big slow regexp for every rule that it implements, sometimes running the regexp in a loop starting with each tag it encounters as it goes through each file. For the Rust version, I switched it to properly tokenize the files and then match rules on the AST in a single (or relatively few in some cases) pass. Honestly, there's still a lot of low hanging fruit to make it faster but it's already such a big improvement that I'm pretty happy with it. I'm sure those optimizations could've been done in Python but if I'm the one maintaining the code now, I'd much rather deal with Rust than Python with or without LLM assistance.

It is still a niche use-case.

No human needs to read or write Rust anymore.

Hence, closed source is what's next probably. Unfortunately.

As always, three lines in you realize that the doc you're reading hasn't been written (maybe not even read) by a human.

So so tired of this breach of trust.