Astral
astral.sh
astral.sh
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.
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 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
I do hope they'll expose Ruff as a Python module / API in the future. I'm currently using Black to format Python code that's in-memory (never gets written out to disk).
With Black (as an imported Py module), it's just a matter of passing in a string and getting one back. With Ruff as it is now, I'd have to write that out to disk, spawn Ruff process, then read the formatted file back in. Do that for many files and the speed advantages disappear, and actually it's slower.
cat bad.py | ruff check --fix --stdin-filename stdin.py - > good.py
* run ruff command many times (with different input file each time) * write all the files to "disk" (tempfs actually so it doesn't involve disk access) and run ruff once
Currently with black I avoid that by importing it as a module once so I get the benefits of both (and is simple to boot).
In other comments here I've read that a person heavily involved in Python-Rust interop is also part of the team, so there's hope they'll expose ruff as a module too and magically whisk my dilemma away :-)
ruff check . —-fixClearly the creator of ruff is going to expand from an open source tool into a company focusing on Python tooling and developer experience, services, etc. There is a market for stuff like that just based on pycharm and jet brains' success in the space alone.
But you might be able to do support contracts, like ansible. Tough road though.
All this while remaining a team of 2-3, hopefully, with all company-running stuff minimized and outsourced.
Ruff is built for speed from the start and doesn't look at type annotations because you should run a type checker alongside.
Also, does Ruff work well on codebase without type hints?
Ruff will work fine without type hints.
I believe it rightfully leaves it to mypy for those who want those features.
Mypy transpiles itself to c using mypyc and that can still take a while to complete when caches get invalidated.
Ruff works well regardless of whether you use type hints.
In mypy a variable taking values of two types is an error (unless explicitly annotated) which means you can assume the type from the first assignment statement and then use that assumption every other time the variable is used/assigned. In pylint it allows variables to take multiple types and only emits errors when an operation is invalid against one of the types. E.g. `x[0]` is valid for lists and tuples so you could assign it a list or a tuple depending on some condition.
The number of possibilities it considers quickly multiplies. Eg if your function is of the form `if blue_condition: x = blue_action(x)` that's a doubling of the possibilities and ten flags -> 1024 possibilities. (pylint has some heuristics on when to give up.)
The advantage of pylint is that it doesn't require your code to fit a certain style. But nowadays people have type annotations and they prefer to use them even if it means changing their code style a bit here and there.
Other type inferers with different approaches are pyright, Jedi, Pyre, pytype etc with different tradeoffs.
Python is becoming a bit too reliant on Rust. Rust is good but, in term of portability, is just not as mature as C. If your lib relies on Rust, please please please test it on something beyond Linux and Mac.
That’s asking a lot. If your platform is poorly supported by Rust, then maybe that’s where your efforts should be directed. If you fix that, lots of interesting stuff beyond one library is unlocked.
Which doesn't mean he hasn't, of course!
Whereas if this conversation was about something with broader stewardship, like _Linux_, I'd be saying this is silly, you shouldn't be compromising other things just so you can build your RPi kernel on an RPi.
> In OpenBSD there is a strict requirement that base builds base. So we cannot replace any base utility, unless the toolchain to build it is in the base.
> Such ecosystems come with incredible costs.
Basically, the cost of adding rust to the OpenBSD base system currently far outweights the proposed benefits (reimplement fileutils), especially considering people will probably not want to pour in the effort needed to rewrite those with strict POSIX compliance (which is another requirement).
He's not saying rust isn't useful but that it wouldn't be a net benefit to have a hard dependency on it in the base system. In the BSD world folks take a very strict and conservative view of what can go in base (and for good reason IMHO).
This is different from the GP comments about just making it possible to use rust programs/libraries in OpenBSD, so we're definitely on a tangent here.
Why? Simply because you use something that even 95% of the unix folk do not?
I can totally see how they wouldn’t be concerned with that. Just as I’m not concerned with making my JS lib work for those weirdos that still run IE 5.5.
No, thank you, I'll just add Windows. Your choice to use platforms that nobody else does save for a few specialists does not constitute a need on my part to support your favorite. In the same way that if I package for Debian, Ubuntu and RHEL, it's your problem that it's not on Arch or unsupported by your custom Hannah Montana Linux. Feel free to submit PRs though.
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.
curious how you assessed this. did you inspect the code or are you just commenting from the user POV?
- "This chef is a great cook!"
- "How do you know, have you looked inside the kitchen?"
How you come to the conclusion he's "just a damn good developer" is a very fair question.
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.
I think there's something to be said for praising the developer that is able to understand user needs so well that they create flawless experiences.
Just my opinion of course, but to be considered a "damn good developer," you have to do both.
Yes.
For the brief time he was at Cedar, he contributed a lot of high quality code
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.
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.
I think the only irreplaceable part of the Python ecosystem at the moment is the math/stats/NN stuff. I wouldn't hire a data scientist who refused to learn Python, but I would hire a web dev who refused to learn it.
Presumably you're referring to ASP.NET, but if not, I'd love to know what you're working with. They're not really all that comparable. If I want to make something very quickly and need it to be trustworthy, I'll use Django, especially with the admin site. That said, these days I'd much rather work in the .NET ecosystem.
Sure, but .NET includes ASP.NET.
> If I want to make something very quickly
The difference in setup time between a modern .NET 7 web application and Django is basically nothing. You can have a boilerplate project in a few seconds, and the Hello World for the API side is 4 lines:
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();\
app.MapGet("/", () => "Hello World!");
app.Run();
I don't understand what this means.
Security? .NET is very likely more secure out of the box because it's supported by a far larger company and is used by so many large organizations.
Lack of runtime errors? You're going to have more in Python because it doesn't have a compiler with strict rules.
I only use Python specifically for utility scripts for this reason.
Not having to type annotate every tiny thing is also great. You can type only what brings you value and leave the rest to be inferred. It really is the best of all worlds.
You set up an application once, write each line a few times, read it dozens of times, and run it millions of times.
The most costly part of that process is reading/rewriting because developer time is expensive.
Language choice should be optimized to make it easy to read other people's code and to prevent mistakes from getting into production. Python is not near the top of the pack in those dimensions.
I think most people would definitely disagree with you on the first point. As far as languages go, Python is probably one of the most readable ones out there. It's often even compared to pseudocode because well written Python reads like it.
The latter is a valid point, but assumes all code you ever write is made for production. That's just plainly false. Python is great for tooling, automation, prototyping and many other smaller scale non-production usage. That's where the low-barrier of entry really shines.
This is absolute rubbish. Go and find me a piece of application code which isn’t procedural math/data manipulation, give it to someone completely new to it and see how easily they (don’t) comprehend it.
I could not disagree more. Python (as most people write it) has many things that make it less readable:
1. Semantic whitespace (absolute disaster for readability, almost as bad as YAML)
2. Choosing to "save keystrokes" by removing helpful visual cues that other languages have, like parentheses, semicolons, and brackets -- these things make scanning much easier
3. As most people write it, very few line spaces, making Python look like an unbroken run-on sentences instead of nice blocks of code
I've been writing and maintaining code for 26 years, and I've worked a lot with C#, JS/TS, Python, and PHP. I know other languages but haven't spent as much time with them.
Out of those, PHP is ironically the most readable because of its $ variables, and then the order is C#, TS, JS, and then Python. Python is hard to scan and just looks like a brick wall at first glance.
Compare
namespace HelloWorld
{
class Hello {
static void Main(string[] args)
{
System.Console.WriteLine("Hello World!");
}
}
}
print("Hello World!")
std::ifstream t("foobar.txt");
std::stringstream content;
content << t.rdbuf();
with open('foobar.txt') as file_object:
content = file_object.read()
I'm a Dart developer by day, Rust enthusiast by night, both are relatively modern languages and the tooling just feels right (of course nothing is perfect): the analyzer, linter, testing, dependency management, lsp, formatter are all just there.
I never want to go back to 20-30 year old languages where, for all these tools, there are 10 different subpar solutions with three decades of baggage, history, and context (though, of course, congrats on the 1000x speed up).
Python, JavaScript, Java, C++, are all in this category, and honestly, even community favorites like TypeScript and Kotlin have similar warts.
It doesn't happen in Python either. So that's good.
> barely ever needing to touch the terminal
Not really a good sign, point-click developers are not usually the strongest. That said I like things to work easily and don't have many quarrels with Python. Certainly fewer than most other languages.
Sounds like you're not very familiar with it and got used to C#. I don't have a problem with anything you list.
In principle I agree, but my point is - it was possible to be fully productive being just a point-click developer.
> It doesn't happen in Python either. So that's good.
pyright + black + isort hook in the project I'm working on takes 1-5 seconds on an M1 mac on save. We're moving to ruff for this reason. Never saw this anywhere else.
> I don't have a problem with anything you list.
To give better examples:
- poetry takes ~900 seconds to resolve dependencies during update/lock
- I had to use multiprocessing where in any other language I would use threads because GIL, inter-process communication is needlessly complex
- I can't dot+tab+enter autocomplete while using boto or many other libraries - due to weak typing discoverability suffers and I need to have documentation always open in another window to do anything. This is not a problem in strongly typed languages.
- wsgi - concept of running separate interpreters for each incoming request is a bit wasteful
- I never had any problem with broken / incompatibile environment like I had on python. I just install recent version of .net / rust / node (to a lesser extent) and things generally tend to work. Here I have to worry about specific subversions and conflicts in PATH with another envs and OS-packaged python. Avoidable, but noobs are certain to hit this at some point.
- I didn't talk about general speed as it's beating a dead horse, but Python basically nullifies the last 20 years of hardware improvements
> Sounds like you're not very familiar with it and got used to C#.
I also used Rust and Go and was super happy with the experience for similar reasons.
git status | grep \.py | tools
It probably will also support Ruff if it doesn't already.
Still, I want some things to run more often than commit, such as pyflakes.
1. Micro-optimisation,
2. Better algorithms,
3. Change the problem.
The potential impact of each of these increases as you go down.
Choosing Rust over Python is micro-optimisation. All things being equal, the impact isn't going to be that great. People are like "let me squeeze out every ounce of power from my CPU so I can run a linter on the entire codebase every time I save". Python folk are like "why on earth would you do that?" We simply changed the problem.
You are thinking like a software engineer, understandably
If you looks at STEM research fields Python is a solid tool for the fact it is a utlility/scripting tool. All the issues you listed rarely occur in this instance.
Most of the Python I write has a very limited lifetime. Typically shorted than the development time
There are indeed better Python alternatives, but very few use them in comparison
The intersection of people who enjoy both C# and Python is very small. I too have worked a soul-sucking job in finance and use of languages like Java and C# was a big part of what I didn't like.
It seems there are two ways to react to the "I don't get it" situation:
1. Other people must be wrong in the head to like this,
2. I don't have the knowledge and/or experience to understand why other people like this.
In life I find it's generally better to give the benefit of the doubt and take the second path. But you may still conclude it's the first after all. All I can say is I'm grateful there are others who are wrong in the head like me and prefer Python for whatever reason.
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.
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.
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!
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.
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.
- 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.
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.
You're right that it will probably still be faster overall because "most" linting will be done with Ruff and any extras would be done externally, but now you've either got 2 tools when you had 1 before, or you've got to shell out to Python which adds overhead, or you've got to rewrite plugins in a Ruff-compatible format, or something else.
> Kinda just sounds like you're grousing because somebody moved the cheese.
I'm just disappointed that someone looked at slow linting and decided the answer was their own new tool, rather than participating in the existing community. Now the effort has forked, it'll take more work overall in the community, and we were already lacking engineering resource.
Setting this up takes a bit more work than for webpack, and it's easier to run into limits on what's reasonably possible, but I don't intend to ever go back.
It looks like the ruff benchmark is run with the `--no-cache` arg: https://github.com/charliermarsh/ruff/blob/main/CONTRIBUTING...
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>
> 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.
For some people, nothing is ever good enough. Such is the nature of getting feedback from strangers. The sooner you learn to filter out the naysayers, the better.
This tool is probably fine. But positive feedback is usually expressed as an upvote.
It is great accomplishment for ruff the project. But the topic here is the launch of Astral the company, not ruff the project. And 1000x speed increase is not a business plan.
I agree that the topic you're describing, and that is suggested by the URL posted, are worth talking about. It makes me nervous to invest time into a VC-backed linter. Though it seems useful enough to be forkable if things go sour.
"VC-backed linter" is a bizarre phrase, though honestly I think you could have described something like Purify in Ye Olden Days as a linter, and it was worth spending money on. (And the issues with being VC-backed go well beyond simply being whether or not something is worth spending money on.)
I mean, paying people who work on it, for one?
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.
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.
Serious question, what is the path for a linter? Where else are people paying for linting as a service?
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.
Starting with some nice developer tooling and going from there doesn't seem crazy at all.
After the core-js debacle[0] earlier this year, it was evident that alot of companies actually do not care care about supply-chain security.
Those that do will happily roll their own hosted repositories that provide little to no guarantees.
[0] https://github.com/zloirock/core-js/blob/master/docs/2023-02...
The natural end state is yet another build service.
There's a FOSS SAST product for Python already, though, called Pysa: https://pyre-check.org/docs/pysa-basics/
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.
I've been using 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.
Having an automated lint run upon opening a PR seems like a minor expense, especially when you can work on other tickets while you wait.
It 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.
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-...
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?
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
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.
Edit: for comparison, flake8 took 8.19s and found approximately the same number of issues. pyflakes took 4.49s and found fewer.
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.
Ruff has an LSP too so it integrates well with editors unlike flake8 and similar which only work on save — and are really slow
1. Fast enough to be live updating as you type in an IDE.
2. Slow enough that running a linter has to be a separate action you take, but fast enough that you don't go do something else while it's running.
3. So slow that it's an asynchronous task that you launch and then come back to later.
Ruff is in the first category, while most other python linters are in the second. This level of performance enables a qualitative difference in how you interact with the tool. If you are invoking it as a separate task, then going from 500ms to 50ms is indeed not very interesting, though.
https://github.com/charliermarsh/ruff#rules
> Ruff supports over 500 lint rules, many of which are inspired by popular tools like Flake8, isort, pyupgrade, and others. ... By default, Ruff enables Flake8's E and F rules. Ruff supports all rules from the F category, and a subset of the E category, omitting those stylistic rules made obsolete by the use of an autoformatter, like Black.
You can see the current list of supported rules here: https://beta.ruff.rs/docs/rules/
There's also a checklist on this PR which tracks progress on implementing pylint compatibility: https://github.com/charliermarsh/ruff/issues/970
- 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
I don't really see why I should care about ruff.
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
I now have to compile Firefox overnight because I can no longer compile it and do something else with my (core i7) laptop simultaneously
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.
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.
And yes, I have regretted clicking on HN links before.
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.
This seems long overdue! Looks like a great project :)
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.
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.
It's funny that all good things for Python are not written in Python. Says a lot about the language.
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.
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.
(Example from https://github.com/home-assistant/core/pull/86224 by yours truly.)
(Also, nice work!)
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.
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/
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.
It's usually true, too.
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.
> 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. ...
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?
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.