Live data from Hacker News

Fable Converted Pylint to Rust

pypi.org

31–40 of 122 posts

Re: Fable Converted Pylint to Rust

#33
post #26

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

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

Then have it run asynchronously when you save

Re: Fable Converted Pylint to Rust

#35

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.

[dead]

Re: Fable Converted Pylint to Rust

#36
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.

Re: Fable Converted Pylint to Rust

#37
post #26

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

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

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

Re: Fable Converted Pylint to Rust

#38

Earlier quoted context omitted.

While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing. It improves the dev-ex of people contributing to these projects and more importantly helps people seperate logic into silos. Python is inherently limited in which kinds of abstraction it can express.

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 proj…

category error.

surely you aren't calling binary releases of binutils 'projects'? why would you call this thing a 'project' in the sense you're using?

Re: Fable Converted Pylint to Rust

#39

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.

I'd go even further: 'look at me, see what was paid for.' This isn't much different than the 'builder brained' coworker who is obsessed with creating technical debt, not owning it. Throwing shit at the wall and seeing what sticks, passing it off as sage wisdom. It'd be interesting to see the math behind offsetting the GPU crunching with more power efficient linting. Assuming every person or CI job switched (and the m…

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

Re: Fable Converted Pylint to Rust

#40

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.

While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing. It improves the dev-ex of people contributing to these projects and more importantly helps people seperate logic into silos. Python is inherently limited in which kinds of abstraction it can express.

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

Post reply on HN