Fable Converted Pylint to Rust
pypi.org
pypi.org
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.
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?
Fair point, though. Agreed in principle.
[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
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.
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.
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.
1. Language semantics don’t translate, way people usually write python is not how you write rust.
2. There’s no such thing as line-for-line rewrite with llm, even if you’re really great at spec planning etc, if you don’t review each line, it’s going to be lazy.
3. Brings me to last point, it’s usually such a huge amount of code that llm “ports” and fact it is going to be lazy somewhere, means you get ticking bomb.
On the good side - abandoned software that needs to be migrated to compile on modern systems is for the most part solved and I love it.
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?
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.
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.
> little point
...yeah.
Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.
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...
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
It's not a huge error, it just speaks to the people doing the work not having a solid footing in the concepts
Can't they run Pylint on itself?
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).
They dont understand its about the idea. The project viability relies on the ability of identifying a problem and brainstorming a novel way of solving it. Thats the hard part. LLMs let me execute my brain plan. The coding aspect has been democratized to non-coders.
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
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.
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.
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.
codebase pylint prylint speedup
black 26.7 hr 41s 2328×It's still impressive but it looks like a pathological case in a test directory.
`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.
> 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?
Because that was the prompt they used. Seems par for the course with vibe coded projects.
To be a drop-in replacement?
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.
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.
https://github.com/adamraudonis/prylint/blob/main/harness/ch...
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!
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.
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
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.
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.
When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them).
Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.
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 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.
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.
Hence, closed source is what's next probably. Unfortunately.
It is still a niche use-case.
No human needs to read or write Rust anymore.
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.
In interactive software, a single dropped frame is noticeable and irritating. Programming is an interactive experience.
I run Ruff + a type checker.
https://github.com/astral-sh/ruff/issues/970
Though some of them will presumably be covered by Ty
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.