9 ms·
Ruff: Python linter and code formatter written in Rust
- throwaway98231 2y agoAt this point I think even people trapped for two years on the International Space Station have heard about the Astral toolchain.
- thrdbndndn 2y agoAny more info about "Astral" the org? I've used ruff/uv for sure, but I never pay attention to Astral who is behind it.
- ericjmorey 2y agoVC funded organization. Not sure what their business model is yet.
- mrits 2y agoMaybe, I use uv and rust has been my primary language for several years. I have never heard of astral though.
- zahlman 2y agoAstral is the organization making uv. It's right there in the GitHub URL.
- mrits 2y agoHow do you read me comment and take away that I still dont know what Astral is? You acted like everyone had heard of it. My point is not even all the users of uv have.
- lmm 2y ago> How do you read me comment and take away that I still dont know what Astral is? The comment where you literally say "I have never heard of astral"? Gee, I wonder.
- zahlman 2y ago>How do you read me comment and take away that I still dont know what Astral is? From the comment I read, quoted directly: >I have never heard of astral though. If you meant "I only learned about Astral thanks to this post", then I pointed out how you might have found out by yourself before.
- hartator 2y agoAstral toolchain?
- zahlman 2y agoPython development tools produced by Astral (https://github.com/astral-sh https://github.com/astral-sh), primarily uv and ruff. GP is a complaint about how often people submit links to these projects. The resulting discussion tends not to produce any new insight and the most common points IMX are "it's fast because it's written in Rust" (which is fairly specious logic - most problems with existing native Python tools are due to algorithmic problems such as poorly designed caching) or "it avoids bootstrapping problems because it's not written in Python" (it's completely possible to avoid those problems for everything except actually provisioning the Python interpreter, which some people apparently do see as a killer feature).
- fastball 2y agoSome previous discussions: https://news.ycombinator.com/item?id=34788020 https://news.ycombinator.com/item?id=34788020 https://news.ycombinator.com/item?id=37908760 https://news.ycombinator.com/item?id=37908760
- tiltowait 2y agoIt really is as fast as it claims. I sometimes intentionally add something it will complain about just to make sure it’s still working.
- atty 2y agoI do the same thing, and I keep doing it regardless of how many times I see it working properly.
- mhh__ 2y agoA small boon to it not being in python — it's now decoupled from your python toolchain.
- zahlman 2y agoThere is no "coupling" inherent to native Python tools. They can generally be installed in a separate virtual environment from the one they operate on. For example, with Pip you simply pass the `--python` option to have it install for a different environment - you can create your venvs `--without-pip`, and share a copy of Pip across all of them. If you use Pipx, you can expose and use Pipx's vendored Pip for this, as I described in a recent blog post (https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-...). Twine and Build don't care about your project's environment at all - Twine uploads a specified file, and Build by default creates a new environment for the build (and even withough build isolation, it only requires your build environment to contain the build backend, and the build environment doesn't have to be the one you use for the rest of development). Setuptools, similarly, either gets installed by the build frontend into an isolated build environment, or can reside in a separate dedicated build environment. It doesn't actually operate on your project's environment - it only operates on your project's source tree.
- mhh__ 2y agoThat's a lot of words compared to "Download binary from server. Run it"
- zahlman 2y agoSometimes it takes a lot of words to debunk a misconception. What you initially said didn't have anything to do with setup effort, but also there is quite little setup effort actually described here.
- mhh__ 2y agoThere is nothing to debunk, my original comment was correct. It's useful to have tooling that doesn't rely on carting around a bunch of python stuff.
- monomial 2y agoI've been using an amalgamation of pyenv, pip-tools, black, isort, etc. for projects and just gave uv and ruff a try. Wow, it really is fast! Skeptical of anything VC-backed but I'll be keeping my eye on it.
- greatgib 2y agoSo much marketing coolaid/bullshit. I'm not that fan of Ruff because to me it doesn't make any sense to add a rust dependency to "python" and it blows my mind that people are so keen to accept the ugly formatting inherited from Black just because "it gives consistency to the team, so I don't have to think, and we don't have to discuss code style"... But all of that personal opinion set aside, what triggers my initial statement is that so many persons are so excited to run to use Ruff because... "It is so fast"... when I'm quite sure most of them would never notice any real speed difference with their modest codebase. In almost all the codebases I have seen, proprietary and OSS, pylint or any other linter was quasi-instant. There are probably a few huge codebases that would see a speed benefit of a few seconds to use Ruff, but their owner would probably better have a look at their code to understand how their reached such a monster!
- Terretta 2y ago> quite sure most of them would never notice any real speed difference with their modest codebase On the contrary, within only a year or so of coding by a small team, this ecosystem takes single digit seconds or less, while the traditional tools are taking minutes and more. Particularly in analytics or scientific computing we've seen minutes versus under a second. Having the tools not require additional/parallel Python dependency management is a plus. Note that we watched these tools for a long time, and jumped in when rye converged with uv. It was promising to see fewer ways to do it. // More on that here: https://news.ycombinator.com/item?id=41309072 https://news.ycombinator.com/item?id=41309072
- sunshowers 2y agoPersonally, I think excellence is a virtue in tooling in and of itself. The Python world just hasn't experienced this kind of excellence before.
- rmwaite 2y agoI have issues with some of Black’s formatting decisions but I’ve also suffered from inconsistent formatting and there is no question in my mind that consistent formatting that I find ugly sometimes is 1000% better than the alternative. And after so many years of dealing with it it’s so refreshing to just “give up” and let the formatter win.
- deleted 2y ago[deleted]
- rikthevik 2y agoI'm very impressed by the recent developer experience improvements in the python ecosystem. Between ruff, uv, and https://github.com/gauge-sh/tach https://github.com/gauge-sh/tach we'll be able to keep our django monolith going for a long time. Any opinions about the current state of the art type checker?
- tylerhillery 2y agoI have always used MyPy but I have noticed some large open source projects adopt Pyright as of late. The folks behind ruff and uv are currently working on a type checker as well but haven't heard when they plan on releasing it.
- ubercore 2y agoMyPy is nice, but it has missed some things that pyright caught, which were legitimate bugs that could have arisen.
- claytonjy 2y agohas Astral confirmed they’re doing a type checker? i’m not surprised, everyone has been asking for it, but i haven’t seen them say they’re doing it
- tylerhillery 2y agoYes it's confirmed, you can listen to Charlie talk about here: https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980 https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980 Code Name is Red Knot: https://github.com/astral-sh/ruff/discussions/12143 https://github.com/astral-sh/ruff/discussions/12143
- Mehdi2277 2y agoI'm very happy with pyright. Most bug reports are fixed within a week and new peps/features are added very rapidly usually before pep is accepted (under experimental flag). Enough that I ended up dropping pylint and consider pyright enough for lint purposes as well. The most valuable lints for my work require good multi-file/semantic analysis and pylint had various false positives. Main tradeoff is this only works if your codebase/core dependencies are typed. For a while that was not true and we used pylint + pyright. Eventually most of our code is typed and we added type stubs for our main untyped dependencies. edit: Also on pylint, it did work well mostly. tensorflow was main library that created most false positives. Other thing I found awkward was occasionally pylint produces non-deterministic lints on my codebase.
- seanwilson 2y agoFor Django projects, what's fast that will cover Python, HTML, CSS and JavaScript files? Ruff only does Python?
- bobbylarrybobby 2y agoPrettier can do HTML CSS and JS but I don't think there's any one tool that can do it all. (It would be interesting if there were something like a tree sitter for auto formatting)
- mdaniel 2y agoI recently learned that tree-sitter does not have a goal of accurately representing the whole source input, and thus as it currently stands could not be used for that purpose Now, whether a tree-sitter-esque ecosystem that is designed for source modeling could catch on like t-s did is a more interesting question
- zahlman 2y agoIf you already have tooling to cover each separately, why would it be better for it to be a single tool?
- seanwilson 2y agoDjango templates snippets get mixed inside CSS, JavaScript and HTML. So regular when CSS/JavaScript/HTML formatters get confused by those, it's not obvious what combination to use. I know of djLint but it's pretty slow.
- dethos 2y agoFor Django projects, I would say DjLint [1]. It doesn't cover all you asked, but makes the job of writing the templates (HTML) much more pleasant. [1] https://djlint.com/ https://djlint.com/
- danpalmer 2y agoI'm a little sad that Ruff took off as a re-implementation of a whole bunch of work that was already done, rather than as a project to improve the work that was already done. It was nice to be able to write little extra linters or flake8 plugins in the language I was linting. Plus decades of effort had gone into making those plugins pretty great, finding the right separation of linting codes so that the right things could be linted/ignored per codebase. I understand why they did it, and they have done it remarkably well, but "rewrite it from scratch" is almost never the best answer and part of me wonders if this result could have been even better achieved another way.
- Onavo 2y agoBlame Guido. Until recently when he was bought out by Microsoft, he had been the primary blocker of higher Python performance. There were a bunch of attempts at adding a JIT to Python but Guido was more interested in splitting hairs over syntax than any real heavy lifting. Python could have been as performant as LuaJIT or V8 but their dictator ruined it. Python need more Mike Palls.
- searealist 2y agoYour argument seems ideological. There is no chance they could have improved Flake8 to be as good as Ruff is.
- burntsushi 2y agoFolks said the same thing to me about grep 8.5 years ago when I released ripgrep.
- oguz-ismail 2y agoAnd you think you've done it?
- JelteF 2y agoWait... Did you misunderstand this comment? Or are you saying grep caught up with ripgrep now?
- Blackarea 2y agoI don't care one bit about py-land, but it's always nice to see a rust project swoope in and save the day. Language processing like compiling or linting is just one of the many aspect where rust can really play out it's awesome strength.
- cwalv 2y agoHow speedy is the rust-language tooling itself these days? I remember wishing for a 'optimize nothing' or even 'just interpret' mode. Compile times noticably contributing to the feedback loop are a serious killjoy.
- goku12 2y agoCompile times are still a bit much, but there are ways around it: - The insanely long times are only for the initial build. Further builds are incremental and more tolerable. - Compilation errors can be checked using 'cargo check'. It avoids the code generation step that's part of a build. I find myself doing it way more often than builds. So it's a time saver depending on how frequently you use it. - You can extend the incremental build mentioned above using sccache [1]. At the minimum, it allows you to share the build cache between all your local projects. So it saves time if your projects or other builds share a lot of common libraries (that's very common in Rust, though). But sccache can go further by using online build caches (for example, using S3) that can be shared between hosts. Finally, sccache also supports distributed builds if you have a few machines sitting idle. (This is like distcc with extra features). [1]: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
- nicoburns 2y agoThere have been significant (if not earth shattering) improvements in the compiler itself. But for me at least, the bigger change has been from better hardware. I now have a processor (Apple M1 Pro) that's 10x (multi core) / 2x (single core) faster than the one I had when I first started programming using Rust (intel dual core processor in a 2015 MBP) and that seems to have translated almost perfectly into faster compile times.
- scosman 2y agoBeing new to python, the astral stuff is such a relief. I don’t think experienced python folks realize how much the flexible tooling slows people down, and creates friction for adopters. Setting up my project I tried 3 environment managers, 2 type checkers, 3 formatters/linters, 3 packagers/dependancy/project managers. I know this is kinda the n+1 issue where astral is just adding another. But it feels like a complete and well designed stack, not a box of parts encouraging me to build my own. Reminds me a bit of go tooling. I am a convert. I’ll happily jump on their type checker and packager when ready.
- kstrauser 2y agoI’ve been writing Python for 25 years and I love love love ruff and uv and friends.
- kibwen 2y ago> I know this is kinda the n+1 issue where astral is just adding another. My bugbear with that XKCD is that even if it's true, it's also how progress is made. By this point I'm so annoyed whenever anyone links it that I kinda just wish Randall would take it down.
- tubthumper8 2y agoYeah, and that comic is about standards anyways, not tools, so it's doubly annoying when it's linked out of context
- earnestinger 2y ago> it's also how progress is made Introducing n+1 solution/ standard may be the necessary cost of making progress, but it is possible to incur that cost without gaining anything (at the extreme, trolling is fun activity with net negative on bigger scale)
- scosman 2y agoYeah but still seems relevant when complaining there are too many options and praising the n+1 option
- 2y ago
- TheTaytay 2y agoI’m used to running command line tools on fast machines, but the first time I ran ruff on my codebase I was blown away. My codebase isn’t massive but most (non-rust) tools just take a while to run. It might be less than a second of startup overhead, but it’s noticeable. Ruff is so fast you wonder if it even did anything. It reminded me how fast computers actually are.
- earnestinger 2y agoDoes formatting match black? (Unlikely, but one can dream of standard being established)
- BerislavLopac 2y agohttps://docs.astral.sh/ruff/formatter/black/ https://docs.astral.sh/ruff/formatter/black/
- bowsamic 2y agoNow we just need this but for mypy
- JohnScolaro 2y agoI first attempted to use ruff for a small project ~2 years ago, and at the time felt that it wasn't quite good enough to replace the: black+isort+whatever linter combo we were using at work. I've used it a few times since then and now I'm a big proponent of using only ruff. I think most of its value comes from: 1. Being fast (or at least fast enough that it's not annoying). 2. Replaces the linting/formatting combo of multiple tools, reducing the cognitive load for the developer. Anyway, big fan.