Can someone with a deeper understanding of these sort of processes say something about the intricaies of building such a transformation process? Seems like constucting the architecture and feedback loops that guide the LLM to achieve a specific goal (byte wise bevhaviour replication) seems rather non trivial and as its on field of research? How common is it to achieve what the authors are publishing here as been having achieved? How elaborate are the achieved goals (i assume that what is specified here is rather precise and assume its true - in good faith for the sake of my question and as it is stated for the sake of being potentually reviewed/checked against)? How advanced are the metrics/behavioral constraints that guided the process? Whats the state of the art of this sort of ehm..reversereplication(?)archaeomorphic kyberneering(?), archaehylomorphic programming(?). Seems like an interesting approach and maybe thats also partially because I haven't seen such an approach - regarding the specificity and methology of defining the desired endresult.

[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

Essentially pay-to-win for coding.

In this case, it’s maybe more “I can access that luxurious model you all pleb are banned from using”

"/loop maintain it" in a cron job

You can't get 2000x faster without actually eliminating some large percentage of the work, you just cannot. You have to find some way to get rid of 99.95% of the work you were doing.

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

>type system guarantees

Can't they run Pylint on itself?

I've stopped telling people when I use LLMs because they focus on that instead of the work itself.

Yeah, because then we would know it has a higher likelihood of being maintained.

Serverless Matrix workers seems to be going nowhere as well.

https://github.com/nkuntz1934/matrix-workers

Most software is not a single finished artifact though, it's a community, a process, knowledge, documentation, and mindshare. This has none of those, so by default it'll die as a project immediately.

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?

In an open source tool, there is no value without community of contributors.

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.

> rewriting a big widely used project in a stricter language is always a good thing

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.

"Buy more RAM" usually isn't the thing I want to hear when my linter is slow.

You'd be surprised, Ruff covers nearly everything: https://docs.astral.sh/ruff/rules/#pylint-pl

I run Ruff + a type checker.

That's how you know it's just for show. A practically equivalent (for Fable) but infinitely more valuable contribution would've been to implement any missing lints as a PR to ruff rather than reinventing (copying) the wheel.

Speculative hyothesis: It might not be compatible with a capitalist social order, but also I get the impression that it' something that will staylike something that will stay. The involved means of production and their control are the critical point here. (Also - highly speculative - potentially the question if they should be >>owned<< at all even by some abstract commons)

In user experience land, 2000ms is not tiny, it's catastrophic.

In interactive software, a single dropped frame is noticeable and irritating. Programming is an interactive experience.

Commit hooks just don't make that much sense. Push hooks are much better idea. Once you're done with all your work, linting, last minute adjustments and whatnot, push it and get the checks result. If something goes wrong, your push is blocked.

> A delay of two seconds in my commit hook pushes my blood to the hydraulic pressure of a 70-ton digger.

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.

Then have it run asynchronously when you save

and hopefully I never have to work with you if you think that every single second must be spent coding, no seconds allowed for stuff to process in the background when you save a file

Ha. I'm probably in the more anti AI camp, but if it could free us from the plague that is Python thinking, I might change my tune. 2 seconds might feel negligible in the real world, but it is damn near an eternity in the supercomputers we're all running.