9 ms·

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

• Jaxkr 11mo ago
  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.
  • motoboi 11mo ago
    I bet we’ll be seeing python compiled to JVM of getting JVM levels of performance. Much better than v8
    • necovek 11mo ago
      There have for a long time been IronPython (CLR) and and Jython (JVM). But, they don't have the full compatibility with CPython, so nobody really picks them up.
      • CamouflagedKiwi 11mo ago
        Jython seems to be effectively dead though - it only has 2.7 compatibility.
        • necovek 11mo ago
          You are right: GraalPy (https://www.graalvm.org/python/ https://www.graalvm.org/python/) is where it's at these days.
    • animuchan 11mo ago
      JVM Python exists for the longest time now, where "exists" is purely technical. It's very cursed and bad, keeping in line with the rest of Java-adjacent stack.
      • homebrewer 11mo ago
        Yet this "Java-adjacent stack" wipes the floor with Python and its ilk w.r.t performance and is what's actually running the world outside of some silicon valley ephemeral unicorns.
    • t43562 11mo ago
      Try https://www.graalvm.org/python/ https://www.graalvm.org/python/
  • pansa2 11mo ago
    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.
    • y1n0 11mo ago
      Depends if they are the right resources.
      • fmbb 11mo ago
        Depends if it’s possible.
        • spooky_deep 11mo ago
          Python is slow due to design decisions in the language. For example operator dispatch is slow without some kind of static analysis. But this is hindered by how dynamic the language is.
          • ogogmad 11mo ago
            It's hard to make Python run fast when it pervasively uses duck typing. It makes types only resolvable at runtime. JIT is the only thing that can work here at the moment, but I think that needs to make very similar assumptions to a branch predictor, plus it needs to identify lexical regions (is that what they're called?). People here have criticised PyPy, but I've forgotten why.
    • danielscrubs 11mo ago
      Wow, know you make me curious about the business processes at Microsoft. Did they see that they would earn more money if the interpreter had a 5x speedup, that they wouldn’t see with 1.5x? Or was it trust broken?
      • eptcyka 11mo ago
  • heavyset_go 11mo ago
    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.
    • zahlman 11mo ago
      Obviously dumb microbenchmark, but here's ~17x on my machine: $ time python -c 'sum(range(1_000_000_000))' real 0m19.997s user 0m19.992s sys 0m0.005s $ time pypy -c 'sum(range(1_000_000_000))' real 0m1.146s user 0m1.126s sys 0m0.020s
      • heavyset_go 11mo ago
        I think some relatively simple math JITs and compiles nicely like that, but when you start using other parts of the language heavily like you would in a real project, it averages out to about ~4x due to the object, VM and locking model, I believe. It's been a while since I've looked into this.
  • rslashuser 11mo ago
    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!
  • ShroudedNight 11mo ago
    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
  • t43562 11mo ago
    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.
  • CamouflagedKiwi 11mo ago
    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.
• adastra22 11mo ago
  [flagged]
• ActorNightly 11mo ago
  > 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.
• rjzzleep 11mo ago
  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.
  • testdelacc1 11mo ago
    How do extra bells and whistles bother you? You had the option to not use them. Like you said yourself, they’re “extra”.
  • miki123211 11mo ago
    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?"
  • ErikBjare 11mo ago
    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)
  • pjc50 11mo ago
    What is the distinction between "package manager and install manager"?
    • x187463 11mo ago
      One installs Python packages into a Python installation and the other manages Python installations.
• miki123211 11mo ago
  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++.
  • thayne 11mo ago
    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.
    • throwup238 11mo ago
      Rust’s compile times are crippling and its type system is easily one of the most rigid of all type systems (lifetimes are part of the type!). The latter is one of Rust’s main selling points because it allows encoding business rules into affine types, but that’s very very far from flexible especially when compared to Typescript (or Python or Haskell and their many ways of polymorphism). Traits add an orthogonal axis of flexibility but they’re still limited by lifetimes (see async_trait and generic associated types and specialization). “Flexible” means the range from gradual typing (‘any’) to Turing complete conditional types that can do stuff like string parsing (for better or for worse). Structural typing vs instanceof and so on. There’s really no comparison between Typescript’s type system and Rust’s. It’s worth noting though that Typescript is a bolted on typesystem that has explicitly traded soundness for flexibility. That’s the real tradeoff between Rust and TS IMHO. Rust is sound and expressive but not flexible, while Typescript is expressive and flexible but not sound.
      • jmaker 11mo ago
        Also, some prominent projects migrated away from TypeScript to JSDoc type comments due to the transpile times in TypeScript. The type checking task takes the more time the more complex the type-level expressions are. Haskell can also take a long time to compile if you turn on a few extensions and move toward dependent types. Rust compiles fast if your translation units don’t need too much macro expansion. You add something like Diesel, and you can call for the lunch break. It’s also worth mentioning Scala with Scala Native and maybe Kotlin with Kotlin/Native. OpenJDK Project Panama FFM now gives a better FFI experiences than JNI.
• teiferer 11mo ago
  > 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 11mo ago
    There’s this thing where you work to requirements instead of picking things on vibes, it’s called engineering.
  • Epa095 11mo ago
    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'.
  • alex_duf 11mo ago
    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.
    • pansa2 11mo ago
      > 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.
      • airspresso 11mo ago
        Hard disagree. Python is so simple anyone can get up and running with coding in a few lines in the REPL.
• deleted 11mo ago
  [deleted]
• txdv 11mo ago
  Just profile the slow parts and rewrite them in rustm, easy.
• liampulles 11mo ago
  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.
  • cyberpunk 11mo ago
    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 {}
    • TheFlyingFish 11mo ago
      uv helps a lot with the first problem. Not so much with the second, though.
    • liampulles 11mo ago
      These issues are true of most legacy codebases I've worked on in other languages, but I think language design can be a factor here. Do you have any thoughts on if and how Python has led to this rot?
      • jiggawatts 11mo ago
        Another comment has explained this already, but the lack of dependency pinning and the general "it's just a script" attitude isn't conducive to long-term stability. During the early days of the llama local LLM runner, I was shocked to discover that releases weren't buildable mere days after being tagged in Git! Days! Other platforms like Java and .NET enjoy one to two decades of life for source before it becomes mildly challenging to build.
        • liampulles 11mo ago
          I think that is a totally fair criticism. There is something to be said about a language being too easy to hack something together with, it's something that makes backend JavaScript coding a long term pain as well I think.
• amelius 11mo ago
  My main question is: how good is it when it breaks? Because with most build/package tools that's when the misery starts.
• deleted 11mo ago
  [deleted]
• zahlman 11mo ago
  > 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).