Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
72% Positive
Analyzed from 3157 words in the discussion.
Trending Topics
#project#rust#code#pylint#more#projects#using#single#ruff#why
Discussion Sentiment
Analyzed from 3157 words in the discussion.
Trending Topics
Discussion (82 Comments)Read Original on HackerNews
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 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.
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
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 making it asynchronous.
Fair point, though. Agreed in principle.
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).
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 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...
https://tsz.dev/benchmarks/micro
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
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?
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.
To preempt a question, our team has no knowledge or experience with nix, it was setup before the current team was in place by people who did have knowledge and experience of nix. The current team knows docker much better.
Fully agentic coding is working well for projects like this since no matter how you write the code, the only way to truly know "it's working" is if it passes the test.
With the right skills you can make well designed software with agentic coding too. It's not as easy as a simple "convert this to rust" prompt, at least today.
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.
It's still impressive but it looks like a pathological case in a test directory.
> 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.
It is still a niche use-case.
No human needs to read or write Rust anymore.
I run Ruff + a type checker.
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.
In interactive software, a single dropped frame is noticeable and irritating. Programming is an interactive experience.
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.
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.