Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- What if Fable made a jit layer for python. How would it affect ai?by vezycash
- So, develop in an ergonomic language. Then use an LLM to convert to Rust.
No human needs to read or write Rust anymore.
by amelius - The LLMs will save us from Rust. I like LLMs now.by wosined
- There are always going to be reasons for human review of code written by a LLM. Furthermore, for both safety and control, we will want human readable code from LLMs. These "needs" and "wants" can't be eliminated, at least while humans are in control.by baranul
- 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.
by dk_sig11 - 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.
by wg0 - 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.by Hamuko
- > 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.
- 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.
by thraxil - 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.
by torginus - 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.
by mohsen1 - 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.by halJordan
- The issue in this particular project is how well maintained it will be in the long term, since it's chasing after another project with the goal of being 100% compatible. How many of these AI ports are just people chasing one shinny thing then moving on to the next?
- 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
by DannyBee - A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way.
When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary.
LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.
by crabbone - 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.
- > 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?
by ma2kx - You can see the validation approach they used here:
https://github.com/adamraudonis/prylint/blob/main/harness/ch...
by Leynos - 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.
by csomar - I have done such migrations.
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!
by Shorel - > 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.
by adastra22 - > There's no paper or explanation as to why the output should be identical to the real Pylint.
To be a drop-in replacement?
- 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.
by kypro - 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×by Lucasoato - 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.
by ndr - 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.by smarx007
- 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.
by auslegung - 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.
by TheChaplain - 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
by dminik - Using less electricity or time for the same result seems a pretty good point.by tuna74