[ederamen]

Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool.

Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my primary language for everything. 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.

I know the performance meta in Python is to...not use python (bind to C, Rust, JVM) - and you can get pretty far with that (see: uv), but I'd rather spend my limited time building expertise in a language that isn't constantly hemorrhaging resources unless your code secretly calls something written in another language :/

There are so many good language options available today that compete. Python has become dominant in certain domains though, so you might not have a choice - which makes me grateful for these big steps forward in improving the tooling and ecosystem.

[liampulles]

I think Python has a place in many developers toolkits. I've never met anyone who hates Python (though I'm sure they exist), whereas for pretty much any other language one could mention there are much more polarizing viewpoints. (as the saying goes "Python is everyone's second favorite programming language").

The Python team needs not feel any pressure to change to compete, Python has already done quite well and found its niche.

[bashkiddie]

raises hand I hate python.

I am a user of pip binaries. Every few years one of them breaks.

As far as I understand, developers never cared about pinning their dependencies and python is fast to deprecate stuff.

  $ uvx remt
      Built pygobject==3.54.5
      Built remt==0.11.0
      Built pycairo==1.28.0
  Installed 12 packages in 9ms
  Traceback (most recent call last):
    File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/bin/remt", line 27, in <module>
    import remt
  File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/lib/python3.13/site-packages/remt/__init__.py", line 20, in <module>
    import pkg_resources
  ModuleNotFoundError: No module named 'pkg_resources'

  $ uvx maybe
  × Failed to build `blessings==1.6`
  ├─▶ The build backend returned an error
  ╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed (exit status:
      1)

      [stderr]
      /home/user/.cache/uv/builds-v0/.tmpsdhgNf/lib/python3.13/site-packages/setuptools/_distutils/dist.py:289:
      UserWarning: Unknown distribution option: 'tests_require'
        warnings.warn(msg)
      /home/user/.cache/uv/builds-v0/.tmpsdhgNf/lib/python3.13/site-packages/setuptools/_distutils/dist.py:289:
      UserWarning: Unknown distribution option: 'test_suite'
        warnings.warn(msg)
      error in blessings setup command: use_2to3 is invalid.

      hint: This usually indicates a problem with the package or the build
      environment.
  help: `blessings` (v1.6) was included because `maybe` (v0.4.0) depends on
        `blessings==1.6`

I heard rumors from computer vision developers that even libraries deprecate that fast.

[intrasight]

I've been mostly not using Python since it's arrival in the early 90s. Meaning I tinker with it but don't use it professionally.

[beeforpork]

Well, I hate Python. Main points for me: the scoping (or lack of it), the lack of declaration of new identifiers (linked to lack of scoping), the lack of update operators (like `a ||= (i > 0)`), the general lack of conciseness, the `a if b else c` confusion, the weirdness of comprehensions (particularly nested `for`s), the exceptions that are raised for non-exceptional cases. The heaviness of handling exception, like trying to delete a non-existing dict entry (need an additional `if` or a `try` block) or access a non-existing map entry (need to use `.get()` instead of `[]` or a `try` block).

Also, the syntax of layout is bad. I am not talking about layout itself, I do like Haskell syntax (despite being weird about parens). But if I write `a = b +` in Python on one line, then I get a syntax error, although the parser could instead assume that the expression is not terminated and must (obviously) continue on the next (indented) line. I hate that I need to use `\` or `(...)` to make this clear to the parser. I wrote parsers myself, and I know that it knows what needs to follow, and Python itself shows me that it knows: by raising a completely unnecessary syntax error.

It feels to me that the Python language design confuses `simple and easy` with `primitive`. If feels like a design without the knowledge of programming language research and ergonomy. It feels to me like a dangerous toy language, and I am never sure which of my stupid mistakes will be found by the compiler/interpreter, and which will just silently misinterpreted. And which of my perfectly valid requests will be rejected with an exception. In some aspects it feels less safe than C, particularly due to the lack of scoping and the danger of reuse of variables or introduction of new function local variables when actually, outer 'scope' variables were intended to be written.

This is not really meant as a rant, but it is a personal opinion, and I try to lay out my reasons. I am not trying to shame anyone who loves Python, but I just want to clarify that there are people who hate Python.

[cyberpunk]

raises hand I hate python.

Every python codebase i’ve had to look after has rotten to the point it doesn’t even build and is a maintenance nightmare.

I also hate whitespace instead of {}

[RamtinJ95]

I hate python and I use it everyday because I work in the data space. Its a toy scripting / glue language that has gotten used for far too much that it was not designed for. The usual suspects are also really annoying, such as white space instead of {}, no types, its so damn slow and all projects use so many packages and the packages use packages etc. That last one could just be a personal preference thing to I will admit, but the rest are just almost objectively bad. Especially when building infrastructure like a data platform.

[miki123211]

I wish we had a language that had the syntax of Python (notably including operator overloading, which is absolutely critical for neural networks, ML, data science and numerical computations), the performance, compile times and concurrency support of Go, the type system flexibility of Typescript, and the native platform integration of C/C++.

[AyanamiKaine]

Than you would probably like the Nim[1] programming language. It has the syntax of python, but transpiles to C/C++. A good type system. The main problem would probably the compiles times. Because you basically compile just C/C++ code. And of course the eco-system is much much smaller than Python.

[1] https://nim-lang.org/

[thayne]

Rust doesn't quite hit all of those, but it hits a lot of them.

It's syntax is significantly different from python, but it does have operator overloading.

It's performance is comparable to go, and has good concurrency support, although it is different than go, and there are still some rough edges with "async" code. Compile times aren't as good as go though.

The type system is excellent, although I'm not really sure what you mean by "flexible".

And FFI support is great.

[antocuni]

This looks exactly what I'm trying to do with SPy -- although SPy is still "not there" and it's WIP. I literally wrote an intro post about it yesterday: https://antocuni.eu/2025/10/29/inside-spy-part-1-motivations...

[CraigJPerry]

Mojo is aiming at that. I've decided it's this years advent of code language for me and kinda looking forward to learning more about it.

[wjholden]

I think Julia largely accomplishes these goals except for the platform integration.

[rewgs]

There's Mojo, but it's been a while since I've heard anything about it.

https://www.modular.com/mojo

[cogman10]

Kotlin on a modern JVM comes pretty close.

* Performance - the JVM is very competitive with C/C++ performance.

* Compile times - Not go fast, but not C/C++/Rust slow.

* Concurrency - Virtual threads (finalized in 21) bring in the concurrency capabilities of go to the JVM

* Type System Flexibility - Kotlin isn't quite as flexible as Typescript, but it's pretty close. It's more flexible than java but not as flexible as scala. I think it strikes a good middle ground.

* Native platform integration - This is probably the weakest part of the JVM but it's gotten a lot better with the work done on Project Panama (mostly delivered in 22). Jextract makes it a lot easier to make native integrations with Java. Definitely not as painful as the JNI days.

There's also kotlin native that you could play around with (I haven't).

[quaintdev]

I feel so much comfortable with Go's type system than Typescript's

[callamdelaney]

Why would operator overloading be absolutely critical? Just use methods. The pipe operator already has around 15 uses and counting, it doesn’t need more

[yard2010]

Also, case matching of Scala <3

[bigpeopleareold]

Free Pascal with better tooling?

[movpasd]

You may be interested in Mojo, it's a project by Chris Lattner. It aims to have Python-like syntax and smooth integration with Python but allow Rust-like low-level control (I believe it has a borrow checker). Unfortunately, I believe it's proprietary.

[teiferer]

> 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.

[wiseowise]

There’s this thing where you work to requirements instead of picking things on vibes, it’s called engineering.

[alex_duf]

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.

[whatevaa]

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.

[Epa095]

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'.

[PeterStuer]

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.

[heinrichhartman]

Well Python Language should be seen as an UI layer for C++/C. Not out of character to use Rust for "heavy lifting"

[jmaker]

In a similar vein, Microsoft TypeScript team picked Go for the new TypeScript transpiler engine.

[AdamN]

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.

[rk06]

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.

[zahlman]

> 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.

[franktankbank]

Bash is written in what?

[wiz21c]

the python interpreter is not written in python :-)

[amelius]

My main question is: how good is it when it breaks? Because with most build/package tools that's when the misery starts.

[Jaxkr]

On performance: 3.13 removed the GIL and added experimental first-party JIT (like PyPy).

In two years I bet we’ll be seeing v8 level performance out of CPython.

[pansa2]

The “Faster CPython” team were let go from Microsoft because they could only produce a 1.5x speedup in four years instead of the planned 5x.

It’s wildly optimistic to now expect a 10x speedup in two years, with fewer resources.

[heavyset_go]

I'd be surprised if we saw anything more than the 4x speedup from compiling Python with something like Nuitka/mypyc/etc can bring.

I also believe the JIT in v8 and Python are different, the latter relying on copy-and-patch while v8 uses a bunch of different techniques together.

[rslashuser]

I would surprised to see performance as good as V8, although that would be great. As I recall the v8 team performed exceptionally well in a corporate environment that badly wanted js performance to improve, and maybe inherited some Hotspot people at the right time.

I'd be quite delighted to see, say, 2x Python performance vs. 3.12. The JIT work has potential, but thus far little has come of it, but in fairness it's still the early days for the JIT. The funding is tiny compared to V8. I'm surprised someone at Google, OpenAI et al isn't sending a little more money that way. Talk about shared infrastructure!

[t43562]

pypy is probably faster. Lets put effort into that. BUT the dynamic features that make python lovely are always going to limit its performance.

If you're using python because you have to then you might not like all that and might see it as something to toss out. This makes me sad.

[motoboi]

I bet we’ll be seeing python compiled to JVM of getting JVM levels of performance. Much better than v8

[ShroudedNight]

Has something changed that allows a more relaxed refcounting / less eager "gc"? Py_DECREF was what murdered any hope of performance back when we hooked up 3.3 to OMR... Well that and the complete opacity of everything implemented in C

[CamouflagedKiwi]

It didn't "remove the GIL". It added an experimental free-threading mode which removes it, but is still considered experimental and not widely used in production yet.

[zahlman]

> I know the performance meta in Python is to...not use python (bind to C, Rust, JVM) - and you can get pretty far with that (see: uv), but I'd rather spend my limited time building expertise in a language that isn't constantly hemorrhaging resources unless your code secretly calls something written in another language :/

In case it encourages you: a lot of uv's performance benefits come from things that are not the implementation language. In particular, it has a much more intelligent system for caching downloaded package artifacts, and when asked to pre-compile bytecode it can use multiple cores (this is coming soon to pip, to my understanding; actually the standard library already has a primitive implementation).

[rjzzleep]

Am I the only one that's sad that poetry happened before pdm otherwise we might have had pdm as a standard instead of uv, addressing many of the things uv addresses without all the extra bells and whistles that make it cumbersome. I don't like the wedding between package manager and install manager.

... but then again neither pdm nor uv would have happened without poetry.

[miki123211]

I think in Python specifically, an install manager is absolutely the right call. There's far too much breakage between Python versions.

I recently had to downgrade one of our projects to 3.12 because of a dependency we needed. With uv, I can be sure that everybody will be running the project on 3.12, it just all happens automatically. Without uv, I'd get the inevitable "but your changes crashed the code, have you even tested them?"

[testdelacc1]

How do extra bells and whistles bother you? You had the option to not use them. Like you said yourself, they’re “extra”.

[pjc50]

What is the distinction between "package manager and install manager"?

[ErikBjare]

Honestly I think poetry was a bigger development than uv. I used pipenv before it, and requirements before that, and I can't imagine going back. I've yet to fully embrace uv and migrate away from poetry for that reason (even thought it seems inevitable at this point, there's just no need)

[txdv]

Just profile the slow parts and rewrite them in rustm, easy.

[ActorNightly]

> 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.

Post like these aptly describe why companies are downsizing in lieu of AI assistants, and they are not wrong for doing so.

Yes, Python is "slow". The thing is, compute is cheap these days and development time is expensive. $1000 per month is considered expensive as hell for an EC2 instance, but no developer would work for $12000 a year.

Furthermore, in modern software dev, most of the bottlenecks is network latency. If your total end to end operation takes 200ms mostly because of network calls, it doesn't matter if you code runs in 10 ms or 5ms as far as compute goes.

When it comes to development, the biggest uses of time are

1. Interfacing with some API or tool, for which you have to write code 2. Making a change, testing a change, fixing bugs.

Python has both covered better than any other language. Just today, it took me literally 10 mins to write code for a menu bar for my Mac using rumps python library so I have most commonly used commands available without typing into a terminal, and that is without using an LLM. Go ahead and try to do the same in Java or Rust or C++ and I promise you that unless you have experience with Mac development, its going to take you way more time. Python has additional things like just putting breakpoint() where you want the debugger, jupyter notebooks for prototyping, and things like lazy imports where you use import inside a function so large modules only get loaded when they run. No compilation step, no complex syntax. Multiprocessing is very easy to use as a replacement for threading, really dunno why people want to get rid of GIL so much. Functionally the only difference is overhead in launching a thread vs launching a process, and shared memory. But with multiprocessing API, you simply spin up a worker pool and send data over Pipes, and its pretty much just as fast as multithreading.

In the end, the things that matter are results. If LLMs can produce code that works, no matter how stringy it is, that code can run in production and start making company money, while they don't have to pay you money for multiple months to write the code yourself. Likewise, if you are able to develop things fast, and a company has to spend a bit more on compute, its a no brainer on using Python.

Meanwhile like strong typing, speed, GIL, and other popular things that get mentioned is all just echos of bullshit education that you learned in CS, and people repeat them without actually having any real world experience. So what if you have weak typing and make mistakes - code fails to run or generate correct results, you go and fix the code, and problem solved. People act like failing code makes your computer explode or something. There is no functional difference between a compilation failure and a code running failure. And as far as production goes, there has never been a case of a strong type language that gets used that gets deployed and doesn't have any bugs, because those bugs are all logic bugs within the actual code. And consequently, with Python, its way easier to fix those bugs.

Youtube, Uber, and a bunch of other well used services all run Python backends for a good reason. And now with skilled LLM usage, a single developer can write services in days that would take a team of engineers to write in weeks.

So TL:DR, if you actually want to stay competitive, use Python. The next set of LLMs are all going to be highly specialized smaller models, and being able to integrate them into services with Pytorch is going to be a very valuable skill, and nobody who is hiring will give a shit how memory safe Rust is.

[saagarjha]

I write Python all day for work and I run into its issues all the time, be it performance or weak typing or just lack of modern language features. If you’re just vibecoding all day and that’s ok for what you want it to do, all the more power to you, but do at least take a moment to understand that when people want things you see no value in maybe they just have different requirements than you do.

[spooky_deep]

The irony here is UV is written in Rust.

[DeathArrow]

Python is bad for large projects, and it's not just because of speed.

I see it shine for scripts and AI but that's it.

[DeathArrow]

>$1000 per month is considered expensive as hell for an EC2 instance, but no developer would work for $12000 a year.

If using Python instead of what we use, our cloud costs would be more than double.

And I can't go to CEO and CFO and explain to them that I want to double the cloud costs (which are already seen as high).

Then, our development speed won't really improve because we have large projects.

That being said, I think using Python for scripting is great in our case.