Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astral

astral.sh

Post reply on HN
Print view View original

181–190 of 248 posts

Re: Astral

#181

Post by npage97 »

zx8080 wrote: post #178
lozenge wrote: post #97

Earlier quoted context omitted.

The main reason pylint is slow is it tries to infer the types of the variables, and it predates type annotations so it can go through multiple functions/control paths across multiple files to figure these out. This approach is obviated by type annotations and type checkers. Ruff is built for speed from the start and doesn't look at type annotations because you should run a type checker alongside.

Just to be sure. Is Ruff faster by lacking type checking? Also, does Ruff work well on codebase without type hints?

Ruff is definitely faster by lacking type-checking. That requires way more analysis.

Ruff will work fine without type hints.

I believe it rightfully leaves it to mypy for those who want those features.

Mypy transpiles itself to c using mypyc and that can still take a while to complete when caches get invalidated.

Re: Astral

#182

Post by mixmastamyk »

ohmahjong wrote: post #98
kvathupo wrote: post #36

Earlier quoted context omitted.

I agree and would ask: is linting that much of a bottleneck to development? Having an automated lint run upon opening a PR seems like a minor expense, especially when you can work on other tickets while you wait.

It's much more noticeable when running locally. Going from something like black + pylint + mypy running in a pre-commit hook to black + ruff + mypy has been wonderful for me. It lets me actually set up another terminal session to run ruff on every file change - where pylint would take seconds, ruff is essentially instant. Side note: I really hope mypy can get the same treatment; it runs quickly once its cache is esta…

These don't have to be run on every file in the repo, only the ones that have changed. At least not often. If it takes seconds, there is something wrong.

Re: Astral

#183

Post by zamnos »

senko wrote: post #54
Night_Thastus wrote: post #53

Earlier quoted context omitted.

Pretty bold to try to replace Flake8 and Black with one tool. I hope they succeed. Would be great to have a tool that does both and is substantially faster.

Indeed. I do hope they'll expose Ruff as a Python module / API in the future. I'm currently using Black to format Python code that's in-memory (never gets written out to disk). With Black (as an imported Py module), it's just a matter of passing in a string and getting one back. With Ruff as it is now, I'd have to write that out to disk, spawn Ruff process, then read the formatted file back in. Do that for many files…

Why doesn't ruff reading/writing from stdin/out, combined with passing the data in with python subprocess.run and os.pipe work here?

    cat bad.py | ruff check --fix --stdin-filename stdin.py - > good.py
Substituting bad.py and good.py for in-memory os.pipe objects for your data. This still involves spawning a subprocess, which can add up, but you're not having to read/write to disk at least.

Re: Astral

#184

Post by ehsankia »

smt88 wrote: post #139
ehsankia wrote: post #136

Earlier quoted context omitted.

Maybe tooling for other languages are faster because the dev has to spend a lot more time specifying a lot more things / are a lot more verbose. The reason tooling on Python is slow is exactly why people love it, because it's lightweight, easy to quickly whip up a script. Take a one line hello world vs having to create an entire project and 10 lines in C#. Not having to type annotate every tiny thing is also great. Y…

Choosing a language based on initial setup or Hello World is valuing the wrong things. You set up an application once, write each line a few times, read it dozens of times, and run it millions of times. The most costly part of that process is reading/rewriting because developer time is expensive. Language choice should be optimized to make it easy to read other people's code and to prevent mistakes from getting into…

> Language choice should be optimized to make it easy to read other people's code and to prevent mistakes from getting into production. Python is not near the top of the pack in those dimensions.

I think most people would definitely disagree with you on the first point. As far as languages go, Python is probably one of the most readable ones out there. It's often even compared to pseudocode because well written Python reads like it.

The latter is a valid point, but assumes all code you ever write is made for production. That's just plainly false. Python is great for tooling, automation, prototyping and many other smaller scale non-production usage. That's where the low-barrier of entry really shines.

Re: Astral

#185

Post by mixmastamyk »

throwaway2137 wrote: post #164
mixmastamyk wrote: post #159

Earlier quoted context omitted.

> Linter taking multiple seconds is not a problem which occurs in any other popular language. It doesn't happen in Python either. So that's good. > barely ever needing to touch the terminal Not really a good sign, point-click developers are not usually the strongest. That said I like things to work easily and don't have many quarrels with Python. Certainly fewer than most other languages. Sounds like you're not very…

> Not really a good sign, point-click developers are not usually the strongest. In principle I agree, but my point is - it was possible to be fully productive being just a point-click developer. > It doesn't happen in Python either. So that's good. pyright + black + isort hook in the project I'm working on takes 1-5 seconds on an M1 mac on save. We're moving to ruff for this reason. Never saw this anywhere else. > I…

I mentioned elsewhere but might as well here again. These tools should only be run on the files that changed, not every single one in the repo. I run my tools with the script equivalent of:

    git status | grep \.py | tools
And it should exit in a split second. We have a pretty large codebase, though not gigantic.

Re: Astral

#186

Post by mardifoufs »

swyx wrote: post #148
emoprincejack wrote: post #134

Earlier quoted context omitted.

[flagged]

then you probably dont know that i'm actually more supportive of charlie than most and are reading negative intent from a perfectly neutral/innocent question that is perhaps badly phrased :)

I don't get it! What's the link here? Sorry if I'm being daft or missing something obvious

Re: Astral

#187

Post by mixmastamyk »

kstrauser wrote: post #39
neves wrote: post #33

Speed is a non existent problem for linters. Pyflake is quick enough. I spend more time thinking than writing code. I just write in one file at a time, which can be linted in sub-second time. How does it compare with Pyflake8 in error messages? Does it find more errors? Does it have less false positives? Does it integrate well with other developers tools? Does it have sane defaults? These are the really important que…

I disagree about the speed. I don't have a problem with pyflake, but running `time ruff -s .` in a project with 1,236 Python files took 78ms. At that speed, it could re-check the file I'm working on in an editor after every keystroke with no noticeable latency. It's not just a little bit faster. It's freakishly, ridiculously, gone-plaid faster. Edit: for comparison, flake8 took 8.19s and found approximately the same…

Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.

Re: Astral

#188

Post by rattray »

zx8080 wrote: post #178
lozenge wrote: post #97

Earlier quoted context omitted.

The main reason pylint is slow is it tries to infer the types of the variables, and it predates type annotations so it can go through multiple functions/control paths across multiple files to figure these out. This approach is obviated by type annotations and type checkers. Ruff is built for speed from the start and doesn't look at type annotations because you should run a type checker alongside.

Just to be sure. Is Ruff faster by lacking type checking? Also, does Ruff work well on codebase without type hints?

Ruff is faster than many tools which don't do type checking.

Ruff works well regardless of whether you use type hints.

Re: Astral

#189

Post by Mawr »

dzonga wrote: post #64

I don't use Rust - but can't deny Rust is saving the environment. countless CPU hours wasted by running dev tools written in slow as molasses languages now getting rewritten in Rust. build / lint times * number of times builds taken * kWH = saved energy

Sure, as long as there are no tradeoffs involved. But there are. Opportunity cost for one.

Your saved energy calculation is the absolute upper bound possible, the real value is likely close to 0 or even negative (crypto).

Even the upper bound you've calculated is an infinitely small amount of energy compared with everything else we use energy for at the global scale. It's irrelevant.

If you want to save the world, do something that has a clear positive relationship towards it. Ditch your car, plant a tree, vote for the right politician.

Re: Astral

#190

Post by panchicore3 »

pid-1 wrote: post #70
akprasad wrote: post #5

I love Ruff and I'm glad that Charlie and the rest of the team are able to work on such tools full-time. I'm also happy to see that the author of Maturin (Rust+Python interop) is involved, as Maturin is a fantastic project with great ease-of-use. For those who aren't familiar, Ruff is a very fast Python linter that supersedes a variety of tools like isort, flake8, and perhaps eventually Black [1]. My understanding is…

Even if no VC was involved, how do you make money developing an open source linter?

Look at sentry
Post reply on HN