Live data from Hacker News

Astral

astral.sh

91–100 of 248 posts

Re: Astral

#91
post #90
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…

just starting to dabble in Rust, and I've seen PyO3 mentioned a number of times for writing rust bindings. What's the difference between Maturin and PyO3?

PyO3 is the library that enables Python Rust bindings, Maturin is a build tool for packaging PyO3 Rust libraries (which export Python APIs) as Python packages!

Re: Astral

#92
This along with pydantic [0] means that 2/3 of my favorite python open source projects are now commercially backed. I wonder how long FastAPI will last?

As an aside, what is the issue with versioning these days? Ruff and FastAPI both have massive user bases and a reliable codebase, but haven't released v1.0.0! Ruff hasn't even got as far as v0.1.0.

[0]: https://techcrunch.com/2023/02/16/sequoia-backs-open-source-...

Re: Astral

#93
Is anyone else sick of seeing "yet another" Python tool? Python is so slow and irrelevant by so many standards nowadays...

Fully prepared to be downvoted for these because I am all too aware of Python's (IMO) undeserved popularity, but the facts are clear: Python lags in performance against nearly any other "backend" or "scripting" language (compare to C, C++, C#, Go, Rust, and many more)

My reasoning: every day I see stack overflow filled with repetitive Python questions, and random finance furus talking about their cool data analysis tools, all in Python, all with poor performance and hacked together with god knows how many libraries.

The problem is indeed because Python is so accessible: anyone who can write Python doesn't know enough about computing in general to even know what the concept of performance is, let alone risks of relying on 1903287012 libraries to get the job done.

Hell, I know half a dozen companies still using Python 2... jeez

Thanks for coming to my TED rant.

Re: Astral

#94
I agree with all of the naysayers here.

Speed is not my problem today, so what's the point if it's not solving my personal problem? Speed was my problem yesterday, and probably will be again tomorrow, but today it isn't and I don't know why random people I don't know aren't invested enough in solving my today problem.

Even worse, they're trying to get paid for it!

Seriously: what does it take to impress people? A mere 1000x speed increase and single point of configuration isn't good enough? Personally, I've waited for my much slower tools to finish plenty of times, I've only run a subset of the tools because I didn't want to wait for all of them to finish every time, and I've avoided configuring them because I'd have to figure out which one does what and how to configure each one.

Yes, it's a rearchitecture, which brings with it the pain of rearchitectures—mainly not supporting the bespoke tools built with the old architecture—but isn't it a good idea to identify when the existing base is problematic and be able to demonstrate that a superior solution could be gained by starting over? And they've even gone to the effort of bringing in the 90% case by encompassing the functionality of several existing tools!

I would understand the complaints better if you were somehow suddenly unable to run any of your existing stuff, but this isn't an incompatible upgrade to an existing project.

Re: Astral

#95

I think HN should ban people who are too lazy to put a proper subject line on their post. I mean, "Astral" .... what's that ? The "astral.sh" domain doesn't tell me anything either. I'm sure those in the know automatically know what it is, but for the rest of us, the title is completely and utterly meaningless.

Agreed. I have a policy of _never_ clicking on a link if I don't have at least _some_ idea of what's behind it, and that includes HN. It's the top link on HN right now and I came to the comments just to see what it was even about.

And yes, I have regretted clicking on HN links before.

Re: Astral

#96

I think HN should ban people who are too lazy to put a proper subject line on their post. I mean, "Astral" .... what's that ? The "astral.sh" domain doesn't tell me anything either. I'm sure those in the know automatically know what it is, but for the rest of us, the title is completely and utterly meaningless.

Banning is a little extreme, but I agree that title is unhelpful. Better title would be "Ruff is a fast Python linter written in Rust" (which is a slight paraphrase from one of the subheads).

Re: Astral

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

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.

Re: Astral

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

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 established, but it's terribly slow running from scratch.

Post reply on HN