by TheChaplain
12 subcomments
- 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.
- 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.
- 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 Lucasoato
2 subcomments
- 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×
- 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.
- > 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?
- 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 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.
- So, develop in an ergonomic language. Then use an LLM to convert to Rust.
No human needs to read or write Rust anymore.
- 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.
- What if Fable made a jit layer for python. How would it affect ai?
- Would be great if it could convert the entire Python ecosystem to another language (or to GIL-free Python).
- *look inside*
> ruff
by worldsavior
1 subcomments
- 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...
- 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.
- I’m interested in python bytecode to rust code compiler, that will save a lot of time and energy.
by voidUpdate
4 subcomments
- 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
by ishouldbework
0 subcomment
- I wonder how it handles pylint's plugins.
by wiseowise
1 subcomments
- X rewrote Y in Rust is the new “Blazing fast Y written in Rust”.
- 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?
by ForHackernews
2 subcomments
- Why do this? Ruff already exists.
by torben-friis
0 subcomment
- >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.