Join the discussion

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

  • Hacker News
  • And ROI of 0?
  • Not at all. The example was an experiment.

    I did because I have a huge legacy code base, a distributed monolith, a few millions lines of code. Ideally, I want to get rid of it.

    At this point, I know a recipe to break the monolith, so I finally could eat the elephant piece by piece.

  • The best language a program to be written in is the original.

    Languages have conventions and best practices that aren’t portable.

    We could port COBOL to c and do a crap ton of goto/jmps and make a

         BEGIN MESS
  • Of course language concepts don't translate.

    My point is that one can translate the data flow to another language.

    You could imagine any program as input -> [blackbox] -> output. For example, same pixels rendered on the screen provided identical keyboard input.

    I propose a way to decompose the blackbox.

  • Makes sense it would have been 6 USD in GLM 5.3?
  • I doubt that it is possible with GLM.

    I haven't played with GLM 5.3, only with 5.2, so I cannot say for sure.

    GLM is at the level of Opus. Fable is something different entirely. It is capable of tracing the data flows of the app, I even tried it in a huge PHP codebase, it works.

    PHP is a weird beast because it allows something like

        $v = 'SomeClass' + 'Controller'
        ... // and later
        new($v)
    
    
    In other words, it could be hard to understand the code without running it, Fable reads this.

    And another distinct feature of Fable — it is an amazing orchestrator. I prohibit it basically read and write, and it operates a swarm of haiku and sonnet.

  • what did i read? genuinely? its only a few words, and even that had to be AI written. The topic in the title barely was mentioned.
  • pangram says 100% human
  • Human-written. I was trying to be short and straight to the point.

    LLM-powered rewrites and huge refactors are better done using 1 additional step "convert the code to <something> that represents it best".

    The simplest example is, for a CRUD app it can be swagger description. The more complex behaviour exhibit the app, the more raw information should be provided.

    Like ontologies, "A is a child of B" model can derive and enforce that "B is a parent of A", and so on.

    On top of that, I write that Fable is reasonably cheap if one uses it solely for agent orchestration.

  • The title is the worst part of the essay. Which is super interesting, to wit: fable's a very capable model when it comes to transforming concepts in and out of structural descriptions, and you can use it (along with a test suite I presume) to transpile a codebase. I wouldn't have thought to do this, but I think it makes sense, and I like it - it's using model intelligence at a few different steps for sensible things. Thanks for the writeup. De clickbait your title though or you'll keep getting clickbait rage responses :)
  • Ime it remains the best model for prototyping, sims, visualization etc throwaway scenarios. Just don’t look at the generated code if you just let it rip on the problem for hours ;) but that advice applies to any model unfortunately
  • I'm glad you liked it. I was trying to keep both, the title and the content as straightforward as possible.

    Another point is, Fable is reasonably cheap if you don't allow it to read or write.

  • I recently rewrote a complex C++ program into Rust using the Strangler Mode, all codes are written by AI. Firstly, I split the code into some dynamic libraries, which uses C ABI to interacts with each other. Secondly, rewrite the libraries one by one. A init_xxx function are used to construct a object and a free_xxx is used to deconstruct it. A handle is used as 'this' pointer. In the caller side, write another class, constructor calls init_xxx and deconstructor calls free_xxx. No other code should be modified during the split.
  • Nice. Yeah, the general problem is how to divide and conquer. Your method is not always available (it depends on the language pair), in my case, Go packages didn't translate into Rust crates 1:1.
  • Most important information is missing here.

      * How many lines was the result? Considering how much err != nil and line splitting needs to be done in Go, did you at least reach 30k SLoC?
        * How was sloc counted here? includes comments, blank lines or not? (something like cloc will give a good answer).
      * Performance characteristics of resulting rust, was there an improvement? It maybe appealing to say Rust is Always faster than Go.
    
    As usual these AI coding posts tend to be loose on actual measurements. Don't like it. Granted you can't do too much experimentation with prompting techniques since you're paying per token. But at least you can assess the code that was produced?
  • Thanks for the feedback. My main goal was to present the idea with an intermediate representation, I didn't payed much attention to the specifics of this translation, it would vary wildly depending on code bases.

    65k LoC of Go without comments resulted in roughly 60k LoC of Rust witout comments (code column of the cloc tool).

    The error handling is not so different between Rust and Go, in both cases I cannot panic to avoid the data loss. So it boils down to if (failure) return something for graceful degradation. And generally errors in my case (a text editor) are rare, only disk IO, which is encapsulated in one VFS module, everything else, like non-closed brackets in code is expected behavior.

    The biggest differences were in third party libraries, UI, markdown parsing — completely different API and paradigms.

    > Performance characteristics of resulting rust

    I haven't measured. I don't think there's any significant difference between Go and Rust if app doesn't do allocations on a critical path. The reason I started this project was mainly to experiment (now I use similar approach to refactor much bigger legacy code base), and tree-sitter support is better Rust so it seemed like a good fit.

  • I have rewritten several things from eg. Python to Rust, Rust to Go very recently. The 400 USD is pretty arbitrary as you could rewrite several big projects pretty comfortably with the Claude ~100 USD subscription tier.

    In my experience it mostly comes down to the harness (or lack of) that you use. Something like 'superpowers' can be pretty verbose and hash out things for a long time (and use a decent amount of tokens) but the output is pretty decent. The better instructions and the more brainstorming you do initially the better - as the subagents encounter fewer issues.

    Without a harness you could try a direct port (prompt: 'convert x to y, don't bother me') and if the languages are roughly compatible you could get a seemingly working port much quicker but likely with major hidden issues. A comprehensive testsuite is obviously a must.

  • > I have rewritten several things from eg. Python to Rust, Rust to Go very recently.

    What is the scale? Because I'm pretty sure it's impossible to one shot 65k LoC with "good luck, make no mistakes" prompt.

    I also did this within a subscription. I counted the number of tokens afterwards and calculated the cost as if I'm paying per token. $400 is of course arbitrary, but it's a ballpark number, bun was $165000.

    > In my experience it mostly comes down to the harness (or lack of) that you use.

    Yep, it is.

    Tokens per task is a good proxy measure of skills, 'superpowers' or any other.

    Either a skill gets you the thing more efficiently (less tokens), or you don't need to redo the result afterwards (less tokens). I benchmark all my skills that way.

    Models need less and less steering at this point, especially frontier ones.

  • Following the recent "Rewriting bun in Rust" I thought to run an experiment which turned out to be success.
  • How much did the verification cost on top? how did you gate it? was it a Go test suite you ran against the Rust or what? I always wonder how ppl are testing these rewrites, rewriting the tests can also lead to bug. I really wonder how reliable are rewrites like that, a 65k lines you didn't actually read. How did you confirm the semantic equivalence, same behaviour?
  • Porting something to a language you don't know doesn't seem very helpful to me. You've locked yourself out of doing useful work except with continued application of more AI. Without the ability to verify it, except with even more AI maybe, you're starting on a slippy slope to slop.

    If the experiment was "spend 400 bucks to see if it'll work" then that's awesome, and fun, and a cool use of AI. It's impressive that AI can do that.

    If it was to make something useful ... has it?

  • I recently performed this exact exercise of converting a complex library set from one language into an intermediate state machine representation and then translated into N other languages. It worked well but there's a lot of caveats. I'd highly recommend a direct "port" in most cases tbh, as many bugs are "load bearing" and may not survive the intermediate translation. I speak from experience.
  • Wouldn’t finding such bugs be considered advantageous? That is unless someone just yoloing the result directly to customer ofc
  • > I'd highly recommend a direct "port"

    I'm sure there are other caveats. Also cost of the more or less straightforward Bun port was $165000 for 500KLoC.