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.
I'd go even further: 'look at me, see what was paid for.'
This isn't much different than the 'builder brained' coworker who is obsessed with creating technical debt, not owning it. Throwing shit at the wall and seeing what sticks, passing it off as sage wisdom.
It'd be interesting to see the math behind offsetting the GPU crunching with more power efficient linting. Assuming every person or CI job switched (and the model stays offline), how many years are we looking at?
Can someone with a deeper understanding of these sort of processes say something about the intricaies of building such a transformation process? Seems like constucting the architecture and feedback loops that guide the LLM to achieve a specific goal (byte wise bevhaviour replication) seems rather non trivial and as its on field of research? How common is it to achieve what the authors are publishing here as been having achieved? How elaborate are the achieved goals (i assume that what is specified here is rather precise and assume its true - in good faith for the sake of my question and as it is stated for the sake of being potentually reviewed/checked against)? How advanced are the metrics/behavioral constraints that guided the process? Whats the state of the art of this sort of ehm..reversereplication(?)archaeomorphic kyberneering(?), archaehylomorphic programming(?). Seems like an interesting approach and maybe thats also partially because I haven't seen such an approach - regarding the specificity and methology of defining the desired endresult.
[some speculative neologismification based on my (limited) understanding of ancient greek ethymology《to illustrate my aesthesis of that process. For the notion of hylomorphism see gilbert simondon ("machine") philosophy]
Adding: polite request to overlook potential orthographic deficiencies of text
Ive done this sort of thing using deepseek flash swarms for just a few bucks. The key thing is that each project needs its own swarm script. you cant just tell the bot "pls port this to rust". you need to analyze the architecture, build a proper plan of how the translation will go, and then iterate your execution script to launch hundreds of bots to do the various stages of the translation. And you need to iterate these stages to make sure it all works.
So, for example, i ported stb_image from C to Jai (you can think of Jai as similar to Zig, another c-style lang).
To do that, i built my own agent scheduling/swarm system, because there is nothing out there that works, its all slop.
First i used normal claudecode and the likes to build a set of translation rules, documentation about the project, and set up the context for all.
Then the first stage of the swarm was to use claude to split the 7000 line library into chunks of about 500 lines each, a few functions/structs at a time. Then each deepseek bot had a task of translating that snippet of code from C to Jai.
Next, i had a system merge it all back together. This was done with just a single claudecode running over time. It had to be agentic and not a script because the bots often would duplicate definitions and things like that.
Then, i had a system where it would try to compile the project, get an error list, parse the error list, and split that error list across multiple fixer agents.
Doing multiple fixers because Jai can give you a large error list across a bunch of functions, so this speeds it up. If your project rules/setup/etc is better you can improve this step to have less errors to begin with. The more tools you can have to prevent errors instantly on a feedback loop of each sub-task, the better it goes.
After the fixer step, the code was ported, but with some mistakes. I ran a wide pass of having 2 agents look at each struct/function, and validate if the translation was done well. 2 of them because if both agree the function is fine, the function probably is actually fine.
Next, i began iterating the test suite. The library had a decent enough test suite, so splitting the work between testing + fixing tests across the different parts of the library was doable. for example i would run fixes on png format and jpeg format at once couse their code doesnt overlap.
After the tests were 100% green, the next stage was to implement a literal exploit finding swarm to fuzz it all, which actually found a couple errors on the original library and found a bunch of more obscure bugs in the port.
After that, now i have my own version of this image loading library, more hardened than the original, on a pet lenguage i wanted to do it for.
Note that the better the AI you have, the less error the process has, and the larger chunking you can use. Mythos can likely do this same port much easier, but deepseek flash did it in about 3 bucks of tokens including the trial runs and experiments.
I later use this tooling to build a translator agent swarm for my videogame that can do english to anything translation for 7000 strings that can be menu buttons, tooltips, small fluff text, and others.
That is why rewriting in another language is such a cheat. LLMs beat 10 years+ experts at the details of a single line of code (and I mean SYNTAX, not invariants), but suck at the design, at the level of functions, and higher up.
If you rewrite someone's stack ... you take out the design part of the work. No need to redesign. Obviously the high level decisions work. 99.5% work as well in python as they do in rust ...
Of course, this will never be the next big thing, and just doesn't help companies one iota. If you need a new thing, this will fuck up badly. Hell, even this translation will fuck up without a senior developer regularly telling the model: "WTF!!!!! Don't do that. Just don't". For a new product you need 100x that.
Eh, I'm not that interested in participating in the marketing. I don't believe Fable/Mythos-lite/whatever is needed to translate. Or, as you call it, luxurious.
You can't get 2000x faster without actually eliminating some large percentage of the work, you just cannot. You have to find some way to get rid of 99.95% of the work you were doing.
Usually those inflated numbers come from single-thread to multi-thread comparisons, where you can fudge as much as you want by adding more cores. They claim this is a single-core to single-core comparison, so basically that means they had a heinous performance bug hidden in their code, almost certainly an n^2 behavior. If this is true 2000x is not the limit of what they could have claimed as speedup. Why not 10,000x? Why not 10,000,000x? All are equally true, and none of them could be fixed by a faithful port of the codebase from one language to another.
So I kinda read it as them being confidently, arrogantly stupid, waving around a result without seemingly having thought about what it means. I think it means they could get most of the speed without ever having had to leave Python if they just fixed one bug...
The 2000x number is based on a pathological directory in black's repo https://github.com/psf/black/tree/main/profiling which make duplicate-code really slow and a fix was done in pylint 4.1.0 according to pylint's maintainer.
>You can't get 2000x faster without actually eliminating some large percentage of the work
Yeah, exactly. That's how optimization works! Recognizing that in many cases, the work is that was being done is not necessary to produce the result you actually need, that it could have been in a different way.
This can sometimes involve adding complexity (by means of a better data structure or algorithm, e.g. a quadtree), and sometimes involve removing it (non-pessimization[0]).
That being said, it's certainly also possible to achieve a speedup by breaking things, which you are suggesting is the case here. I can't comment on that part.
I like the other commenter's information here https://news.ycombinator.com/item?id=48597915. It confirms what i suspected: the source of the 2000x slowdown is very much fixable in Python.
It's not a huge error, it just speaks to the people doing the work not having a solid footing in the concepts
Your best result is not even an order of magnitude faster, while this repo is claiming on average almost 2 orders of magnitude faster. Extraordinary claims require extraordinary evidence sort of thing.
Currently, there are things pylint does that ruff doesn't. To use these, I was running pylint on pypy to get it running at a reasonable speed.
Having pylint reimplemented in Rust seems like a very useful thing to have from my perspective. I get another several x speed up, and I can stop having to worry about a separate python interpreter used for one tool that is a few Python versions behind my codebase.
Also, I'd be interested in the quality of these Rust ports.
I have a friend who's an experienced Rust programmer, and he told me Rust ownership doesn't really lend itself well to rewriting mostly OOP code that was written without having strict ownership in mind, and such project often result on very ugly code full of Box, Rc, unwrap() etc, that majorly pollute the code, and basically mean that you abandon all the Rust-specific safety.
But getting rid of all of this usually requires a complex rethink on how the data actually flows through the application, and many 'rewrite in Rust' project even before AI tended not to bother with that.
They said it's a median 85x speedup while maintaining byte for byte equivalence. If it wasn't agentic coding that got there, everyone would be singing praises about that.
I just watched a video by a guy who got cosmetic surgery done. He's getting roughly 10x more positive attention now. Unless he mentions the surgery, in which case a lot of people get upset.
I note an isomorphism there. If you use AI properly, you can do amazing things with it. But if you brag about it, that doesn't seem to produce positive results (and bragging and quality work appear to be inversely correlated).
Most software is not a single finished artifact though, it's a community, a process, knowledge, documentation, and mindshare. This has none of those, so by default it'll die as a project immediately.
To gain any of those is a much bigger problem: is the code structured well enough to get contributors over? Do the contributors know Rust? What about all the open bug reports? What about the edge cases that aren't triggered by the benchmarked projects, how do you even find them?
pylint keeps being developed, maintained as usual, etc. and the LLM conversion pipeline (little more than "rewrite the diff in rust, make no mistakes" in a loop) runs in the background. why do you care about it? do you care about maintainability of the output of your C compiler?
While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing. It improves the dev-ex of people contributing to these projects and more importantly helps people seperate logic into silos. Python is inherently limited in which kinds of abstraction it can express.
In an open source tool, there is no value without community of contributors.
The value of the discussed project is exactly zero right now in the best-case scenario.
It's more likely to be negative: because there has been no contact with reality (no users have used it in production), the risk is higher than using the existing one.
IOW,
1. Only after some brave souls use this in production, will the value of this project rise to zero.
2. Only after a community (could even just be a single person) demonstrates commitment to this project will it have a non-zero positive value.
Since it was done primarily by someone who was never part of the original community, and they have yet to demonstrate a commitment to maintenance, there is no value to this project.
> While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing.
Assuming everything else stays the same, sure. But everything else is not the same - there is no community, no commitment to maintenance, high risk and, worst of all, no human involvement. This project has negative value now due to the risk.
> It improves the dev-ex of people contributing to these projects
What contributors? There are none, and there are unlikely to be any for the majority of the new repos created like this.
Improving the devex of zero contributors improves exactly nothing.
> Python is inherently limited in which kinds of abstraction it can express.
Sure, but successful projects require committed humans. This has none.
> surely you aren't calling binary releases of binutils 'projects'? why would you call this thing a 'project' in the sense you're using?
Because you called it a good thing using my definition of project:
>>> It improves the dev-ex of people contributing to these projects
If this is supposed to be a "Product of the compilation process only", then sure, but if so, what devex of the contributors exist?
If you want to shift to regarding this as analogous to the binary releases of binutils, then the devex of contributors doesn't matter, because the contributors to binutils aren't binary-patching files.
> rewriting a big widely used project in a stricter language is always a good thing
Always might be a too strong word. Rust is, by design, a language with low development velocity.
So you risk:
1. ossification of the current architecture and deferment of important features; or
2. reliance on AI coding to recover velocity.
Maybe for some 2 does not look like a risk, but I think it's too early to call. We have yet to see the effects of extensively using these tools on large scale projects, for years and decades.
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.
Interesting to read the comments and see the reaction here.
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'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.
I think people will come around to accepting llm written code eventually, but it's hard having your entire career, and identity, upended overnight.
Many people, myself included, have come to define themselves by their coding skills. They've taken great pride in not just solving the problem, but solving it in an elegant or nice looking way. Crisp comments, nice spacing, clever abstractions.
In an age where an llm is better at scanning the code than you are, these things just do not matter anymore. Llms will be doing the debugging. Llms will be doing the writing. Llms will be doing the optimizing. And so all that matters is that llms can make sense of things.
And they are much much better at making sense of things without the need for so many of the things that humans rely on as waypoints.
The skill is no longer writing the code. It's solving the problems. Maybe it always was.
It reminds me very heavily of being on woodworking forums as ever more mass automation happened, and the infinite arguments around whether using power tools/CNC/etc was still "real woodworking".
Lots of previously "hand-crafted" industries have dealt with mass automation. Software is not the first or the last. Hand-wringing by practitioners will change nothing, as it did not for any other industry. The vast majority of customers only care about the results, not the means. While there are some in the high end commission world who care about the art form, this is very rare and not sustainable for the majority.
History says folks would be better off learning how folks survived and adapted in those industries, rather than trying to argue about how worthless or crappy the change is.
Hobby wise, sure, whatever, but as a business what happens is very clear
It's not fascinating, it's tired and well trod territory. I'm disappointed that the HN community fell so willingly into the same hole drawing professionals fell into when Photoshop was released.
> 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?
That caught me off guard too – is that the intention, or the actual verifiable outcome?
Potentially if there are failing tests of known bugs in pylint then Fable could have tried to reproduce those bugs in prylint, but that doesn't necessarily mean identical behaviour – at best only identical test-time behaviour.
Seems the vibe coder likely wanted it to "produce byte-for-byte identical output", but realistically there's no way to actually guarantee that as the description suggests.
It's one thing to burn tokens on a project like this and share it to see if there's any interest, but quite another to make exaggerated claims about its portability.
Because verifying such claims will require roughly as much work as doing the thing manually; that or the community adopting his project, and testing the claims against their code bases (who doesn't want to run random LLM-generated code on their own codebase to verify the OP claims?)
The OP claims align with billions (trillions?) of invested money at the moment. There is a very strong current that want to amplify this narrative.
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×
Quite believable if the test was run on a machine with little RAM and generous/unbounded swap. Not sure these are the numbers we want to see. Anything can take days if it swaps to death.
`pylint . --disable=R0801` will work, `pylint profiling/ --enable=duplicate-code` doesn't seem to exit in a reasonable time. So that's likely hitting some pathological case, possibly accidentallyquadratic.tumblr.com material.
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.
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.
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.
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...
The repo creation date is confusing but if you look at the actual commits, there's been 0 commits between repo creation on Dec 6 2025 and last week, after which it's all "Co-Authored-By: Claude Fable 5". So it's in fact all Fable, not Opus.
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.
That's how you know it's just for show. A practically equivalent (for Fable) but infinitely more valuable contribution would've been to implement any missing lints as a PR to ruff rather than reinventing (copying) the wheel.
Speculative hyothesis: It might not be compatible with a capitalist social order, but also I get the impression that it' something that will staylike something that will stay. The involved means of production and their control are the critical point here. (Also - highly speculative - potentially the question if they should be >>owned<< at all even by some abstract commons)
It covers a lot but in our situation we had to throw Flake8 into the mix to be fully compliant with our style guide (the industry I work in is stricter than most here). There were Ruff rules which would've worked in 95% of cases, but there was no scope for configuration to get it all the way there. Last I checked you also couldn't add your own rules.
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
Commit hooks just don't make that much sense. Push hooks are much better idea. Once you're done with all your work, linting, last minute adjustments and whatnot, push it and get the checks result. If something goes wrong, your push is blocked.
> A delay of two seconds in my commit hook pushes my blood to the hydraulic pressure of a 70-ton digger.
Why though? Surely you have it set up to lint as you edit? I know my neovim installation does that and I see the results in the editor as I type.
If it's a rule that linting needs to be in the commit hook, maybe the linter should write a hash of the files linted somewhere. The commit hook script then only lints those files that have changed since the last lint took place.
and hopefully I never have to work with you if you think that every single second must be spent coding, no seconds allowed for stuff to process in the background when you save a file
Ha. I'm probably in the more anti AI camp, but if it could free us from the plague that is Python thinking, I might change my tune. 2 seconds might feel negligible in the real world, but it is damn near an eternity in the supercomputers we're all running.
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?).
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.
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.
I'd go even further: 'look at me, see what was paid for.'
This isn't much different than the 'builder brained' coworker who is obsessed with creating technical debt, not owning it. Throwing shit at the wall and seeing what sticks, passing it off as sage wisdom.
It'd be interesting to see the math behind offsetting the GPU crunching with more power efficient linting. Assuming every person or CI job switched (and the model stays offline), how many years are we looking at?
Can someone with a deeper understanding of these sort of processes say something about the intricaies of building such a transformation process? Seems like constucting the architecture and feedback loops that guide the LLM to achieve a specific goal (byte wise bevhaviour replication) seems rather non trivial and as its on field of research? How common is it to achieve what the authors are publishing here as been having achieved? How elaborate are the achieved goals (i assume that what is specified here is rather precise and assume its true - in good faith for the sake of my question and as it is stated for the sake of being potentually reviewed/checked against)? How advanced are the metrics/behavioral constraints that guided the process? Whats the state of the art of this sort of ehm..reversereplication(?)archaeomorphic kyberneering(?), archaehylomorphic programming(?). Seems like an interesting approach and maybe thats also partially because I haven't seen such an approach - regarding the specificity and methology of defining the desired endresult.
[some speculative neologismification based on my (limited) understanding of ancient greek ethymology《to illustrate my aesthesis of that process. For the notion of hylomorphism see gilbert simondon ("machine") philosophy]
Adding: polite request to overlook potential orthographic deficiencies of text
Ive done this sort of thing using deepseek flash swarms for just a few bucks. The key thing is that each project needs its own swarm script. you cant just tell the bot "pls port this to rust". you need to analyze the architecture, build a proper plan of how the translation will go, and then iterate your execution script to launch hundreds of bots to do the various stages of the translation. And you need to iterate these stages to make sure it all works.
So, for example, i ported stb_image from C to Jai (you can think of Jai as similar to Zig, another c-style lang).
To do that, i built my own agent scheduling/swarm system, because there is nothing out there that works, its all slop. First i used normal claudecode and the likes to build a set of translation rules, documentation about the project, and set up the context for all. Then the first stage of the swarm was to use claude to split the 7000 line library into chunks of about 500 lines each, a few functions/structs at a time. Then each deepseek bot had a task of translating that snippet of code from C to Jai. Next, i had a system merge it all back together. This was done with just a single claudecode running over time. It had to be agentic and not a script because the bots often would duplicate definitions and things like that.
Then, i had a system where it would try to compile the project, get an error list, parse the error list, and split that error list across multiple fixer agents.
Doing multiple fixers because Jai can give you a large error list across a bunch of functions, so this speeds it up. If your project rules/setup/etc is better you can improve this step to have less errors to begin with. The more tools you can have to prevent errors instantly on a feedback loop of each sub-task, the better it goes.
After the fixer step, the code was ported, but with some mistakes. I ran a wide pass of having 2 agents look at each struct/function, and validate if the translation was done well. 2 of them because if both agree the function is fine, the function probably is actually fine.
Next, i began iterating the test suite. The library had a decent enough test suite, so splitting the work between testing + fixing tests across the different parts of the library was doable. for example i would run fixes on png format and jpeg format at once couse their code doesnt overlap.
After the tests were 100% green, the next stage was to implement a literal exploit finding swarm to fuzz it all, which actually found a couple errors on the original library and found a bunch of more obscure bugs in the port.
After that, now i have my own version of this image loading library, more hardened than the original, on a pet lenguage i wanted to do it for.
Here is the result https://github.com/vblanco20-1/stb_image_jai
Note that the better the AI you have, the less error the process has, and the larger chunking you can use. Mythos can likely do this same port much easier, but deepseek flash did it in about 3 bucks of tokens including the trial runs and experiments.
I later use this tooling to build a translator agent swarm for my videogame that can do english to anything translation for 7000 strings that can be menu buttons, tooltips, small fluff text, and others.
Essentially pay-to-win for coding.
They even replicated the lootbox logic. How long until the agent gives you a set of changes you have to open with a paid key (60% of success)!
With moves like this, I'm not so sure victory is assured... but yes. Pay to play.
I, like most, beat linting delay by running it in the background; asynchronous.
Having been negative, so far, I want to say something positive. I appreciate that LLMs weren't used for license washing in this case.
That is why rewriting in another language is such a cheat. LLMs beat 10 years+ experts at the details of a single line of code (and I mean SYNTAX, not invariants), but suck at the design, at the level of functions, and higher up.
If you rewrite someone's stack ... you take out the design part of the work. No need to redesign. Obviously the high level decisions work. 99.5% work as well in python as they do in rust ...
Of course, this will never be the next big thing, and just doesn't help companies one iota. If you need a new thing, this will fuck up badly. Hell, even this translation will fuck up without a senior developer regularly telling the model: "WTF!!!!! Don't do that. Just don't". For a new product you need 100x that.
In this case, it’s maybe more “I can access that luxurious model you all pleb are banned from using”
Eh, I'm not that interested in participating in the marketing. I don't believe Fable/Mythos-lite/whatever is needed to translate. Or, as you call it, luxurious.
Fair point, though. Agreed in principle.
Yeah a fun hobby of mine this week is to take all these "amazing" Fable projects and clone them with DeepSeek Flash (not even Pro)
Nice, same here/there. Still haven't tried DS, all Gemma, GPT-'OSS', and Qwen.
Making something 50-2000x faster is pointless?
Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.
>type system guarantees
Can't they run Pylint on itself?
You can't get 2000x faster without actually eliminating some large percentage of the work, you just cannot. You have to find some way to get rid of 99.95% of the work you were doing.
Usually those inflated numbers come from single-thread to multi-thread comparisons, where you can fudge as much as you want by adding more cores. They claim this is a single-core to single-core comparison, so basically that means they had a heinous performance bug hidden in their code, almost certainly an n^2 behavior. If this is true 2000x is not the limit of what they could have claimed as speedup. Why not 10,000x? Why not 10,000,000x? All are equally true, and none of them could be fixed by a faithful port of the codebase from one language to another.
So I kinda read it as them being confidently, arrogantly stupid, waving around a result without seemingly having thought about what it means. I think it means they could get most of the speed without ever having had to leave Python if they just fixed one bug...
The 2000x number is based on a pathological directory in black's repo https://github.com/psf/black/tree/main/profiling which make duplicate-code really slow and a fix was done in pylint 4.1.0 according to pylint's maintainer.
>You can't get 2000x faster without actually eliminating some large percentage of the work
Yeah, exactly. That's how optimization works! Recognizing that in many cases, the work is that was being done is not necessary to produce the result you actually need, that it could have been in a different way.
This can sometimes involve adding complexity (by means of a better data structure or algorithm, e.g. a quadtree), and sometimes involve removing it (non-pessimization[0]).
That being said, it's certainly also possible to achieve a speedup by breaking things, which you are suggesting is the case here. I can't comment on that part.
[0] Casey Muratori - Refterm Lecture Part 1 - Philosophies of Optimization https://www.youtube.com/watch?v=pgoetgxecw8
I like the other commenter's information here https://news.ycombinator.com/item?id=48597915. It confirms what i suspected: the source of the 2000x slowdown is very much fixable in Python.
It's not a huge error, it just speaks to the people doing the work not having a solid footing in the concepts
In the world of compilers there is a lot of wasted compute. In my project I'm also getting good results (for now on single files)
https://tsz.dev/benchmarks/micro
Your best result is not even an order of magnitude faster, while this repo is claiming on average almost 2 orders of magnitude faster. Extraordinary claims require extraordinary evidence sort of thing.
I don't think you are. My first reaction was: "cool, now maintain it"
"/loop maintain it" in a cron job
/loop make people respect me for being competent and trustworthy
missing the point
Currently, there are things pylint does that ruff doesn't. To use these, I was running pylint on pypy to get it running at a reasonable speed.
Having pylint reimplemented in Rust seems like a very useful thing to have from my perspective. I get another several x speed up, and I can stop having to worry about a separate python interpreter used for one tool that is a few Python versions behind my codebase.
Also, I'd be interested in the quality of these Rust ports.
I have a friend who's an experienced Rust programmer, and he told me Rust ownership doesn't really lend itself well to rewriting mostly OOP code that was written without having strict ownership in mind, and such project often result on very ugly code full of Box, Rc, unwrap() etc, that majorly pollute the code, and basically mean that you abandon all the Rust-specific safety.
But getting rid of all of this usually requires a complex rethink on how the data actually flows through the application, and many 'rewrite in Rust' project even before AI tended not to bother with that.
They said it's a median 85x speedup while maintaining byte for byte equivalence. If it wasn't agentic coding that got there, everyone would be singing praises about that.
I've stopped telling people when I use LLMs because they focus on that instead of the work itself.
I just watched a video by a guy who got cosmetic surgery done. He's getting roughly 10x more positive attention now. Unless he mentions the surgery, in which case a lot of people get upset.
I note an isomorphism there. If you use AI properly, you can do amazing things with it. But if you brag about it, that doesn't seem to produce positive results (and bragging and quality work appear to be inversely correlated).
Yeah, because then we would know it has a higher likelihood of being maintained.
Using less electricity or time for the same result seems a pretty good point.
Most software is not a single finished artifact though, it's a community, a process, knowledge, documentation, and mindshare. This has none of those, so by default it'll die as a project immediately.
To gain any of those is a much bigger problem: is the code structured well enough to get contributors over? Do the contributors know Rust? What about all the open bug reports? What about the edge cases that aren't triggered by the benchmarked projects, how do you even find them?
...what's the point?
pylint keeps being developed, maintained as usual, etc. and the LLM conversion pipeline (little more than "rewrite the diff in rust, make no mistakes" in a loop) runs in the background. why do you care about it? do you care about maintainability of the output of your C compiler?
Ah, that reminded me to check up on these "AI wonder projects".
Cursor's Web Browser? Last update 5 months ago:
https://github.com/wilsonzlin/fastrender
The Claude C compiler? 4 months since any changes:
https://github.com/anthropics/claudes-c-compiler
Zero moderation too, nice. https://github.com/anthropics/claudes-c-compiler/issues/264#...
CloudFlare's slop NextJS project is still going though. https://github.com/cloudflare/vinext
Serverless Matrix workers seems to be going nowhere as well.
https://github.com/nkuntz1934/matrix-workers
> 100x faster for byte-for-byte identical output
> little point
...yeah.
The ~~beatings~~ rewriting to Rust will continue until morale improves.
[dead]
While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing. It improves the dev-ex of people contributing to these projects and more importantly helps people seperate logic into silos. Python is inherently limited in which kinds of abstraction it can express.
In an open source tool, there is no value without community of contributors.
The value of the discussed project is exactly zero right now in the best-case scenario.
It's more likely to be negative: because there has been no contact with reality (no users have used it in production), the risk is higher than using the existing one.
IOW,
1. Only after some brave souls use this in production, will the value of this project rise to zero.
2. Only after a community (could even just be a single person) demonstrates commitment to this project will it have a non-zero positive value.
Since it was done primarily by someone who was never part of the original community, and they have yet to demonstrate a commitment to maintenance, there is no value to this project.
> While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing.
Assuming everything else stays the same, sure. But everything else is not the same - there is no community, no commitment to maintenance, high risk and, worst of all, no human involvement. This project has negative value now due to the risk.
> It improves the dev-ex of people contributing to these projects
What contributors? There are none, and there are unlikely to be any for the majority of the new repos created like this.
Improving the devex of zero contributors improves exactly nothing.
> Python is inherently limited in which kinds of abstraction it can express.
Sure, but successful projects require committed humans. This has none.
category error.
surely you aren't calling binary releases of binutils 'projects'? why would you call this thing a 'project' in the sense you're using?
> surely you aren't calling binary releases of binutils 'projects'? why would you call this thing a 'project' in the sense you're using?
Because you called it a good thing using my definition of project:
>>> It improves the dev-ex of people contributing to these projects
If this is supposed to be a "Product of the compilation process only", then sure, but if so, what devex of the contributors exist?
If you want to shift to regarding this as analogous to the binary releases of binutils, then the devex of contributors doesn't matter, because the contributors to binutils aren't binary-patching files.
> rewriting a big widely used project in a stricter language is always a good thing
Always might be a too strong word. Rust is, by design, a language with low development velocity.
So you risk: 1. ossification of the current architecture and deferment of important features; or 2. reliance on AI coding to recover velocity.
Maybe for some 2 does not look like a risk, but I think it's too early to call. We have yet to see the effects of extensively using these tools on large scale projects, for years and decades.
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.
Interesting to read the comments and see the reaction here.
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'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.
I think people will come around to accepting llm written code eventually, but it's hard having your entire career, and identity, upended overnight.
Many people, myself included, have come to define themselves by their coding skills. They've taken great pride in not just solving the problem, but solving it in an elegant or nice looking way. Crisp comments, nice spacing, clever abstractions.
In an age where an llm is better at scanning the code than you are, these things just do not matter anymore. Llms will be doing the debugging. Llms will be doing the writing. Llms will be doing the optimizing. And so all that matters is that llms can make sense of things. And they are much much better at making sense of things without the need for so many of the things that humans rely on as waypoints.
The skill is no longer writing the code. It's solving the problems. Maybe it always was.
Agreed
It reminds me very heavily of being on woodworking forums as ever more mass automation happened, and the infinite arguments around whether using power tools/CNC/etc was still "real woodworking".
Lots of previously "hand-crafted" industries have dealt with mass automation. Software is not the first or the last. Hand-wringing by practitioners will change nothing, as it did not for any other industry. The vast majority of customers only care about the results, not the means. While there are some in the high end commission world who care about the art form, this is very rare and not sustainable for the majority.
History says folks would be better off learning how folks survived and adapted in those industries, rather than trying to argue about how worthless or crappy the change is.
Hobby wise, sure, whatever, but as a business what happens is very clear
It's not fascinating, it's tired and well trod territory. I'm disappointed that the HN community fell so willingly into the same hole drawing professionals fell into when Photoshop was released.
> 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?
> There's no paper or explanation as to why the output should be identical to the real Pylint.
To be a drop-in replacement?
> There's no paper or explanation as to why the output should be identical to the real Pylint.
Because that was the prompt they used. Seems par for the course with vibe coded projects.
You can see the validation approach they used here:
https://github.com/adamraudonis/prylint/blob/main/harness/ch...
That caught me off guard too – is that the intention, or the actual verifiable outcome?
Potentially if there are failing tests of known bugs in pylint then Fable could have tried to reproduce those bugs in prylint, but that doesn't necessarily mean identical behaviour – at best only identical test-time behaviour.
Seems the vibe coder likely wanted it to "produce byte-for-byte identical output", but realistically there's no way to actually guarantee that as the description suggests.
It's one thing to burn tokens on a project like this and share it to see if there's any interest, but quite another to make exaggerated claims about its portability.
Because verifying such claims will require roughly as much work as doing the thing manually; that or the community adopting his project, and testing the claims against their code bases (who doesn't want to run random LLM-generated code on their own codebase to verify the OP claims?)
The OP claims align with billions (trillions?) of invested money at the moment. There is a very strong current that want to amplify this narrative.
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:
Quite believable if the test was run on a machine with little RAM and generous/unbounded swap. Not sure these are the numbers we want to see. Anything can take days if it swaps to death.
"Buy more RAM" usually isn't the thing I want to hear when my linter is slow.
TBH this is true only on the root of black. If you do `uvx pylint src/` it takes 5s on my machine.
It's still impressive but it looks like a pathological case in a test directory.
https://github.com/psf/black/tree/main/profiling
Yes it's that, in particular `duplicate-code`.
`pylint . --disable=R0801` will work, `pylint profiling/ --enable=duplicate-code` doesn't seem to exit in a reasonable time. So that's likely hitting some pathological case, possibly accidentallyquadratic.tumblr.com material.
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.
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.
It is still a niche use-case.
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.
So, develop in an ergonomic language. Then use an LLM to convert to Rust.
No human needs to read or write Rust anymore.
The LLMs will save us from Rust. I like LLMs now.
What if Fable made a jit layer for python. How would it affect ai?
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...
The repo creation date is confusing but if you look at the actual commits, there's been 0 commits between repo creation on Dec 6 2025 and last week, after which it's all "Co-Authored-By: Claude Fable 5". So it's in fact all Fable, not Opus.
*look inside* > ruff
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.
> It even uses Ruff's code under the surface.
This is the modus operandi for a lot of vibe coded stuff. Absorb the code of entire projects wholesale and then repackage it as something new.
Some of them have the decency to at least give credits to the original.
That's how you know it's just for show. A practically equivalent (for Fable) but infinitely more valuable contribution would've been to implement any missing lints as a PR to ruff rather than reinventing (copying) the wheel.
Speculative hyothesis: It might not be compatible with a capitalist social order, but also I get the impression that it' something that will staylike something that will stay. The involved means of production and their control are the critical point here. (Also - highly speculative - potentially the question if they should be >>owned<< at all even by some abstract commons)
Why do this? Ruff already exists.
ruff scratches the surface. pylint has more deep checks.
They don't all support the same rules (there's literally thousands of them), so it's quite common to run multiple linters against a project.
You'd be surprised, Ruff covers nearly everything: https://docs.astral.sh/ruff/rules/#pylint-pl
I run Ruff + a type checker.
It covers a lot but in our situation we had to throw Flake8 into the mix to be fully compliant with our style guide (the industry I work in is stricter than most here). There were Ruff rules which would've worked in 95% of cases, but there was no scope for configuration to get it all the way there. Last I checked you also couldn't add your own rules.
Would be great if it could convert the entire Python ecosystem to another language (or to GIL-free Python).
I’m interested in python bytecode to rust code compiler, that will save a lot of time and energy.
It would be like writing english words using cyrylic letters claiming you know Russian.
I wonder how it handles pylint's plugins.
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
A delay of two seconds in my commit hook pushes my blood to the hydraulic pressure of a 70-ton digger.
Commit hooks just don't make that much sense. Push hooks are much better idea. Once you're done with all your work, linting, last minute adjustments and whatnot, push it and get the checks result. If something goes wrong, your push is blocked.
In user experience land, 2000ms is not tiny, it's catastrophic.
In interactive software, a single dropped frame is noticeable and irritating. Programming is an interactive experience.
> A delay of two seconds in my commit hook pushes my blood to the hydraulic pressure of a 70-ton digger.
Why though? Surely you have it set up to lint as you edit? I know my neovim installation does that and I see the results in the editor as I type.
If it's a rule that linting needs to be in the commit hook, maybe the linter should write a hash of the files linted somewhere. The commit hook script then only lints those files that have changed since the last lint took place.
[dead]
Then have it run asynchronously when you save
hopefully I never have to work with you if you think 2 seconds for libting is fine
and hopefully I never have to work with you if you think that every single second must be spent coding, no seconds allowed for stuff to process in the background when you save a file
2 seconds is an eternity for a check since the last edit. I expect IDE to respond real time as I type.
2 seconds is bonkers to check a single file.
Ha. I'm probably in the more anti AI camp, but if it could free us from the plague that is Python thinking, I might change my tune. 2 seconds might feel negligible in the real world, but it is damn near an eternity in the supercomputers we're all running.
They may instead be targeting folks that run it in CI.
X rewrote Y in Rust is the new “Blazing fast Y written in Rust”.
no, its "rewrote x in rust and now it's blazing fast". I still dont know fast "blazing" is. 10x? 100x? any increase at all?
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?).
How much did it cost?
>Where pylint crashes, prylint reports the same crash message.
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.
... and Mythos just found 10k of zero-days. Dept of trading issued an order to restrict foreigners access to PyLint. /s
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.