Rendered at 10:45:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
TheChaplain 2 hours ago [-]
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.
bravetraveler 2 hours ago [-]
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?
NonHyloMorph 33 minutes ago [-]
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
rpunkfu 25 minutes ago [-]
Essentially pay-to-win for coding.
bravetraveler 8 minutes ago [-]
With moves like this, I'm not so sure victory is assured... but yes. Pay to play.
dgellow 2 hours ago [-]
In this case, it’s maybe more “I can access that luxurious model you all pleb are banned from using”
bravetraveler 1 hours ago [-]
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.
1 hours ago [-]
dminik 3 minutes ago [-]
Ah, that reminded me to check up on these "AI wonder projects".
Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.
xnickb 2 hours ago [-]
I don't think you are. My first reaction was: "cool, now maintain it"
2 hours ago [-]
baq 54 minutes ago [-]
"/loop maintain it" in a cron job
tuna74 2 hours ago [-]
Using less electricity or time for the same result seems a pretty good point.
danpalmer 1 hours ago [-]
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?
baq 55 minutes ago [-]
...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?
1 hours ago [-]
odiroot 10 minutes ago [-]
The ~~beatings~~ rewriting to Rust will continue until morale improves.
baq 58 minutes ago [-]
> 100x faster for byte-for-byte identical output
> little point
...yeah.
aaron695 45 minutes ago [-]
[dead]
whereistejas 1 hours ago [-]
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.
lelanthran 59 minutes ago [-]
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.
baq 33 minutes ago [-]
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?
lelanthran 20 minutes ago [-]
> 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.
cornholio 32 minutes ago [-]
> 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.
dk_sig11 40 minutes ago [-]
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.
amelius 12 minutes ago [-]
Would be great if it could convert the entire Python ecosystem to another language (or to GIL-free Python).
ma2kx 4 hours ago [-]
> 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?
QuantumNomad_ 2 hours ago [-]
> There's no paper or explanation as to why the output should be identical to the real Pylint.
To be a drop-in replacement?
adastra22 2 hours ago [-]
> 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.
kypro 1 hours ago [-]
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.
csomar 1 hours ago [-]
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.
voidUpdate 1 hours ago [-]
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
flyingbeaver09 24 minutes ago [-]
hopefully I never have to work with you if you think 2 seconds for libting is fine
voidUpdate 10 minutes ago [-]
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
psd1 59 minutes ago [-]
A delay of two seconds in my commit hook pushes my blood to the hydraulic pressure of a 70-ton digger.
odiroot 6 minutes ago [-]
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.
lelanthran 39 minutes ago [-]
> 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.
voidUpdate 49 minutes ago [-]
Then have it run asynchronously when you save
deviation 1 hours ago [-]
They may instead be targeting folks that run it in CI.
ForHackernews 49 minutes ago [-]
Why do this? Ruff already exists.
iamgopal 53 minutes ago [-]
I’m interested in python bytecode to rust code compiler, that will save a lot of time and energy.
self_awareness 14 minutes ago [-]
It would be like writing english words using cyrylic letters claiming you know Russian.
Hamuko 2 hours ago [-]
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.
short_sells_poo 1 hours ago [-]
> 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.
NonHyloMorph 20 minutes ago [-]
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)
torben-friis 50 minutes ago [-]
>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.
monax 2 hours ago [-]
*look inside*
> ruff
6 hours ago [-]
pbgcp2026 3 hours ago [-]
... and Mythos just found 10k of zero-days. Dept of trading issued an order to restrict foreigners access to PyLint. /s
devnull3 1 hours ago [-]
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.
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?
[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
Fair point, though. Agreed in principle.
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
Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.
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?
> little point
...yeah.
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.
It is still a niche use-case.
> 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?
To be a drop-in replacement?
Because that was the prompt they used. Seems par for the course with vibe coded projects.
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.
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.
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.
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.