Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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.
  • 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.

  • 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.

  • 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.

  • > 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?

  • 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×
  • 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.

  • 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.

Explore Birbla archives