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.
The main reason pylint is slow is it tries to infer the types of the variables, and it predates type annotations so it can go through multiple functions/control paths across multiple files to figure these out. This approach is obviated by type annotations and type checkers.
Ruff is built for speed from the start and doesn't look at type annotations because you should run a type checker alongside.
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)
I actually cursed Maturin a few years ago, as it refused to compile on OpenBSD and hence broke some lib I planned to use.
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.
I thought Black was an auto-formatter, similar to clang-format, but for Python. Ruff seems to be only doing linting, not formatting. Am I missing something?
That's a very good point. We love to talk about speed in dev tools, probably because it's an easy metric to track, but usability and good features are really the key points for making a tool that people want to use and keep using. Too many open source projects neglect the product angle in favor of the technical.
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.
I think the main problem for you is that Python is heavily rooted in Unix and, more specifically, GNU/Linux and free software. Also, it has history. Python has been in use since the early 90s. C# is a Java knockoff that appeared almost a decade later.
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.
> Linter taking multiple seconds is not a problem which occurs in any other popular language.
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.
> It really boggles my mind why is this lang so popular.
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
>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.
Same, the tooling makes a big difference when it comes to languages.
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.
I agree on the venv, 'which python', and packages and I would add Python V2/V3. I work on a few Macbooks and have to occasionally return to Python. It's constant firefighting on environments.
Maybe tooling for other languages are faster because the dev has to spend a lot more time specifying a lot more things / are a lot more verbose. The reason tooling on Python is slow is exactly why people love it, because it's lightweight, easy to quickly whip up a script. Take a one line hello world vs having to create an entire project and 10 lines in C#.
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 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.
Using something like [poetry](https://python-poetry.org) would make your workflow much better. With this tool, you don’t need to care about venv and `which python`.
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.
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.
> 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.
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.
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.
A faster version of black is not a strong enough value proposition for an entire company. Ruff should remain an open source product. What is the point of making every half decent Developer tool a whole startup?
I'm inclined to agree and when they eventually die, what happens to the tool they built?
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.
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.
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
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.
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.
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?
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
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.
- 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
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'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.
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?
I hope they eventually attack package management and easy static bundling. It would make Python more attractive for people coming from other ecosystems.
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.
[+] [-] akprasad|2 years ago|reply
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
[+] [-] lozenge|2 years ago|reply
Ruff is built for speed from the start and doesn't look at type annotations because you should run a type checker alongside.
[+] [-] pid-1|2 years ago|reply
[+] [-] swyx|2 years ago|reply
[+] [-] toyg|2 years ago|reply
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.
[+] [-] Night_Thastus|2 years ago|reply
[+] [-] BiteCode_dev|2 years ago|reply
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.
[+] [-] hardwaregeek|2 years ago|reply
[+] [-] swyx|2 years ago|reply
curious how you assessed this. did you inspect the code or are you just commenting from the user POV?
[+] [-] throwaway2137|2 years ago|reply
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.
[+] [-] globular-toast|2 years ago|reply
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.
[+] [-] mixmastamyk|2 years ago|reply
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.
[+] [-] was_a_dev|2 years ago|reply
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
[+] [-] robswc|2 years ago|reply
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.
[+] [-] serial_dev|2 years ago|reply
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.
[+] [-] benjaminwootton|2 years ago|reply
[+] [-] ehsankia|2 years ago|reply
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.
[+] [-] int_19h|2 years ago|reply
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.
[+] [-] booleandilemma|2 years ago|reply
I only use Python specifically for utility scripts for this reason.
[+] [-] meatjuice|2 years ago|reply
[+] [-] Tossrock|2 years ago|reply
[+] [-] Phelinofist|2 years ago|reply
[+] [-] lchengify|2 years ago|reply
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.
[+] [-] danpalmer|2 years ago|reply
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.
[+] [-] neuronexmachina|2 years ago|reply
It looks like the ruff benchmark is run with the `--no-cache` arg: https://github.com/charliermarsh/ruff/blob/main/CONTRIBUTING...
[+] [-] qbasic_forever|2 years ago|reply
[+] [-] sfink|2 years ago|reply
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>
[+] [-] kitanata|2 years ago|reply
[+] [-] BiteCode_dev|2 years ago|reply
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.
[+] [-] qudat|2 years ago|reply
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.
[+] [-] paulgb|2 years ago|reply
I mean, paying people who work on it, for one?
[+] [-] kvathupo|2 years ago|reply
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.
[+] [-] swyx|2 years ago|reply
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.
[+] [-] motbus3|2 years ago|reply
[+] [-] M3L0NM4N|2 years ago|reply
[+] [-] colincooke|2 years ago|reply
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-...
[+] [-] amlozano|2 years ago|reply
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?
[+] [-] kleaver|2 years ago|reply
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
[+] [-] neves|2 years ago|reply
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.
[+] [-] senko|2 years ago|reply
- 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
[+] [-] korijn|2 years ago|reply
I don't really see why I should care about ruff.
[+] [-] hardwaregeek|2 years ago|reply
[+] [-] dzonga|2 years ago|reply
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
[+] [-] divan|2 years ago|reply
[+] [-] traceroute66|2 years ago|reply
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.
[+] [-] mhh__|2 years ago|reply
[+] [-] haolez|2 years ago|reply
[+] [-] claytonjy|2 years ago|reply
¹: https://www.github.com/David-OConnor/pyflow
[+] [-] singhrac|2 years ago|reply
[+] [-] jfb|2 years ago|reply