30 ms·

Astral

1078 points by hasheddan 4y ago

SirChud 4y ago
Testing do i be shadowbannered
petrusnonius 4y ago
Is there a similar endeavour for Ruby?
voidfunc 4y ago
Yet another linter.
slekker 4y ago
What’s in the roadmap for what will be built by Astral?
kitanata 4y ago
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?
- paulgb 4y ago
  > What is the point of making every half decent Developer tool a whole startup? I mean, paying people who work on it, for one?
  - kitanata 4y ago
    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.
    - paulgb 4y ago
      Python has become a hugely critical language for science, AI/ML, finance, etc. and the current state of tooling has lagged the language's importance. I can think of lots of ways a company that solves that problem could add adjacent products and monetize them. Enterprise support, tooling for building and deploying custom lint rules, supply-chain security, managed builds, etc.
    - VWWHFSfQ 4y ago
      > 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.
      - rwalle 4y ago
        Maybe your answer is correct but it is not useful, at all. It does not answer the question, like, providing real solutions.
        deleted 4y ago
        [deleted]
- BiteCode_dev 4y ago
  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.
  - overthrow 4y ago
    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?
    - BiteCode_dev 4y ago
      I don't know their plan, so I can't speak for them. What I would do is build an entire ecosystem of that quality that would include a tool to solve the Python distributions problem. Either you help with deployment on the server, and you offer hosting. Or you help with making an installer, and you offer nodes to build installers for multiple OS and upload to multiple app stores, manage updates, cdn, permissions... You can even start small and just help with a service for cross-compiling C extensions and scale from that. Or provide machine learning analysis of the quality of your code and make companies pay for it. Or go full Continuum. They are good enough that they can pick and choose whatever they want, really. When you solve pain, people pay. If readthedoc managed to survive by being a static rst site, astral has a shot provided they keep the business side of things in mind as nicely as they build their user stories.
    - VWWHFSfQ 4y ago
      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.
- M3L0NM4N 4y ago
  I agree, but I also don't make the decision. The free market decides whether their value proposition is enough, so the company's success is dependent on the developer demand.
- motbus3 4y ago
  I agree with you. On the other hand, if you build something cool you may want to make some money... The problem imo, is changing the speech in the middle of the way, aham openai
- swyx 4y ago
  this is too narrowly focused on what Ruff does today and not enough on what it could do for the Python ecosystem as a whole. his focus and clear execution has built an incredible wedge and brand, and his next product will probably be well received, and the next, and the next. the opportunity to bring speed and sanity to the whole Python Ecosystem tooling is large (if you dont feel the pain, you don't do enough python) and honestly i cant belive anyone has been (crazy enough) to try this since Anaconda.
- qudat 4y ago
  I'm inclined to agree and when they eventually die, what happens to the tool they built? I've been using https://rome.tools https://rome.tools and really love the work they put into it. It's clear they had people working fulltime on it. But now, what? The code is open-source, there are people working on it, but development has mostly dropped off. I guess that's okay? It just adds a lot of doubt into the longevity of the project. I'd be wary adding these tools into your stack because their progress relies pretty heavily on VC funding and a tight runway to profitability.
- kvathupo 4y ago
  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.
  - ohmahjong 4y ago
    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.
    - davidhalter 4y ago
      I'm currently speeding up Mypy + Jedi in Rust. I'm pretty far already and it's definitely a lot faster. Tests are currently running 500 times faster than Mypy.
    - mixmastamyk 4y ago
      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.
akprasad 4y ago
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 that since Ruff is an all-in-one tool, it can parse the underlying Python files just once -- and since this is the most expensive phase of these kinds of tools, adding any extra functionality on top (such as linting, formatting, ...) is very cheap. And that's to say nothing of the fact that Ruff is built on Rust, with the usual performance wins that Rust projects tend to have. I'm a little apprehensive of how development will look given a VC raise with the expectation of VC returns. But for now, I'm delighted and can't wait to see what the team comes up with. [1]: https://github.com/charliermarsh/ruff/issues/1904 https://github.com/charliermarsh/ruff/issues/1904
- swyx 4y ago
  if it's any consolation, Accel is in my mind one of the "good ones". they have a record of backing "good" devtool companies that manage open source and commercial concerns well - Vercel, Sentry, etc. (i'm sure theres more, those are just the two that i'm closest to)
  - echelon 4y ago
    What are the good VC companies? Not just for dev tools, but in general. Where do you find this information?
    - swyx 4y ago
      just being "in the scene" for a few years :) tbh i care more about individual investors than the fund brand, but its a fallback whenever meeting someone new edit: https://overcast.fm/+t_0aYbn-o/12:00 https://overcast.fm/+t_0aYbn-o/12:00 listen to steve krouse talk about how accel encouraged him for val.town even tho he didnt initially believe in it himself. thats not normal investor behavior. look out for people like that, by definition they are rare
danpalmer 4y ago
Having written a bunch of Flake8 plugins, including custom plugins for internal use at a company, and using 5-10 popular plugins on every Python project I work on... rewriting the entire linting ecosystem in one monolithic Rust tool doesn't feel like the best solution. There's no good story for building an ecosystem around this yet, and I think that's a big hurdle to overcome. Ruff is fast, sure, but the benchmarking seems a little disingenuous, as I believe their number includes caching, but doesn't necessarily include caching for other tools. In fairness, not all the other tools have caching, but it is common to run them through pre-commit and therefore only on the current git diff, which speeds them up by orders of magnitude.
- qbasic_forever 4y ago
  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.
  - danpalmer 4y ago
    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 try to speed those up (which could be done in a number of ways), Ruff started from scratch. It doesn't feel like the right decision for an ecosystem that is as community focused as Python, and the engineering reasons feel like a toss up at best.
    - qbasic_forever 4y ago
      ??? 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 that aren't you. Kinda just sounds like you're grousing because somebody moved the cheese.
divan 4y ago
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?
- int_19h 4y ago
  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.
- qbasic_forever 4y ago
  It's linting the entire CPython codebase and standard library, which is quite large (possibly one of the largest python codebases). But yes, pure python linters will be inherently quite a bit slower than a native implementation. The point of ruff is that it's so fast you forget or never even notice it's running. Every change, every little modification, etc. should always be linted with near instant feedback.
- overthrow 4y ago
  I worked on a 50k-100k loc python codebase where the linters took a full minute to run if you deleted your cache. And I did try to optimize it. I wouldn't be surprised if that's normal.
ur-whale 4y ago
What is it beyond a linter. Also: speed is good, but when it comes to linting, that's not what I'd place first as a feature. How good is the code at spotting my potential mistakes would come before speed for sure. Hence: it's fast, but is it in any way better than the other solutions out there?
BiteCode_dev 4y ago
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.
- swyx 4y ago
  > 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?
  - BiteCode_dev 4y ago
    Eating at a restaurant: - "This chef is a great cook!" - "How do you know, have you looked inside the kitchen?"
    - ZephyrBlu 4y ago
      Code is not food. You can create a great product with shit code (Or just mediocre code!). Does that make someone a good dev, or a bad dev? How you come to the conclusion he's "just a damn good developer" is a very fair question.
      - ashtonbaker 4y ago
        I think it's actually basically the same. Being a clean, organized cook is probably positively correlated with making good food, but it's not strictly necessary. If someone is writing sloppy code but shipping a project of this overall quality without leaking the "low quality" of their implementation, then I wouldn't presume to call them a "bad dev" - I would probably conclude that they're more efficient than I am at prioritizing where to spend organizational energy.
      - BiteCode_dev 4y ago
        In this analogy, the food is the entire project, and a dev does much more than coding. You can do one thing right with luck, you can't do most things right by luck alone. The guy is fluent in 2 languages, one being known to be hard to master, create a tool that replace several others, get adopted in months by half the community, welcome 172 contributors on a project that is parsing stuff, a hard problem. Also the doc is good. As a professional dev, I never get all those right. Never. So yes, the food is good, and the chef is excellent to get all that stuff right.
rtuin 4y ago
Perfect timing, I’m excited to what Astral will bring. The python ecosystem keeps building momentum as “doing things with data” becomes bigger, more accessible, and also more (near) real-time and I think the ecosystem would really thrive with better, unambiguous tools that become de facto to the community of builders instead of plenty of suboptimal ones to choose from.
andy_xor_andrew 4y ago
In the last few weeks I've been using Python to play with some LLMs locally, and at first I thought there was some bug in VS Code because the linting was so slooooooow. This seems long overdue! Looks like a great project :)
neves 4y ago
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.
- kstrauser 4y ago
  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.
  - mixmastamyk 4y ago
    Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.
    - kstrauser 4y ago
      That’s not true unless you have a dependency map between all modules. (Note: that’s what I did in pytest-fastest to only retest modules that had changed, or that imported modules that had changed.) Otherwise, if you rename a function, you wouldn’t know what all broke.
      - mixmastamyk 4y ago
        You don’t need to check everything, every time. (Another case of yours is when you want all types checked.) Good time for a full check is when new feature is complete. Run all linters, typers, and full test suite, until clear. Then commit and push.
sergiotapia 4y ago
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.
hn_throawlles 4y ago
[flagged]
zephraph 4y ago
Congrats Charlie! Excited to see you launch and I wish you the best. Ruff is awesome and y'all are doing great work.
hardwaregeek 4y ago
I'm glad people are continuing the promise of Rome. High quality, high performance programming language tooling is a great mission and very much an unsolved problem. And tbh, the Python ecosystem is a great space. There's plenty to be built.
traceroute66 4y ago
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.
- rochak 4y ago
  +1. Comes across as a bad attempt at gaining publicity.
- bityard 4y ago
  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.
- Zanni 4y ago
  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).
  - 1f60c 4y ago
    Or "Ruff creators found Astral Software Inc." or something.
    - ricardobeat 4y ago
      Editoralizing is discouraged and your post will end up edited to match the original URL’s title either way.
  - swyx 4y ago
    especially when it doesnt seem to be the ruff founder who submitted this particular post. maybe dang or someone will rename it something more appropriate but from hn comments its pretty clear what the context is
kleaver 4y ago
I wonder if the eventual goal of this is similar to deno, where it's about building really good, no-hassle tooling/ecosystem for a language and then making it very simple to deploy/host (if I'm misspeaking about deno please correct me, I'm not well versed on it). One thing I like most about Go is actually the Go tool; having a ubiquitous linter, formatter, test framework, dependency management, etc, all built in and not having to install various tools is huge imo. I think a lot of languages are missing this ease of tooling. I think (?) this is what deno/astral is trying to address for javascript/python and then the business model is once you're using it, it's simple to host with them. Curious what other think
senko 4y ago
I am at once: - happy because Ruff deserves full time focus and having a team that can focus on tooling as their main product (not a nights&weekends hobby) is a clear win for everyone; but also - concerned because VC is not charity, and this must surely come with strings attached (in terms of future growth); I haven't seen many VCs aiming for "sustainable profitable business providing great value for the community" type exits; then again, if this turns into a Hashicorp-type story that wouldn't be too bad an outcome either
singhrac 4y ago
I cannot comment on the feasibility of building a profitable open source business around Python tooling, but I can say that I'm very very glad someone is taking that risk: both Charlie in career/business risks, and the VCs in taking on the financial risk. I just get to benefit - ruff is really nice and I anticipate big improvements to Python tooling as a result, at no cost to me.
jfb 4y ago
If they can get a good type checker in ruff, or produce one as comparably better than mypy than ruff is from pre-existing tools ... well.
dzonga 4y ago
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
- Waterluvian 4y ago
  Hopefully. But oftentimes the result is people just use more of something when it's cheaper.
  - gooseyman 4y ago
    Ah yes! https://en.m.wikipedia.org/wiki/Jevons_paradox https://en.m.wikipedia.org/wiki/Jevons_paradox
  - digging 4y ago
    A bit optimistic to say "sometimes" IMO
- Thaxll 4y ago
  This is a drop in the ocean, and really not saving anything meaningful.
- mdaniel 4y ago
  heh, I would actually be curious about that environment claim when one balances the amount of power consumed by compiling rust; i.e. the savings for its users balanced against the horrific amount of wattage drawn on the developer's workstations or cloud or ci servers I now have to compile Firefox overnight because I can no longer compile it and do something else with my (core i7) laptop simultaneously
- Mawr 4y ago
  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.
prisonguard 4y ago
nowadays, it's cool to say this new toy is faster than the rest because it is written in Rust without providing further details? When I visit the Bun project landing page[0], I get concise reasons as to why bun is faster than its peers. [0] https://bun.sh/ https://bun.sh/
- stavros 4y ago
  > nowadays, it's cool to say this new toy is faster than the rest because it is written in Rust without providing further details? What more details do you want? You run it, and it runs in milliseconds rather than seconds. I don't care if it's because it's written in Rust or because they sacrificed a goat to Baal, I care that it's fast.
- mrkeen 4y ago
  > nowadays, it's cool to say this new toy is faster than the rest because it is written in Rust without providing further details? It's usually true, too.
bbkane 4y ago
Super excited about ruff improvements, but I gotta comment that the CSS for a clicked link in astral.sh looks like normal text. I clicked a link, hit back in Android Firefox, and couldn't find the link again.
fnetisma 4y ago
I'm trying to use this via ssh into another instance on VSCode, but it doesn't work, any help?
theusus 4y ago
Does it support type inference and stuff?
- neuronexmachina 4y ago
  https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-mypy-or-pyright-or-pyre https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-mypy... > Ruff is a linter, not a type checker. It can detect some of the same problems that a type checker can, but a type checker will catch certain errors that Ruff would miss. The opposite is also true: Ruff will catch certain errors that a type checker would typically ignore. ...
mhh__ 4y ago
Although I'm sure it is faster, comparing "Linting" speeds as a Blackbox strikes me as bullshit artistry (for any language other than python perhaps)
colincooke 4y ago
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-data-validation-framework-pydantic-to-commercialize-with-cloud-services/ https://techcrunch.com/2023/02/16/sequoia-backs-open-source-...
- amlozano 4y ago
  You aren't the only one that has noticed: https://0ver.org/ https://0ver.org/ More seriously though, for these projects, the first version is version zero. If they make no major backward incompatible changes, why would they ever release a version 1?
  - rokob 4y ago
    Because version 1 is the first version with any actual guarantees: https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4
fullstackchris 4y ago
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.
sfink 4y ago
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. </rant>
- mrkeen 4y ago
  > I agree with all of the naysayers ... Speed is not my problem today > A mere 1000x speed increase and single point of configuration isn't good enough? > this isn't an incompatible upgrade I genuinely can't understand if you are for or against this tool.
  - intellix 4y ago
    He's being extremely sarcastic. He's massively for it
  - deleted 4y ago
    [deleted]
  - tempaccount420 4y ago
    The user expresses their frustration with the critics by sarcastically asking what it would take to impress them. They believe that the new technology offers significant benefits and that the complaints seem unjustified.
PaulHoule 4y ago
Python needs something like pip and poetry that is (1) correct, and (2) faster than poetry.
- claytonjy 4y ago
  This might be Pyflow, written in rust: https://www.github.com/David-OConnor/pyflow https://www.github.com/David-OConnor/pyflow
  - mbwgh 4y ago
    Thanks for mentioning this, wasn't aware of this potential alternative to poetry (which I keep making mistakes with, since I only use it every few months or so).
anilshanbhag 4y ago
I really hope they develop a faster mypy. In my dev workflows, mypy takes most of the time. Linting is a small fraction of it.
- davidhalter 4y ago
  I'm currently speeding up Mypy + Jedi in Rust. I'm pretty far already and it's definitely a lot faster. Tests are currently running 500 times faster than Mypy.
hkt 4y ago
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.
- ikornaselur 4y ago
  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.
  - hkt 4y ago
    > 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.
- akx 4y ago
  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 https://github.com/home-assistant/core/pull/86224 by yours truly.)
  - hkt 4y ago
    That's a great point. The GWP of computation is hugely underappreciated. (Also, nice work!)
ossusermivami 4y ago
they sure know how to make a website! quite a change from ye old README.md
korijn 4y ago
If your codebase is as large as cpython's, I think the benefits are clear. But most projects aren't actually this big right? Flake8 runs less than a second on even my biggest projects. Is linting such a bottleneck in people's workflows? Why bother shaving a couple seconds off a linter when your test suite and Dockerfiles take minutes to complete? I don't really see why I should care about ruff.
- ki_ 4y ago
  If both run under 500ms. I guess it's your choice. Just pick the one that's most productive for you. If flake8 takes longer than 1 second, i'd replace it with ruff. 1 second is a really really long time for a linter, even if your codebase is 1 million lines of code.
throwaway2137 4y ago
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 jupyter notebook you start dealing with stupid problems like - venv - no standard package manager, dependency resolution taking forever - multiprocessing - untyped libraries (looking at you boto) - `which python` - wsgi - CLI debugging et cetera. I'm currently working daily with Python, and compared to the .NET world I'm coming from, it's MINDBLOWING how many things are annoying here. In my previous job I was able to spend several years working on a C# app barely ever needing to touch the terminal, everything came with batteries included, tooling / autocompletion / package management / performance / time spent on dealing with little issues was REALLY good in comparison. Reason I moved is that it's hard to find a job in C# which isn't soul sucking stuff like banking / maintainance / insurance, so I'm dealing with it as the project is interesting at least.
- int_19h 4y ago
  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.
- Tossrock 4y ago
  Roblox is a big C# shop that's pretty fun - platform tech in the gaming space. And hiring!
- robswc 4y ago
  >It really boggles my mind why is this lang so popular a lot of problems can be solved well with python. The frameworks are also priceless. What is an alternative to Django, for example? Nearly every backend service I create is with python, unless it needs speed or rock-solid reliability. For that I use Go. Dynamic UI/UX I use nextjs with python backend.
thelonelygod 4y ago
Does anyone have recommendations for a good jinja linter?
haolez 4y ago
I hope they eventually attack package management and easy static bundling. It would make Python more attractive for people coming from other ecosystems.
- claytonjy 4y ago
  I wonder if they'll try to bring in Pyflow¹, a rust-based python package manager, under the Astral banner. Could make a lot of sense! ¹: https://www.github.com/David-OConnor/pyflow https://www.github.com/David-OConnor/pyflow
TheAlchemist 4y ago
Don't have an opinion about it yet, but I love the website - it's really fast !
- clivestaples 4y ago
  The site is very well done and impressed me too. It's built with Next and noticed Astral is backed by Guillermo Rauch himself.
nichochar 4y ago
Seems cool but i wish they had an auto-formatter. After years of coding, I have found that taking away the opinionated-ness and doing a format-on-save (ideally, that's supported by the language like Golang) is by far the most productive. I'm sad that python is still prevalent everywhere, given how terrible the language and its tooling is, but it seems it's not going away with the A.I wave, so companies like this will become more valuable.
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]
jonthepirate 4y ago
Somehow, ruff is linting my entire codebase 350x faster than pylint did.
almostdigital 4y ago
This is great, I'm going to switch to this from black. Being used to working in other languages I feel like I'm swimming in molasses when using Python. It's funny that all good things for Python are not written in Python. Says a lot about the language.
- sfink 4y ago
  It doesn't replace black, at least not yet. It sounds like autoformatting is planned.
  - almostdigital 4y ago
    Yeah, just realized that and was about to edit my comment. Found an issue tracking the black replacement bit: https://github.com/charliermarsh/ruff/issues/1904 https://github.com/charliermarsh/ruff/issues/1904
lchengify 4y ago
User of Ruff here and follower of Charlie's work. I've been slinging python since 2003, and I've used a pretty wide swath of the toolchain. I've also had the (pleasure?) of using python in a lot of different contexts: desktop applications, web programming, custom scientific calculation plugins, grad school hacks, Maya, and obviously Juypter notebooks. My honest take: Toolchain tools like Ruff are the only way the Python ecosystem as a whole moves forward. In order to be broadly adopted by the wide swath of use cases, it needs to be universally applicable and have a killer reason for being (in this case, speed, which opens up new use cases that didn't exist before). Ironically, the commonality to these toolchain improvements for python ... is that they not be written in Python. If you want good analogues, you can look at the work that others have done with multithreading and trying to bypass the GIL, which is one of my other hobby horses with Python. Hot take: For most users, python is not used for itself, but more to flexibly orchestrate some other low-level problem. This is why Maya, scipy, most of data science, and other DSLs use python so much. To empower these users, you either need to (1) work in the compiler (2) below the GIL or (3) do the heavy lifting of wrapping around the language flexibility without requiring changing the python code itself. Ruff does that, and I imagine the thesis of Astral is to extend that philosophy to the rest of the toolchain. Lastly, in the spirit of this site, I'll give my second spicy take: I think web development in python is on the decline, and the future of python is in data science and related fields. These fields care a lot about fast toolchain, and will use ruff and other tools to achieve those ends without modifying legacy code. For web, node has won. I know users that use python but you can't really beat needing to learn just one language vs two to build a web app.
- coldtea 4y ago
  >Hot take: For most users, python is not used for itself, but more to flexibly orchestrate some other low-level problem. Well, there's nothing wrong with that. In fact, a great "glue language" (and Python sure needs lots of improvements in many areas) is kind of the holy grail of IT!
  - lchengify 4y ago
    Ha! And I remember when Perl was the default "glue language". It's been a long time since I've seen Perl, I bet it's still kicking around somewhere but I doubt they teach it in undergrad anymore.
Aeolun 4y ago
Good for him. I’m less enthusiastic about them hiring one of the core contributors of Rome away though. I don’t care about Python, but I very much care about Typescript.
garfieldnate 4y ago
I'm surprised PyLance isn't in the list of linters that they benchmarked. It's the fastest one by far, in my experience, and it's conveniently available in the VSCode Python plugin.
- aobdev 4y ago
  Just pointing out that Pylance is a VSCode wrapper around Pyright, which is a static type checker with no primary linting features. The separate VSCode Python plugin however integrates with pylint, flake8, pylama, bandit, etc. and I agree that it is very good.
gunshai 4y ago
I do a fair amount of python scripting but I don't work on code bases or anything. Can someone help me along what this tool would help me with? I think I've been stuck in the scripting world for far too long. Edit: .... oh I've been using one of these for ages and didn't even realize it.
woea 4y ago
How are they going to make money?
ea550ff70a 4y ago
just tried. damn it is fast.
sertsa 4y ago
Already is a python package named Astral: https://sffjunkie.github.io/astral/ https://sffjunkie.github.io/astral/
canadiantim 4y ago
How well would this mix with something like fastapi?
sandGorgon 4y ago
OT...but brilliant site design. compliments.
vrglvrglvrgl 4y ago
[dead]

Astral

1078 points by hasheddan 4y ago

SirChud 4y ago

Testing do i be shadowbannered

petrusnonius 4y ago

Is there a similar endeavour for Ruby?

voidfunc 4y ago

Yet another linter.

slekker 4y ago

What’s in the roadmap for what will be built by Astral?

kitanata 4y ago

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?

paulgb 4y ago
> What is the point of making every half decent Developer tool a whole startup? I mean, paying people who work on it, for one?
- kitanata 4y ago
  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.
  - paulgb 4y ago
    Python has become a hugely critical language for science, AI/ML, finance, etc. and the current state of tooling has lagged the language's importance. I can think of lots of ways a company that solves that problem could add adjacent products and monetize them. Enterprise support, tooling for building and deploying custom lint rules, supply-chain security, managed builds, etc.
  - VWWHFSfQ 4y ago
    > 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.
    - rwalle 4y ago
      Maybe your answer is correct but it is not useful, at all. It does not answer the question, like, providing real solutions.
      - deleted 4y ago
        [deleted]
BiteCode_dev 4y ago
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.
- overthrow 4y ago
  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?
  - BiteCode_dev 4y ago
    I don't know their plan, so I can't speak for them. What I would do is build an entire ecosystem of that quality that would include a tool to solve the Python distributions problem. Either you help with deployment on the server, and you offer hosting. Or you help with making an installer, and you offer nodes to build installers for multiple OS and upload to multiple app stores, manage updates, cdn, permissions... You can even start small and just help with a service for cross-compiling C extensions and scale from that. Or provide machine learning analysis of the quality of your code and make companies pay for it. Or go full Continuum. They are good enough that they can pick and choose whatever they want, really. When you solve pain, people pay. If readthedoc managed to survive by being a static rst site, astral has a shot provided they keep the business side of things in mind as nicely as they build their user stories.
  - VWWHFSfQ 4y ago
    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.
M3L0NM4N 4y ago
I agree, but I also don't make the decision. The free market decides whether their value proposition is enough, so the company's success is dependent on the developer demand.
motbus3 4y ago
I agree with you. On the other hand, if you build something cool you may want to make some money... The problem imo, is changing the speech in the middle of the way, aham openai
swyx 4y ago
this is too narrowly focused on what Ruff does today and not enough on what it could do for the Python ecosystem as a whole. his focus and clear execution has built an incredible wedge and brand, and his next product will probably be well received, and the next, and the next. the opportunity to bring speed and sanity to the whole Python Ecosystem tooling is large (if you dont feel the pain, you don't do enough python) and honestly i cant belive anyone has been (crazy enough) to try this since Anaconda.
qudat 4y ago
I'm inclined to agree and when they eventually die, what happens to the tool they built? I've been using https://rome.tools https://rome.tools and really love the work they put into it. It's clear they had people working fulltime on it. But now, what? The code is open-source, there are people working on it, but development has mostly dropped off. I guess that's okay? It just adds a lot of doubt into the longevity of the project. I'd be wary adding these tools into your stack because their progress relies pretty heavily on VC funding and a tight runway to profitability.
kvathupo 4y ago
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.
- ohmahjong 4y ago
  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.
  - davidhalter 4y ago
    I'm currently speeding up Mypy + Jedi in Rust. I'm pretty far already and it's definitely a lot faster. Tests are currently running 500 times faster than Mypy.
  - mixmastamyk 4y ago
    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.

akprasad 4y ago

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 that since Ruff is an all-in-one tool, it can parse the underlying Python files just once -- and since this is the most expensive phase of these kinds of tools, adding any extra functionality on top (such as linting, formatting, ...) is very cheap. And that's to say nothing of the fact that Ruff is built on Rust, with the usual performance wins that Rust projects tend to have. I'm a little apprehensive of how development will look given a VC raise with the expectation of VC returns. But for now, I'm delighted and can't wait to see what the team comes up with. [1]: https://github.com/charliermarsh/ruff/issues/1904 https://github.com/charliermarsh/ruff/issues/1904

swyx 4y ago
if it's any consolation, Accel is in my mind one of the "good ones". they have a record of backing "good" devtool companies that manage open source and commercial concerns well - Vercel, Sentry, etc. (i'm sure theres more, those are just the two that i'm closest to)
- echelon 4y ago
  What are the good VC companies? Not just for dev tools, but in general. Where do you find this information?
  - swyx 4y ago
    just being "in the scene" for a few years :) tbh i care more about individual investors than the fund brand, but its a fallback whenever meeting someone new edit: https://overcast.fm/+t_0aYbn-o/12:00 https://overcast.fm/+t_0aYbn-o/12:00 listen to steve krouse talk about how accel encouraged him for val.town even tho he didnt initially believe in it himself. thats not normal investor behavior. look out for people like that, by definition they are rare

danpalmer 4y ago

Having written a bunch of Flake8 plugins, including custom plugins for internal use at a company, and using 5-10 popular plugins on every Python project I work on... rewriting the entire linting ecosystem in one monolithic Rust tool doesn't feel like the best solution. There's no good story for building an ecosystem around this yet, and I think that's a big hurdle to overcome. Ruff is fast, sure, but the benchmarking seems a little disingenuous, as I believe their number includes caching, but doesn't necessarily include caching for other tools. In fairness, not all the other tools have caching, but it is common to run them through pre-commit and therefore only on the current git diff, which speeds them up by orders of magnitude.

qbasic_forever 4y ago
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.
- danpalmer 4y ago
  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 try to speed those up (which could be done in a number of ways), Ruff started from scratch. It doesn't feel like the right decision for an ecosystem that is as community focused as Python, and the engineering reasons feel like a toss up at best.
  - qbasic_forever 4y ago
    ??? 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 that aren't you. Kinda just sounds like you're grousing because somebody moved the cheese.

divan 4y ago

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?

int_19h 4y ago
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.
qbasic_forever 4y ago
It's linting the entire CPython codebase and standard library, which is quite large (possibly one of the largest python codebases). But yes, pure python linters will be inherently quite a bit slower than a native implementation. The point of ruff is that it's so fast you forget or never even notice it's running. Every change, every little modification, etc. should always be linted with near instant feedback.
overthrow 4y ago
I worked on a 50k-100k loc python codebase where the linters took a full minute to run if you deleted your cache. And I did try to optimize it. I wouldn't be surprised if that's normal.

ur-whale 4y ago

What is it beyond a linter. Also: speed is good, but when it comes to linting, that's not what I'd place first as a feature. How good is the code at spotting my potential mistakes would come before speed for sure. Hence: it's fast, but is it in any way better than the other solutions out there?

BiteCode_dev 4y ago

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.

swyx 4y ago
> 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?
- BiteCode_dev 4y ago
  Eating at a restaurant: - "This chef is a great cook!" - "How do you know, have you looked inside the kitchen?"
  - ZephyrBlu 4y ago
    Code is not food. You can create a great product with shit code (Or just mediocre code!). Does that make someone a good dev, or a bad dev? How you come to the conclusion he's "just a damn good developer" is a very fair question.
    - ashtonbaker 4y ago
      I think it's actually basically the same. Being a clean, organized cook is probably positively correlated with making good food, but it's not strictly necessary. If someone is writing sloppy code but shipping a project of this overall quality without leaking the "low quality" of their implementation, then I wouldn't presume to call them a "bad dev" - I would probably conclude that they're more efficient than I am at prioritizing where to spend organizational energy.
    - BiteCode_dev 4y ago
      In this analogy, the food is the entire project, and a dev does much more than coding. You can do one thing right with luck, you can't do most things right by luck alone. The guy is fluent in 2 languages, one being known to be hard to master, create a tool that replace several others, get adopted in months by half the community, welcome 172 contributors on a project that is parsing stuff, a hard problem. Also the doc is good. As a professional dev, I never get all those right. Never. So yes, the food is good, and the chef is excellent to get all that stuff right.

rtuin 4y ago

Perfect timing, I’m excited to what Astral will bring. The python ecosystem keeps building momentum as “doing things with data” becomes bigger, more accessible, and also more (near) real-time and I think the ecosystem would really thrive with better, unambiguous tools that become de facto to the community of builders instead of plenty of suboptimal ones to choose from.

andy_xor_andrew 4y ago

In the last few weeks I've been using Python to play with some LLMs locally, and at first I thought there was some bug in VS Code because the linting was so slooooooow. This seems long overdue! Looks like a great project :)

neves 4y ago

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.

kstrauser 4y ago
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.
- mixmastamyk 4y ago
  Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.
  - kstrauser 4y ago
    That’s not true unless you have a dependency map between all modules. (Note: that’s what I did in pytest-fastest to only retest modules that had changed, or that imported modules that had changed.) Otherwise, if you rename a function, you wouldn’t know what all broke.
    - mixmastamyk 4y ago
      You don’t need to check everything, every time. (Another case of yours is when you want all types checked.) Good time for a full check is when new feature is complete. Run all linters, typers, and full test suite, until clear. Then commit and push.

sergiotapia 4y ago

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.

hn_throawlles 4y ago

[flagged]

zephraph 4y ago

Congrats Charlie! Excited to see you launch and I wish you the best. Ruff is awesome and y'all are doing great work.

hardwaregeek 4y ago

I'm glad people are continuing the promise of Rome. High quality, high performance programming language tooling is a great mission and very much an unsolved problem. And tbh, the Python ecosystem is a great space. There's plenty to be built.

traceroute66 4y ago

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.

rochak 4y ago
+1. Comes across as a bad attempt at gaining publicity.
bityard 4y ago
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.
Zanni 4y ago
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).
- 1f60c 4y ago
  Or "Ruff creators found Astral Software Inc." or something.
  - ricardobeat 4y ago
    Editoralizing is discouraged and your post will end up edited to match the original URL’s title either way.
- swyx 4y ago
  especially when it doesnt seem to be the ruff founder who submitted this particular post. maybe dang or someone will rename it something more appropriate but from hn comments its pretty clear what the context is

kleaver 4y ago

I wonder if the eventual goal of this is similar to deno, where it's about building really good, no-hassle tooling/ecosystem for a language and then making it very simple to deploy/host (if I'm misspeaking about deno please correct me, I'm not well versed on it). One thing I like most about Go is actually the Go tool; having a ubiquitous linter, formatter, test framework, dependency management, etc, all built in and not having to install various tools is huge imo. I think a lot of languages are missing this ease of tooling. I think (?) this is what deno/astral is trying to address for javascript/python and then the business model is once you're using it, it's simple to host with them. Curious what other think

senko 4y ago

I am at once: - happy because Ruff deserves full time focus and having a team that can focus on tooling as their main product (not a nights&weekends hobby) is a clear win for everyone; but also - concerned because VC is not charity, and this must surely come with strings attached (in terms of future growth); I haven't seen many VCs aiming for "sustainable profitable business providing great value for the community" type exits; then again, if this turns into a Hashicorp-type story that wouldn't be too bad an outcome either

singhrac 4y ago

I cannot comment on the feasibility of building a profitable open source business around Python tooling, but I can say that I'm very very glad someone is taking that risk: both Charlie in career/business risks, and the VCs in taking on the financial risk. I just get to benefit - ruff is really nice and I anticipate big improvements to Python tooling as a result, at no cost to me.

jfb 4y ago

If they can get a good type checker in ruff, or produce one as comparably better than mypy than ruff is from pre-existing tools ... well.

dzonga 4y ago

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

Waterluvian 4y ago
Hopefully. But oftentimes the result is people just use more of something when it's cheaper.
- gooseyman 4y ago
  Ah yes! https://en.m.wikipedia.org/wiki/Jevons_paradox https://en.m.wikipedia.org/wiki/Jevons_paradox
- digging 4y ago
  A bit optimistic to say "sometimes" IMO
Thaxll 4y ago
This is a drop in the ocean, and really not saving anything meaningful.
mdaniel 4y ago
heh, I would actually be curious about that environment claim when one balances the amount of power consumed by compiling rust; i.e. the savings for its users balanced against the horrific amount of wattage drawn on the developer's workstations or cloud or ci servers I now have to compile Firefox overnight because I can no longer compile it and do something else with my (core i7) laptop simultaneously
Mawr 4y ago
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.

prisonguard 4y ago

nowadays, it's cool to say this new toy is faster than the rest because it is written in Rust without providing further details? When I visit the Bun project landing page[0], I get concise reasons as to why bun is faster than its peers. [0] https://bun.sh/ https://bun.sh/

stavros 4y ago
> nowadays, it's cool to say this new toy is faster than the rest because it is written in Rust without providing further details? What more details do you want? You run it, and it runs in milliseconds rather than seconds. I don't care if it's because it's written in Rust or because they sacrificed a goat to Baal, I care that it's fast.
mrkeen 4y ago
> nowadays, it's cool to say this new toy is faster than the rest because it is written in Rust without providing further details? It's usually true, too.

bbkane 4y ago

Super excited about ruff improvements, but I gotta comment that the CSS for a clicked link in astral.sh looks like normal text. I clicked a link, hit back in Android Firefox, and couldn't find the link again.

fnetisma 4y ago

I'm trying to use this via ssh into another instance on VSCode, but it doesn't work, any help?

theusus 4y ago

Does it support type inference and stuff?

neuronexmachina 4y ago
https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-mypy-or-pyright-or-pyre https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-mypy... > Ruff is a linter, not a type checker. It can detect some of the same problems that a type checker can, but a type checker will catch certain errors that Ruff would miss. The opposite is also true: Ruff will catch certain errors that a type checker would typically ignore. ...

mhh__ 4y ago

Although I'm sure it is faster, comparing "Linting" speeds as a Blackbox strikes me as bullshit artistry (for any language other than python perhaps)

colincooke 4y ago

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-data-validation-framework-pydantic-to-commercialize-with-cloud-services/ https://techcrunch.com/2023/02/16/sequoia-backs-open-source-...

amlozano 4y ago
You aren't the only one that has noticed: https://0ver.org/ https://0ver.org/ More seriously though, for these projects, the first version is version zero. If they make no major backward incompatible changes, why would they ever release a version 1?
- rokob 4y ago
  Because version 1 is the first version with any actual guarantees: https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4

fullstackchris 4y ago

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.

sfink 4y ago

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

mrkeen 4y ago
> I agree with all of the naysayers ... Speed is not my problem today > A mere 1000x speed increase and single point of configuration isn't good enough? > this isn't an incompatible upgrade I genuinely can't understand if you are for or against this tool.
- intellix 4y ago
  He's being extremely sarcastic. He's massively for it
- deleted 4y ago
  [deleted]
- tempaccount420 4y ago
  The user expresses their frustration with the critics by sarcastically asking what it would take to impress them. They believe that the new technology offers significant benefits and that the complaints seem unjustified.

PaulHoule 4y ago

Python needs something like pip and poetry that is (1) correct, and (2) faster than poetry.

claytonjy 4y ago
This might be Pyflow, written in rust: https://www.github.com/David-OConnor/pyflow https://www.github.com/David-OConnor/pyflow
- mbwgh 4y ago
  Thanks for mentioning this, wasn't aware of this potential alternative to poetry (which I keep making mistakes with, since I only use it every few months or so).

anilshanbhag 4y ago

I really hope they develop a faster mypy. In my dev workflows, mypy takes most of the time. Linting is a small fraction of it.

davidhalter 4y ago
I'm currently speeding up Mypy + Jedi in Rust. I'm pretty far already and it's definitely a lot faster. Tests are currently running 500 times faster than Mypy.

hkt 4y ago

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.

ikornaselur 4y ago
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.
- hkt 4y ago
  > 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.
akx 4y ago
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 https://github.com/home-assistant/core/pull/86224 by yours truly.)
- hkt 4y ago
  That's a great point. The GWP of computation is hugely underappreciated. (Also, nice work!)

ossusermivami 4y ago

they sure know how to make a website! quite a change from ye old README.md

korijn 4y ago

If your codebase is as large as cpython's, I think the benefits are clear. But most projects aren't actually this big right? Flake8 runs less than a second on even my biggest projects. Is linting such a bottleneck in people's workflows? Why bother shaving a couple seconds off a linter when your test suite and Dockerfiles take minutes to complete? I don't really see why I should care about ruff.

ki_ 4y ago
If both run under 500ms. I guess it's your choice. Just pick the one that's most productive for you. If flake8 takes longer than 1 second, i'd replace it with ruff. 1 second is a really really long time for a linter, even if your codebase is 1 million lines of code.

throwaway2137 4y ago

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 jupyter notebook you start dealing with stupid problems like - venv - no standard package manager, dependency resolution taking forever - multiprocessing - untyped libraries (looking at you boto) - `which python` - wsgi - CLI debugging et cetera. I'm currently working daily with Python, and compared to the .NET world I'm coming from, it's MINDBLOWING how many things are annoying here. In my previous job I was able to spend several years working on a C# app barely ever needing to touch the terminal, everything came with batteries included, tooling / autocompletion / package management / performance / time spent on dealing with little issues was REALLY good in comparison. Reason I moved is that it's hard to find a job in C# which isn't soul sucking stuff like banking / maintainance / insurance, so I'm dealing with it as the project is interesting at least.

int_19h 4y ago
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.
Tossrock 4y ago
Roblox is a big C# shop that's pretty fun - platform tech in the gaming space. And hiring!
robswc 4y ago
>It really boggles my mind why is this lang so popular a lot of problems can be solved well with python. The frameworks are also priceless. What is an alternative to Django, for example? Nearly every backend service I create is with python, unless it needs speed or rock-solid reliability. For that I use Go. Dynamic UI/UX I use nextjs with python backend.

thelonelygod 4y ago

Does anyone have recommendations for a good jinja linter?

haolez 4y ago

I hope they eventually attack package management and easy static bundling. It would make Python more attractive for people coming from other ecosystems.

claytonjy 4y ago
I wonder if they'll try to bring in Pyflow¹, a rust-based python package manager, under the Astral banner. Could make a lot of sense! ¹: https://www.github.com/David-OConnor/pyflow https://www.github.com/David-OConnor/pyflow

TheAlchemist 4y ago

Don't have an opinion about it yet, but I love the website - it's really fast !

clivestaples 4y ago
The site is very well done and impressed me too. It's built with Next and noticed Astral is backed by Guillermo Rauch himself.

nichochar 4y ago

Seems cool but i wish they had an auto-formatter. After years of coding, I have found that taking away the opinionated-ness and doing a format-on-save (ideally, that's supported by the language like Golang) is by far the most productive. I'm sad that python is still prevalent everywhere, given how terrible the language and its tooling is, but it seems it's not going away with the A.I wave, so companies like this will become more valuable.

deleted 4y ago
[deleted]

deleted 4y ago

[deleted]

jonthepirate 4y ago

Somehow, ruff is linting my entire codebase 350x faster than pylint did.

almostdigital 4y ago

This is great, I'm going to switch to this from black. Being used to working in other languages I feel like I'm swimming in molasses when using Python. It's funny that all good things for Python are not written in Python. Says a lot about the language.

sfink 4y ago
It doesn't replace black, at least not yet. It sounds like autoformatting is planned.
- almostdigital 4y ago
  Yeah, just realized that and was about to edit my comment. Found an issue tracking the black replacement bit: https://github.com/charliermarsh/ruff/issues/1904 https://github.com/charliermarsh/ruff/issues/1904

lchengify 4y ago

User of Ruff here and follower of Charlie's work. I've been slinging python since 2003, and I've used a pretty wide swath of the toolchain. I've also had the (pleasure?) of using python in a lot of different contexts: desktop applications, web programming, custom scientific calculation plugins, grad school hacks, Maya, and obviously Juypter notebooks. My honest take: Toolchain tools like Ruff are the only way the Python ecosystem as a whole moves forward. In order to be broadly adopted by the wide swath of use cases, it needs to be universally applicable and have a killer reason for being (in this case, speed, which opens up new use cases that didn't exist before). Ironically, the commonality to these toolchain improvements for python ... is that they not be written in Python. If you want good analogues, you can look at the work that others have done with multithreading and trying to bypass the GIL, which is one of my other hobby horses with Python. Hot take: For most users, python is not used for itself, but more to flexibly orchestrate some other low-level problem. This is why Maya, scipy, most of data science, and other DSLs use python so much. To empower these users, you either need to (1) work in the compiler (2) below the GIL or (3) do the heavy lifting of wrapping around the language flexibility without requiring changing the python code itself. Ruff does that, and I imagine the thesis of Astral is to extend that philosophy to the rest of the toolchain. Lastly, in the spirit of this site, I'll give my second spicy take: I think web development in python is on the decline, and the future of python is in data science and related fields. These fields care a lot about fast toolchain, and will use ruff and other tools to achieve those ends without modifying legacy code. For web, node has won. I know users that use python but you can't really beat needing to learn just one language vs two to build a web app.

coldtea 4y ago
>Hot take: For most users, python is not used for itself, but more to flexibly orchestrate some other low-level problem. Well, there's nothing wrong with that. In fact, a great "glue language" (and Python sure needs lots of improvements in many areas) is kind of the holy grail of IT!
- lchengify 4y ago
  Ha! And I remember when Perl was the default "glue language". It's been a long time since I've seen Perl, I bet it's still kicking around somewhere but I doubt they teach it in undergrad anymore.

Aeolun 4y ago

Good for him. I’m less enthusiastic about them hiring one of the core contributors of Rome away though. I don’t care about Python, but I very much care about Typescript.

garfieldnate 4y ago

I'm surprised PyLance isn't in the list of linters that they benchmarked. It's the fastest one by far, in my experience, and it's conveniently available in the VSCode Python plugin.

aobdev 4y ago
Just pointing out that Pylance is a VSCode wrapper around Pyright, which is a static type checker with no primary linting features. The separate VSCode Python plugin however integrates with pylint, flake8, pylama, bandit, etc. and I agree that it is very good.

gunshai 4y ago

I do a fair amount of python scripting but I don't work on code bases or anything. Can someone help me along what this tool would help me with? I think I've been stuck in the scripting world for far too long. Edit: .... oh I've been using one of these for ages and didn't even realize it.

woea 4y ago

How are they going to make money?

ea550ff70a 4y ago

just tried. damn it is fast.

sertsa 4y ago

Already is a python package named Astral: https://sffjunkie.github.io/astral/ https://sffjunkie.github.io/astral/

canadiantim 4y ago

How well would this mix with something like fastapi?

sandGorgon 4y ago

OT...but brilliant site design. compliments.

vrglvrglvrgl 4y ago

[dead]