> A Rust reimplementation of pylint that produces byte-for-byte identical output — 15–2300× faster (median ~85×).
> 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?
An entire codebase of PL/SQL Oracle stored procedures, and I migrated it to MySQL stored procedures. Long before LLMs existed.
You migrate the logic as-is because you want to replace the other code. You don't go rewriting or optimizing stuff just yet, not until the migration is complete.
It helps a lot in isolating migration related issues from optimization related issues. You do one thing at at time, and fully test it before doing the next thing.
So basically `ruff check --select=PL` but worse in every single way, maintained by a system that's not even available anymore? It even uses Ruff's code under the surface.
IMHO there is little point of these conversion projects. It screams of "look at me, see what I made" and when the attention goes down a little nothing was ever pushed to the repo ever again.
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.
Do you generally pylint an entire codebase at once though? Why not just the file you are actually working on? Based on the homeassistant results (10.3 hours to lint 17.5k files), it only takes about 2 seconds to pylint a file, which doesn't really feel like enough of a wait to need an entirely new linter
Its fascinating to see these code conversions. I reckon its easier for LLMs because the existing code acts like a precise spec and double up as prompts which the user does not have to provide.
It is the easiest use-case for agents because deterministic tool for testing/verification exists and code of the source project is available. Give it enough tokens and test data and it will produce a clone tool pretty much autonomously in several iterations.
In the few days I had access to Fable 5, I asked it to migrate our toolchain from nix+npm to docker+pnpm. It damn-near one-shotted it. I spent over a week stress testing it in every way and found very few things it missed. I was shocked.
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.
Of course I'm not sure I'd trust to install or use in my main machine something that has been 100% written by an LLM, that doesn't have enough reviews and scrutiny, but the numbers look astounding:
codebase pylint prylint speedup
black 26.7 hr 41s 2328×
This project was created 6 months ago, and had been worked on for months with claude. I guess Fable existed 6 months ago and none of us knew about it...
It's fascinating to read the comments here. The attitude is very strange to me. Writing software is not a sport that if you "cheat" using tools then your results are worthless. Results are speaking for themselves. Unless you can provide a failing test case that the software presented here fails at then your arguments for "how" it was made is moot.
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.
A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way.
When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary.
LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.
This is an interesting use case of LLMs. I like it even though I am not very pro AI in general. Let humans write the program in a high level language and then compile it to a lower-level one using an LL compiler (large language compiler?).
Considering how successful LLMs are at these kinds of projects. I think labs RL on converting successively bigger programs from language A to B, considering they have near-infinite training data, and infinite retries, I think given enough compute, LLMs can get very good at this.
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.
I think open source is dead. Basic issue is - if your product is open source or even open core, building a business around it would be impossible because someone else would point an AI agent at it and would have similar thing to offer.
Hence, closed source is what's next probably. Unfortunately.
29 comments
[ 2.1 ms ] story [ 46.1 ms ] thread> 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?
An entire codebase of PL/SQL Oracle stored procedures, and I migrated it to MySQL stored procedures. Long before LLMs existed.
You migrate the logic as-is because you want to replace the other code. You don't go rewriting or optimizing stuff just yet, not until the migration is complete.
It helps a lot in isolating migration related issues from optimization related issues. You do one thing at at time, and fully test it before doing the next thing.
It baffles me this is not super obvious to you!
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.
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.
It is still a niche use-case.
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.
No human needs to read or write Rust anymore.
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.
When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary.
LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.
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.
Hence, closed source is what's next probably. Unfortunately.