6 ms·

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

by klysm 10mo ago

tabbott 10mo ago
Yeah their work thus far has been an incredible public service to the Python community.
amanzi 10mo ago
"pyx" is their first commercial offering: https://astral.sh/pyx https://astral.sh/pyx I agree though. Hope this is successful and they keep building awesome open-source tools.
- clircle 10mo ago
  Why the “y” look so wrong in the special font.
- jbmsf 10mo ago
  We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff. It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.
  - embedding-shape 10mo ago
    > Feels like the best case is something like Hashicorp Wow, that's probably my go-to case of things going south, not "best case scenario". They sold to IBM, a famous graveyard for software, and on the way there changed from FOSS licensing to their own proprietary ones for software the community started to rely on.
    - jbmsf 10mo ago
      You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.
      - embedding-shape 10mo ago
        You however, are. Hashimoto didn't leave until December 2023, Hashicorp announced the license change August 10, 2023. Also way back in September 2021 they started having staffing issues and stopped accepting community contributions, and also made the questionable choice of going public that same year. You might be on to something with point B, hard to find good examples of developer tool companies that don't eventually turn sour. However, there are countless examples of successful and still very useful developer tools out there, maybe slapping a company on it and sell a "pro" version isn't the way to go?
        jbmsf 10mo ago
        Meh. The end of the company many of us admire was a combination of the founders giving up control to the usual villains and the venture business model failing for developer tools. I don't think the specific departure date matters very much; things started to degrade earlier. As for "slapping a company on it", I agree, but also I don't think we've developed a viable alternative. Python has been limping along with one toolchain or another for my entire career (multiple decades) and it took Astral's very specific approach to create something better. It's fair to ask why they needed to be venture backed, but they clearly are and the lack of successful alternatives is telling.
        vietthan 10mo ago
        I actually would argue that Hashimoto "left" earlier. He "stepped down" from the executive team July 2021 and became an individual contributor then. He likely lost interest/power a long time before 2023. https://www.hashicorp.com/en/blog/mitchell-s-new-role-at-hashicorp https://www.hashicorp.com/en/blog/mitchell-s-new-role-at-has...
tyre 10mo ago
Feels like they’re headed in the direction of bun.
- mi_lk 10mo ago
  In zero revenue or acquisition direction
  - rockwotj 10mo ago
    Thankfully all these LLM labs are heavily invested in python so this seems like the likely route IMO
    - ares623 10mo ago
      Just need to book a long nice walk with one of the CEOs
bmitc 10mo ago
My issue with them is that they claim their tools replace existing tools, but they don't bother to actually replicate all of the functionality. So if you want to use the full functionality of existing tools, you need to fall back on them instead of using Astral's "replacements". It's like one step forward and one step back. For me personally, speed of the tooling is not as important as what the tooling can check, which is very important for a language like Python that is very easy to get wrong.
- woodruffw 10mo ago
  If there are specific incompatibilities or rough edges you're running into, we're always interested in hearing about them. We try pretty hard to provide a pip compatibility layer[1], but Python packaging is non-trivial and has a lot of layers and caveats. [1]: https://docs.astral.sh/uv/pip/ https://docs.astral.sh/uv/pip/
  - amluto 10mo ago
    Is there any plan for a non-“compatibility layer” way to do anything manual or nontrivial? uv sync and uv run are sort of fine for developing a distribution/package, but they’re not exactly replacements for anything else one might want to do with the pip and venv commands. As a very basic example I ran into last week, Python tooling, even the nice Astral tooling, seems to be almost completely lacking any good detection of what source changes need to trigger what rebuild steps. Unless I’ve missed something, if I make a change to a source tree that uv sync doesn’t notice, I’m stuck with uv pip install -e ., which is a wee bit disappointing and feels a bit gross. I suppose I could try to put something correct into cache-keys, but this is fundamentally wrong. The list of files in my source tree that need to trigger a refresh is something that my build system determines when it builds. Maybe there should be a way to either plumb that into uv’s cache or to tell uv that at least “uv sync” should run the designated command to (incrementally) rebuild my source tree? (Not that I can blame uv for failing to magically exfiltrate metadata from the black box that is hatchling plus its plugins.)
    - woodruffw 10mo ago

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

by klysm 10mo ago

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

tabbott 10mo ago

Yeah their work thus far has been an incredible public service to the Python community.

amanzi 10mo ago

"pyx" is their first commercial offering: https://astral.sh/pyx https://astral.sh/pyx I agree though. Hope this is successful and they keep building awesome open-source tools.

clircle 10mo ago
Why the “y” look so wrong in the special font.
jbmsf 10mo ago
We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff. It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.
- embedding-shape 10mo ago
  > Feels like the best case is something like Hashicorp Wow, that's probably my go-to case of things going south, not "best case scenario". They sold to IBM, a famous graveyard for software, and on the way there changed from FOSS licensing to their own proprietary ones for software the community started to rely on.
  - jbmsf 10mo ago
    You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.
    - embedding-shape 10mo ago
      You however, are. Hashimoto didn't leave until December 2023, Hashicorp announced the license change August 10, 2023. Also way back in September 2021 they started having staffing issues and stopped accepting community contributions, and also made the questionable choice of going public that same year. You might be on to something with point B, hard to find good examples of developer tool companies that don't eventually turn sour. However, there are countless examples of successful and still very useful developer tools out there, maybe slapping a company on it and sell a "pro" version isn't the way to go?
      - jbmsf 10mo ago
        Meh. The end of the company many of us admire was a combination of the founders giving up control to the usual villains and the venture business model failing for developer tools. I don't think the specific departure date matters very much; things started to degrade earlier. As for "slapping a company on it", I agree, but also I don't think we've developed a viable alternative. Python has been limping along with one toolchain or another for my entire career (multiple decades) and it took Astral's very specific approach to create something better. It's fair to ask why they needed to be venture backed, but they clearly are and the lack of successful alternatives is telling.
      - vietthan 10mo ago
        I actually would argue that Hashimoto "left" earlier. He "stepped down" from the executive team July 2021 and became an individual contributor then. He likely lost interest/power a long time before 2023. https://www.hashicorp.com/en/blog/mitchell-s-new-role-at-hashicorp https://www.hashicorp.com/en/blog/mitchell-s-new-role-at-has...

tyre 10mo ago

Feels like they’re headed in the direction of bun.

mi_lk 10mo ago
In zero revenue or acquisition direction
- rockwotj 10mo ago
  Thankfully all these LLM labs are heavily invested in python so this seems like the likely route IMO
  - ares623 10mo ago
    Just need to book a long nice walk with one of the CEOs

bmitc 10mo ago

My issue with them is that they claim their tools replace existing tools, but they don't bother to actually replicate all of the functionality. So if you want to use the full functionality of existing tools, you need to fall back on them instead of using Astral's "replacements". It's like one step forward and one step back. For me personally, speed of the tooling is not as important as what the tooling can check, which is very important for a language like Python that is very easy to get wrong.

woodruffw 10mo ago
If there are specific incompatibilities or rough edges you're running into, we're always interested in hearing about them. We try pretty hard to provide a pip compatibility layer[1], but Python packaging is non-trivial and has a lot of layers and caveats. [1]: https://docs.astral.sh/uv/pip/ https://docs.astral.sh/uv/pip/
- amluto 10mo ago
  Is there any plan for a non-“compatibility layer” way to do anything manual or nontrivial? uv sync and uv run are sort of fine for developing a distribution/package, but they’re not exactly replacements for anything else one might want to do with the pip and venv commands. As a very basic example I ran into last week, Python tooling, even the nice Astral tooling, seems to be almost completely lacking any good detection of what source changes need to trigger what rebuild steps. Unless I’ve missed something, if I make a change to a source tree that uv sync doesn’t notice, I’m stuck with uv pip install -e ., which is a wee bit disappointing and feels a bit gross. I suppose I could try to put something correct into cache-keys, but this is fundamentally wrong. The list of files in my source tree that need to trigger a refresh is something that my build system determines when it builds. Maybe there should be a way to either plumb that into uv’s cache or to tell uv that at least “uv sync” should run the designated command to (incrementally) rebuild my source tree? (Not that I can blame uv for failing to magically exfiltrate metadata from the black box that is hatchling plus its plugins.)
  - woodruffw 10mo ago