6 ms·

I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous wit

I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous with CPython. I think 2 languages are enough, we don't need a 3rd one that nobody asked for. I have nothing against Rust. If you want a new tool, go for it. If you want a re-write of an existing tool, go for it. I'm against it creeping into an existing eco-system for no reason. A popular Python package called Pendulum went over 7 months without support for 3.13. I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself. https://github.com/python-pendulum/pendulum/issues/844 https://github.com/python-pendulum/pendulum/issues/844 In my ideal world if someone wanted fast datetimes written in Rust (or any other language other than C) they'd write a proper library suitable for any language to consume over FFI. So far this Rust stuff has left a bad taste in my mouth and I don't blame the Linux community for being resistant.

moolcool 1y ago
> I am totally against Python tooling being written in a language other than Python I will be out enjoying the sunshine while you are waiting for your Pylint execution to finish
- throwawaysleep 1y ago
  Linting is the new "compiling!"
- lillecarl 1y ago
  Linting and type checking are very CPU intensive tasks so I would excuse anyone implementing those types of tools in $LANG where using all CPU juice matters. I can't help but think uv is fast not because it's written in Rust but because it's a fast reimplementation. Dependency solving in the average Python project is hardly computationally expensive, it's just downloading and unpacking packages with a "global" package cache. I don't see why uv couldn't have been implemented in Python and be 95% as fast. Edit: Except implementing uv in Python requires shipping a Python interpreter kinda defeating some of it's purpose of being a package manager able to install Python as well.
  - nonethewiser 1y ago
    You also have to factor in startup time and concurrency. Caching an SAT solvers can't get python to 95% of uv.
  - Daishiman 1y ago
    Nope, this is totally an area where using Rust makes sense and is just _fast_. The fact that Rust has concurrency primitives that are easy to use helps tons too.
    - lillecarl 1y ago
      I still don't get it, uv is checking if dependencies exist on disk, if they do it creates a link from the cache to your environment, it's a stat syscall and a hardlink syscall in the best of worlds (after solving dependency versions but that should already be done in a lockfile). Interpreter startup time is hardly significant once in one invocation to set up your environment. What makes Rust faster for downloading and unpacking dependencies. Considering how slow pip is and how fast uv is (100s of X) it seems naive to attribute it to the language.
hoppp 1y ago
I love rust but I tend to agree, python tooling should be maintainable by the community without learning a new language. However rust is a thousand times faster than python. At the end, if you don't like it don't use it.
nchmy 1y ago
What, exactly, is your objection to using rust (or any non-python/C language) for python tooling? You didn't actually give any reasons
- jftuga 1y ago
  I believe he alluded to it here... "I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself."
  - ericfrederich 1y ago
    Correct. There better be a damn good reason to add another language to the ecosystem other than it's that particular developer's new favorite language. Is there anything being done in uv that couldn't be done in Python?
    - nyzs 1y ago
      speed
      - ericfrederich 1y ago
        I don't see any meaningful speedup. The 10x claims are not reproducible. He's also comparing it to the much older style of requirements.txt projects and not a poetry project with a lockfile. I detailed this in another comment but pip (via requirements.txt): 8.1s, poetry: 3.7s, uv: 2.1s. Not even 10x against pip and certainly not against poetry.
        nchmy 1y ago
        You must be holding it wrong, because everyone else raves about uv
        cpburns2009 1y ago
masklinn 1y ago
According to the very link you provide, the sticking point was a dependency which does not use rust, and the maintainer probably being busy. I updated a rust-implemented wheel to 3.13 compat myself and literally all that required was bumping pyo3 (which added support back in June) and adding the classifier. Afaik cryptography had no trouble either, iirc what they had to wait on was a 3.13 compatible cffi .
- ericfrederich 1y ago
  The PR which enabled 3.13 did have changes to Rust code. https://github.com/python-pendulum/pendulum/pull/871 https://github.com/python-pendulum/pendulum/pull/871
  - masklinn 1y ago
    Because they did more than just support 3.13: > I'm sure some of the changes are going too far. We are open to revert them if there's an interest from maintainers to merge this PR :) Notably they bumped the bindings (“O3”) for better architecture coverage, and that required some renaming as 0.23 completed an API migration.
patcon 1y ago
Upvoting for interesting/important/sympathetic perspective, but am very much in disagreement
- mh- 1y ago
  Offtopic, but thank you. I really wish this way of treating up/downvotes was more widespread. Down should mean it doesn't contribute to the conversation, not that you disagree with their opinion.
guardian5x 1y ago
you say "I'm against it creeping into an existing eco-system for no reason.", while you ignore that there is at least one good reason: A lot better performance.
- ericfrederich 1y ago
  The 10x performance wasn't mentioned in the article at all except the title. I watched the video and he does mention it going from 30s to 3s when switching from a requirements.txt approach to a uv based approach. No comparison was done against poetry. I am unable to reproduce these results. I just copied his dependencies from the pyproject.toml file into a new poetry project. I ran `poetry install` from within Docker (to avoid using my local cache) `docker run --rm -it -v `pwd`:/work python:3.13 /bin/bash` and it took 3.7s I did the same with an empty repo and a requirements.txt file and it took 8.1s. I also did through `uv` and it took 2.1s. Better performance?, sure. A lot better performence?, I can't say that with the numbers I got. 10x performance?... absolutely not. Also, this isn't a major part of anybody's workflow. Docker builds happen typically on release. Maybe when running tests during CI/CD after the majority of work has been done locally.
  - mixmastamyk 1y ago
    I personally don’t care about the performance: https://news.ycombinator.com/item?id=44359183 https://news.ycombinator.com/item?id=44359183 I agree it would be better if it was in Python but pypa did not step up, for decades! On the other hand, it is not powershell or ruby, it is a single deployed executable that works. I find that acceptable if not perfect.
- cjaybo 1y ago
  Better performance than C? This is news to me
  - kibwen 1y ago
    There are cases where single-threaded Rust and C are faster than each other, though usually only by single-digit percentages. But Rust is so much easier to parallelize than C that it isn't even funny.
greener_grass 1y ago
Rust offers a feature-set that neither Python nor C has. If Rust is the right tool for the job, I would rather the code be written in Rust. Support has more to do with incentive structures than implementation language.
Gabrys1 1y ago
I, on the other hand, don't care what language the tools are written in. I do get the sentiment that a user of these tools, being a Python developer could in theory contribute to them. But, if a tool does its job, I don't care if it's not "in Python". Moreover, I imagine there is a class of problems with the Python environment setup that'd break the tool that could help you fix it if the tool itself is written in Python.
- HelloNurse 1y ago
  It is well known, and not Python-specific, that using a different language/interpreter for development tools eliminates large classes of bootstrapping complications and conflicts. If there are two versions of X, it becomes possible to use the wrong one. If a tool to manage X depends on X, some of the changes that we would like the tool to perform are more difficult, imperfect or practically impossible.
manojlds 1y ago
Did you even read the issue that you pointed to? It's not even the rust part that was the issue.
bodge5000 1y ago
In theory, I can get behind what your saying, but in practice I just haven't found any package manager written in Python to be as good as uv, and I'm not even talking about speed. uv as I like it could be written in Python, but it hasn't been
- RamblingCTO 1y ago
  I really dig rye, have you tried that?
  - gschizas 1y ago
    rye is also written in Rust and it's being replaced by uv. From its homepage: https://rye.astral.sh/ https://rye.astral.sh/ > If you're getting started with Rye, consider uv, the successor project from the same maintainers. > While Rye is actively maintained, uv offers a more stable and feature-complete experience, and is the recommended choice for new projects. > Having trouble migrating? Let us know what's missing.
  - Kwpolska 1y ago
    It's also Rust.
lvl155 1y ago
I understand this sentiment. Part of it was people trying to build up their cv for Rust. On the other hand, some tools/libraries in Python were old. Take pandas for example, it was not good for modern use. We desperately needed something like polars and even that is being outpaced by current trends.
- theLiminator 1y ago
  Curious what you see as outpacing polars, hybrid analytical/streaming query engines?
mvieira38 1y ago
Or maybe the community will embrace Rust as it is implemented... There's no reason to think because you or the current gen of Python devs are focused on C then the next gen or further will too.
sgarland 1y ago
Python is my favorite language, but I have fully embraced uv. It’s so easy, and so fast, that there is nothing else remotely close. Need modern Python on an ancient server running with EOL’d distro that no one will touch for fear of breaking everything? uv. Need a dependency or two for a small script, and don’t want to hassle with packaging to share it? uv. That said, I do somewhat agree with your take on extensions. I have a side project I’ve been working on for some years, which started as pure Python. I used it as a way to teach myself Python’s slow spots, and how to work around them. Then I started writing the more intensive parts in C, and used ctypes to interface. Then I rewrote them using the Python API. I eventually wrote so much of it in C that I asked myself why I didn’t just write all of it in C, to which my answer was “because I’m not good enough at C to trust myself to not blow it up,” so now I’m slowly rewriting it in Rust, mostly to learn Rust. That was a long-winded way to say that I think if your external library functions start eclipsing the core Python code, that’s probably a sign you should write the entire thing in the other language.
coldtea 1y ago
>I am totally against Python tooling being written in a language other than Python. Cool story bro. I'm totally against Python tooling being in dismal dissaray for 30 years I've been using the language, and if it takes some Rust projects to improve upon it, I'm all for it. I also not rather have the chicken-and-egg dependency issue with Python tooling written in Python. >A popular Python package called Pendulum went over 7 months without support for 3.13. I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself. Somehow the availability and wide knowledge of C didn't make anyone bother writing a datetime management lib in C and making it as popular. It took those Pendulum Rust coders. And you could of course use pytz or dateutil or some other, but, no, you wanted to use the Rust-Python lib. Well, when you start the project yourself, you get to decide what language it would be in.
nonethewiser 1y ago
>I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous with CPython. >I think 2 languages are enough, we don't need a 3rd one that nobody asked for. Enough for what? The uv users dont have to deal with that. Most ecosystems use a mix of language for tooling. It's not a detail the user of the tool has to worry about. >I'm against it creeping into an existing eco-system for no reason. It's much faster. Because its not written in Python. The tooling is for the user. The language of the tooling is for the developer of the tooling. These dont need to be the same people. The important thing is if the tool solves a real problem in the ecosystem (it does). Do people like it?
ufmace 1y ago
I appreciate this perspective, but I think building a tool like uv in Rust is a good idea because it's a tool for managing Python stuff, not a tool to be called from within Python code. Having your python management tools also be written in python creates a chicken-and-egg situation. Now you have to have a working python install before you can start your python management tool, which you are presumably using because it's superior to managing python stuff any other way. Then you get a bunch of extra complex questions like, what python version and specific executable is this management tool using? Is the actual code you're running using the same or a different one? How about the dependency tree? What's managing the required python packages for the installation that the management tool is running in? How do you know that the code you're running is using its own completely independent package environment? What happens if it isn't, and there's a conflict between a package or version your app needs and what the management tool needs? How do you debug and fix it if any of this stuff isn't actually working quite how you expected? Having the management tool be a compiled binary you can just download and use, regardless of what language it was written in, blows up all of those tricky questions. Now the tool actually does manage everything about python usage on your system and you don't have to worry about using some separate toolchain to manage the tool itself and whether that tool potentially has any conflicts with the tool you actually wanted to use.
peterhadlaw 1y ago
I had a situation, admittedly niche, where some git based package dependency wasn't being updated properly (tags vs. commit hashes) and thanks to poetry being written in Python I was able to quickly debug and solve the problem. I think it's more a matter of core functionality (that affects everyone) vs. more esoteric or particular use cases (like dataframe libraries) that make sense to FFI.
kzrdude 1y ago
> I think 2 languages are enough, we don't need a 3rd one that nobody asked for. Look at the number of stars ruff and uv got on github. That's a meteoric rise. So they were validated with ruff, and continued with uv, this we can call "was asked for". > I'm against it creeping into an existing eco-system for no reason. It's not no reason. A lot of other things have been tried. It's for big reasons: Good performance, and secondly independence from Python is a feature. When your python managing tool does not depend on Python itself, it simplifies some things.
0x457 1y ago
> I'm against it creeping into an existing eco-system for no reason. There is a reason: tools that exist today are awful and unusable if you ever wrote anything other than python. : I'm saying it because the only way I can see someone not realizing it is that they have never seen anything better. Okay, maybe C and C++ have even worse tooling in some areas, but python is still the top language of having the worst tooling.
pabs3 1y ago
I'm wondering why folks aren't moving wholesale from Python to Rust, seems like it would be better for everyone.
- whytevuhuni 1y ago
  It would be a wholesale move from one of the easiest programming languages to start on, to one of the hardest languages to start on. Most programmers I've met were beginners, and they need something easier to work with until they can juggle harder concepts easily.
- masklinn 1y ago
  Because rust is a lot harder to experiment with and really does not work for interactive or notebook stuff. Python also has a massive ecosystem of existing libraries. And thus rust is used to either make tools, or build libraries (de novo or out of rust libraries), which plays to both strengths.

moolcool 1y ago

> I am totally against Python tooling being written in a language other than Python I will be out enjoying the sunshine while you are waiting for your Pylint execution to finish

throwawaysleep 1y ago
Linting is the new "compiling!"
lillecarl 1y ago
Linting and type checking are very CPU intensive tasks so I would excuse anyone implementing those types of tools in $LANG where using all CPU juice matters. I can't help but think uv is fast not because it's written in Rust but because it's a fast reimplementation. Dependency solving in the average Python project is hardly computationally expensive, it's just downloading and unpacking packages with a "global" package cache. I don't see why uv couldn't have been implemented in Python and be 95% as fast. Edit: Except implementing uv in Python requires shipping a Python interpreter kinda defeating some of it's purpose of being a package manager able to install Python as well.
- nonethewiser 1y ago
  You also have to factor in startup time and concurrency. Caching an SAT solvers can't get python to 95% of uv.
- Daishiman 1y ago
  Nope, this is totally an area where using Rust makes sense and is just _fast_. The fact that Rust has concurrency primitives that are easy to use helps tons too.
  - lillecarl 1y ago
    I still don't get it, uv is checking if dependencies exist on disk, if they do it creates a link from the cache to your environment, it's a stat syscall and a hardlink syscall in the best of worlds (after solving dependency versions but that should already be done in a lockfile). Interpreter startup time is hardly significant once in one invocation to set up your environment. What makes Rust faster for downloading and unpacking dependencies. Considering how slow pip is and how fast uv is (100s of X) it seems naive to attribute it to the language.

hoppp 1y ago

I love rust but I tend to agree, python tooling should be maintainable by the community without learning a new language. However rust is a thousand times faster than python. At the end, if you don't like it don't use it.

nchmy 1y ago

What, exactly, is your objection to using rust (or any non-python/C language) for python tooling? You didn't actually give any reasons

jftuga 1y ago
I believe he alluded to it here... "I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself."
- ericfrederich 1y ago
  Correct. There better be a damn good reason to add another language to the ecosystem other than it's that particular developer's new favorite language. Is there anything being done in uv that couldn't be done in Python?
  - nyzs 1y ago
    speed
    - ericfrederich 1y ago
      I don't see any meaningful speedup. The 10x claims are not reproducible. He's also comparing it to the much older style of requirements.txt projects and not a poetry project with a lockfile. I detailed this in another comment but pip (via requirements.txt): 8.1s, poetry: 3.7s, uv: 2.1s. Not even 10x against pip and certainly not against poetry.
      - nchmy 1y ago
        You must be holding it wrong, because everyone else raves about uv
        cpburns2009 1y ago

masklinn 1y ago

According to the very link you provide, the sticking point was a dependency which does not use rust, and the maintainer probably being busy. I updated a rust-implemented wheel to 3.13 compat myself and literally all that required was bumping pyo3 (which added support back in June) and adding the classifier. Afaik cryptography had no trouble either, iirc what they had to wait on was a 3.13 compatible cffi .

ericfrederich 1y ago
The PR which enabled 3.13 did have changes to Rust code. https://github.com/python-pendulum/pendulum/pull/871 https://github.com/python-pendulum/pendulum/pull/871
- masklinn 1y ago
  Because they did more than just support 3.13: > I'm sure some of the changes are going too far. We are open to revert them if there's an interest from maintainers to merge this PR :) Notably they bumped the bindings (“O3”) for better architecture coverage, and that required some renaming as 0.23 completed an API migration.

patcon 1y ago

Upvoting for interesting/important/sympathetic perspective, but am very much in disagreement

mh- 1y ago
Offtopic, but thank you. I really wish this way of treating up/downvotes was more widespread. Down should mean it doesn't contribute to the conversation, not that you disagree with their opinion.

guardian5x 1y ago

you say "I'm against it creeping into an existing eco-system for no reason.", while you ignore that there is at least one good reason: A lot better performance.

ericfrederich 1y ago
The 10x performance wasn't mentioned in the article at all except the title. I watched the video and he does mention it going from 30s to 3s when switching from a requirements.txt approach to a uv based approach. No comparison was done against poetry. I am unable to reproduce these results. I just copied his dependencies from the pyproject.toml file into a new poetry project. I ran `poetry install` from within Docker (to avoid using my local cache) `docker run --rm -it -v `pwd`:/work python:3.13 /bin/bash` and it took 3.7s I did the same with an empty repo and a requirements.txt file and it took 8.1s. I also did through `uv` and it took 2.1s. Better performance?, sure. A lot better performence?, I can't say that with the numbers I got. 10x performance?... absolutely not. Also, this isn't a major part of anybody's workflow. Docker builds happen typically on release. Maybe when running tests during CI/CD after the majority of work has been done locally.
- mixmastamyk 1y ago
  I personally don’t care about the performance: https://news.ycombinator.com/item?id=44359183 https://news.ycombinator.com/item?id=44359183 I agree it would be better if it was in Python but pypa did not step up, for decades! On the other hand, it is not powershell or ruby, it is a single deployed executable that works. I find that acceptable if not perfect.
cjaybo 1y ago
Better performance than C? This is news to me
- kibwen 1y ago
  There are cases where single-threaded Rust and C are faster than each other, though usually only by single-digit percentages. But Rust is so much easier to parallelize than C that it isn't even funny.

greener_grass 1y ago

Rust offers a feature-set that neither Python nor C has. If Rust is the right tool for the job, I would rather the code be written in Rust. Support has more to do with incentive structures than implementation language.

Gabrys1 1y ago

I, on the other hand, don't care what language the tools are written in. I do get the sentiment that a user of these tools, being a Python developer could in theory contribute to them. But, if a tool does its job, I don't care if it's not "in Python". Moreover, I imagine there is a class of problems with the Python environment setup that'd break the tool that could help you fix it if the tool itself is written in Python.

HelloNurse 1y ago
It is well known, and not Python-specific, that using a different language/interpreter for development tools eliminates large classes of bootstrapping complications and conflicts. If there are two versions of X, it becomes possible to use the wrong one. If a tool to manage X depends on X, some of the changes that we would like the tool to perform are more difficult, imperfect or practically impossible.

manojlds 1y ago

Did you even read the issue that you pointed to? It's not even the rust part that was the issue.

bodge5000 1y ago

In theory, I can get behind what your saying, but in practice I just haven't found any package manager written in Python to be as good as uv, and I'm not even talking about speed. uv as I like it could be written in Python, but it hasn't been

RamblingCTO 1y ago
I really dig rye, have you tried that?
- gschizas 1y ago
  rye is also written in Rust and it's being replaced by uv. From its homepage: https://rye.astral.sh/ https://rye.astral.sh/ > If you're getting started with Rye, consider uv, the successor project from the same maintainers. > While Rye is actively maintained, uv offers a more stable and feature-complete experience, and is the recommended choice for new projects. > Having trouble migrating? Let us know what's missing.
- Kwpolska 1y ago
  It's also Rust.

lvl155 1y ago

I understand this sentiment. Part of it was people trying to build up their cv for Rust. On the other hand, some tools/libraries in Python were old. Take pandas for example, it was not good for modern use. We desperately needed something like polars and even that is being outpaced by current trends.

theLiminator 1y ago
Curious what you see as outpacing polars, hybrid analytical/streaming query engines?

mvieira38 1y ago

Or maybe the community will embrace Rust as it is implemented... There's no reason to think because you or the current gen of Python devs are focused on C then the next gen or further will too.

sgarland 1y ago

Python is my favorite language, but I have fully embraced uv. It’s so easy, and so fast, that there is nothing else remotely close. Need modern Python on an ancient server running with EOL’d distro that no one will touch for fear of breaking everything? uv. Need a dependency or two for a small script, and don’t want to hassle with packaging to share it? uv. That said, I do somewhat agree with your take on extensions. I have a side project I’ve been working on for some years, which started as pure Python. I used it as a way to teach myself Python’s slow spots, and how to work around them. Then I started writing the more intensive parts in C, and used ctypes to interface. Then I rewrote them using the Python API. I eventually wrote so much of it in C that I asked myself why I didn’t just write all of it in C, to which my answer was “because I’m not good enough at C to trust myself to not blow it up,” so now I’m slowly rewriting it in Rust, mostly to learn Rust. That was a long-winded way to say that I think if your external library functions start eclipsing the core Python code, that’s probably a sign you should write the entire thing in the other language.

coldtea 1y ago

>I am totally against Python tooling being written in a language other than Python. Cool story bro. I'm totally against Python tooling being in dismal dissaray for 30 years I've been using the language, and if it takes some Rust projects to improve upon it, I'm all for it. I also not rather have the chicken-and-egg dependency issue with Python tooling written in Python. >A popular Python package called Pendulum went over 7 months without support for 3.13. I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself. Somehow the availability and wide knowledge of C didn't make anyone bother writing a datetime management lib in C and making it as popular. It took those Pendulum Rust coders. And you could of course use pytz or dateutil or some other, but, no, you wanted to use the Rust-Python lib. Well, when you start the project yourself, you get to decide what language it would be in.

nonethewiser 1y ago

>I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous with CPython. >I think 2 languages are enough, we don't need a 3rd one that nobody asked for. Enough for what? The uv users dont have to deal with that. Most ecosystems use a mix of language for tooling. It's not a detail the user of the tool has to worry about. >I'm against it creeping into an existing eco-system for no reason. It's much faster. Because its not written in Python. The tooling is for the user. The language of the tooling is for the developer of the tooling. These dont need to be the same people. The important thing is if the tool solves a real problem in the ecosystem (it does). Do people like it?

ufmace 1y ago

I appreciate this perspective, but I think building a tool like uv in Rust is a good idea because it's a tool for managing Python stuff, not a tool to be called from within Python code. Having your python management tools also be written in python creates a chicken-and-egg situation. Now you have to have a working python install before you can start your python management tool, which you are presumably using because it's superior to managing python stuff any other way. Then you get a bunch of extra complex questions like, what python version and specific executable is this management tool using? Is the actual code you're running using the same or a different one? How about the dependency tree? What's managing the required python packages for the installation that the management tool is running in? How do you know that the code you're running is using its own completely independent package environment? What happens if it isn't, and there's a conflict between a package or version your app needs and what the management tool needs? How do you debug and fix it if any of this stuff isn't actually working quite how you expected? Having the management tool be a compiled binary you can just download and use, regardless of what language it was written in, blows up all of those tricky questions. Now the tool actually does manage everything about python usage on your system and you don't have to worry about using some separate toolchain to manage the tool itself and whether that tool potentially has any conflicts with the tool you actually wanted to use.

peterhadlaw 1y ago

I had a situation, admittedly niche, where some git based package dependency wasn't being updated properly (tags vs. commit hashes) and thanks to poetry being written in Python I was able to quickly debug and solve the problem. I think it's more a matter of core functionality (that affects everyone) vs. more esoteric or particular use cases (like dataframe libraries) that make sense to FFI.

kzrdude 1y ago

> I think 2 languages are enough, we don't need a 3rd one that nobody asked for. Look at the number of stars ruff and uv got on github. That's a meteoric rise. So they were validated with ruff, and continued with uv, this we can call "was asked for". > I'm against it creeping into an existing eco-system for no reason. It's not no reason. A lot of other things have been tried. It's for big reasons: Good performance, and secondly independence from Python is a feature. When your python managing tool does not depend on Python itself, it simplifies some things.

0x457 1y ago

> I'm against it creeping into an existing eco-system for no reason. There is a reason: tools that exist today are awful and unusable if you ever wrote anything other than python. : I'm saying it because the only way I can see someone not realizing it is that they have never seen anything better. Okay, maybe C and C++ have even worse tooling in some areas, but python is still the top language of having the worst tooling.

pabs3 1y ago

I'm wondering why folks aren't moving wholesale from Python to Rust, seems like it would be better for everyone.

whytevuhuni 1y ago
It would be a wholesale move from one of the easiest programming languages to start on, to one of the hardest languages to start on. Most programmers I've met were beginners, and they need something easier to work with until they can juggle harder concepts easily.
masklinn 1y ago
Because rust is a lot harder to experiment with and really does not work for interactive or notebook stuff. Python also has a massive ecosystem of existing libraries. And thus rust is used to either make tools, or build libraries (de novo or out of rust libraries), which plays to both strengths.