5 ms·

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

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 3y 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 3y 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 3y 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 3y 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 3y ago
      Maybe your answer is correct but it is not useful, at all. It does not answer the question, like, providing real solutions.
      - deleted 3y ago
        [deleted]
BiteCode_dev 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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.

paulgb 3y 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 3y 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 3y 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 3y 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 3y ago
    Maybe your answer is correct but it is not useful, at all. It does not answer the question, like, providing real solutions.
    - deleted 3y ago
      [deleted]

BiteCode_dev 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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.