Live data from Hacker News

Astral

astral.sh

241–248 of 248 posts

Re: Astral

#241
post #70
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?

I think we're going to see a shift in developers expectations towards the cost of their tools, as a side-effect of Copilot & co. If you already pay $100/mo in subscriptions for IDE, its plugins, and services it integrates with, then forking additional $5 for a linter doesn't look as absurd as it used to...

Re: Astral

#242

Yet another case of Python developers getting a basic utility which any other language had available for years and being amazed at something which is an industry standard literally anywhere else. Linter taking multiple seconds is not a problem which occurs in any other popular language. It really boggles my mind why is this lang so popular. Once you write something a little more involved than an utility script or jup…

You don't have to use CLI debugging unless you want to. All popular Python IDEs have integrated debuggers with all the usual features one might expect - not as advanced as modern Java or C# debuggers, true, but definitely light years ahead of debug prints.

It's true that many users avoid them, though, but that's more of a cultural issue, and seems to be more common among DS/ML folk.

Re: Astral

#243
post #11

Those progress bars with time of other linters - is it a joke or it's a data from stupidly enourmous codebase? Or slow (>1s) linters is something that is normal in python?

If you have to do things like parsing or AST walking a lot, you run into the slow performance of the core bytecode interpreter pretty quickly. For Python, this is a compute-heavy workload.

Re: Astral

#246
post #206
post #102

This sounds nice, but um, what's the benefit to faster linting? Is it being slow really a problem people have? I've no experience of this.

18 minutes of CPU time vs 22 seconds of CPU time is significant energy-wise too. (Example from https://github.com/home-assistant/core/pull/86224 by yours truly.)

That's a great point. The GWP of computation is hugely underappreciated.

(Also, nice work!)

Re: Astral

#247
post #102

This sounds nice, but um, what's the benefit to faster linting? Is it being slow really a problem people have? I've no experience of this.

Just because you don't have the issue doesn't mean it's non-existent. We went from 8ish seconds with flake8 to tens of milliseconds with ruff. Ruff can just run as a pre-commit hook because it's so fast. I for one have stopped using flake8 in favour of ruff because of both speed and the huge amount of supported rules in ruff already.

> Just because you don't have the issue doesn't mean it's non-existent.

Indeed! Knowing this is why I asked! Having only worked on small projects I've never had an issue with flake8 as a precommit hook, but what you describe makes it sound compelling.

Re: Astral

#248
post #70

Earlier quoted context omitted.

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

Look at sentry

Sentry requires a platform to work, it's much easier to monetise. I'm not even sure it's possible to self-host?
Post reply on HN