> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell.
Case in point: uv itself is not written in Python. It's a Rust tool.
It always amazes me when people work on an ecosystem for a language but then don't buy enough into that to actually use it to do the work.
Avoidance of dogfooding is a big red flag to me.
There’s this thing where you work to requirements instead of picking things on vibes, it’s called engineering.
I understand the argument but the language used for uv (rust) and python don't have the same goal.
Python aims to be simple, not particularly fast (though it is getting faster)
I don't see a problem with that. Pick the language adapted to your problem. Python isn't aiming at solving every problem and that's okay.
> Python aims to be simple
Well, it wildly missed the mark there. Nothing about modern Python is simple. It's a very complex language hiding behind friendly syntax.
Hard disagree. Python is so simple anyone can get up and running with coding in a few lines in the REPL.
Simple != easy. Rich Hickey has the details:
https://www.youtube.com/watch?v=SxdOUGdseq4
Python performance is poor. Python achieves performance by having as little python code as possible. The runtime and all performant libraries are not in python.
It's ok for IO bound but not for CPU bound work.
And that's how languages start optimizing towards being a better language to write compilers in ;-)
It's completely fair for a language to have a niche different that 'quick start-up and runtime'.
Different tools for different use cases.
Would you write an assembler IDE in assembler?
I use Python for >90% of my code these days. I love uv for its ux and speed. I 0% care it wasn't written in Python. In fact, making it fully independent of any existing Python environment is a plus for the Python user. No weird bootstrap problems.
It does not make me switch to Rust for my own code.
Well Python Language should be seen as an UI layer for C++/C. Not out of character to use Rust for "heavy lifting"
In a similar vein, Microsoft TypeScript team picked Go for the new TypeScript transpiler engine.
That's like every language. The language you work in (typically) has all sorts of libraries that are lower level. And even if not it's not like you're code is 'running', it's compiling to lower level code that actually runs and the compilers that do that work are usually black box unless you're a compiler engineer.
The power of Python is that it's high level and very powerful and has a great community and ecosystem of tools/libraries. There's absolutely zero problem and totally a good thing if there are core libraries written in faster languages.
> It always amazes me when people work on an ecosystem for a language but then don't buy enough into that to actually use it to do the work.
> Avoidance of dogfooding is a big red flag to me.
I'm making PAPER for a reason.
Interpreted languages are not the best choicce for a variety of software. for eg: Vast amount of performance issues in typescript cli boil down to being written in typescript, and team is porting to golang now.
Tools specifically CLI tools, are best written in statically typed compiled languages.
Bash is written in what?
the python interpreter is not written in python :-)
it can be though and pypy is