Live data from Hacker News

Astral

astral.sh

31–40 of 248 posts

Re: Astral

#31

Earlier quoted context omitted.

There's no reason your custom bespoke plugins couldn't be called by ruff as necessary. It's silly to burden the happy path of 99% of users who just need common sense python linting with those edge cases and custom needs.

That's what esbuild did for their plugins—which made them useless since it kills any performance gains of switching to esbuild in the first place

Yes the point isn't esbuild will have magic pixie dust that makes nodejs AST processing magically faster--that's objectively impossible. The point is you can migrate to the new system over time without losing critical plugin functionality right now. It's not to live in a steady state with old slow nodejs plugins.

Re: Astral

#32
post #8

Earlier quoted context omitted.

I’m not against folks getting paid. My question is how does one build an entire company selling a slightly better version of a widely used open source tool? Ruff is not strong enough to build a company from.

> X is not strong enough to build a company from. I mean, these are the famous last words of a lot of non-visionaries. I'm not saying that Ruff is some kind of unicorn, but there are a lot of cases where a seemingly small improvement on an existing technology resulted in a very successful enterprise. Docker, for example. There are others that I'm sure people will chime in with.

Maybe your answer is correct but it is not useful, at all. It does not answer the question, like, providing real solutions.

Re: Astral

#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 questions that aren't answered in the site.

Re: Astral

#34
post #30

It's true that being that much faster is interesting, but that's not the only reason. ruff is just really good. It has sane defaults, it is easy to use and configure. It can replace not one but multiple tools. From day one it had few bugs or integration problems. Charlie Marsh is just a damn good developer, on top of driving a good product vision. That's rare. Lots of respect to that.

> Charlie Marsh is just a damn good developer curious how you assessed this. did you inspect the code or are you just commenting from the user POV?

Eating at a restaurant:

- "This chef is a great cook!"

- "How do you know, have you looked inside the kitchen?"

Re: Astral

#35

Earlier quoted context omitted.

That could be done in one of two ways: - Supporting flake8 plugins, using the existing community, and sacrificing the speed. - Requiring new plugins, in Python or another scripting language, sacrificing the community progress and goodwill, and sacrificing some of the speed. Neither of these options is good. The Python linting ecosystem is a mature one with a lot of investment into the existing tools, and rather than…

??? There is no downside to adding your bespoke flake8 plugins. For people that don't use them (99% of people) they get the benefit of blazing speed. For your custom plugins you live with the tradeoff of slower execution to do those AST passes with flake8/python tools. Even if ruff didn't exist you would still be burdened with your slow flake8 plugins speed. There is zero downside to you and only upside to people tha…

It's not just "custom" plugins, it's all third-party plugins though right? If someone wants to publish a new linter for something, right now they can, and others can use it easily, but Ruff centralises that and makes it harder.

You're right that it will probably still be faster overall because "most" linting will be done with Ruff and any extras would be done externally, but now you've either got 2 tools when you had 1 before, or you've got to shell out to Python which adds overhead, or you've got to rewrite plugins in a Ruff-compatible format, or something else.

> Kinda just sounds like you're grousing because somebody moved the cheese.

I'm just disappointed that someone looked at slow linting and decided the answer was their own new tool, rather than participating in the existing community. Now the effort has forked, it'll take more work overall in the community, and we were already lacking engineering resource.

Re: Astral

#36
post #4

A faster version of black is not a strong enough value proposition for an entire company. Ruff should remain an open source product. What is the point of making every half decent Developer tool a whole startup?

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.

Re: Astral

#37

Earlier quoted context omitted.

That's just a foot in the door. Like sentry made a good logging library, then pivoted to an observability service. And today I use sentry because I have a great history with their product. It's smart and a positive way to make money. I dig it. PS: ruff is not replacing black (although it will probably in the end), but compete with flake8 and pylint.

Sentry had a natural path into cloud services because error monitoring has a server-side component to it. Serious question, what is the path for a linter? Where else are people paying for linting as a service?

A lot of companies would pay actual money for some semblance of supply-chain security. Hosted, verified, certified Python dependencies. This is how Red Hat made all their money in Linux. Something like "use our vetted and secure pypi instead of the free-for-all full of typo squaters and package takeovers that the public pypi.org offers."

Starting with some nice developer tooling and going from there doesn't seem crazy at all.

Re: Astral

#38
A VC raise gives the team cash to work on this full-time, that's great news.

What worries me is what possible possible path can exist that gives VC-returns that is not at odds with customer happiness? Customers being Python developers.

Re: Astral

#39
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 number of issues. pyflakes took 4.49s and found fewer.

Re: Astral

#40
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…

Speed is a problem for linters. If I spend 200ms of CI time instead of say 5minutes that’s a real difference in toil and CI spend

Ruff has an LSP too so it integrates well with editors unlike flake8 and similar which only work on save — and are really slow

Post reply on HN