I don't think that's an accurate metaphor. Seatbelts are expressly a runtime solution to car crashes, whereas Python's type checking is a) only done during development (not even during build), and b) completely reliant on third-party tools.
If you're looking for a car analogy, I would suggest comparing Python type checking to installing speed cameras on the factory floor.
Ever had customers deploy your project on 4 different debian versions without docker? Probably not, because there are problems lurking you didn't even know could exist. And 99% of them are gone with uv.
You don't have to believe the parts you made up. The comment you're replying to didn't actually state that a single customer was deploying to four different Debian versions. As written, the comment only requires you to believe that four Debian versions were in use collectively across the customer base.
Granted, but that is relevant to the point I made in which way?
In reality you will have people running different OS versions. Maybe not within one org, but across users? For sure. If you are not using containers for one reason or another uv has shown to be a very good, reliable and easy to use way of dealing with the issues like these.
Additionally it has some other benefits when it comes to dev dependecies etc. Not that you couldn't somehow manage without it, it just makes certain things so much less pain as they were.
Yeah, but it sold itself on its merrits. That is the point. Maybe venv and pip works fine for some toy projects that are deployed on the developer controlled OS without regular dependency updates, but let me assure you I had hours of fights with updating python services with complex needs on Debian boxes from various ages while ensuring whst I ran as a dev is the stuff that is guaranteed to run in production.
With uv it just works and that in a fraction of the time. Where before updates would mean to mentally prepare that a thing that should take 5 seconds in the best and 15 minutes in the worst case could occupy my whole day, it has now become very predictable.
I don't care what it is written in. It works. If you think people love it because it was written in some language it just means you never had a job where what uv brings was really needed and thus you can't really judge its usefulness.
Also one has to chuckle at the notion that re-writing package management in Rust is some kind of fanbois with hammers looking for nails activism. Rust is almost certainly the best option for this in the 2020s, especially for a package ecosystem as deranged as Python's.
By this point I feel reminded of a former collegue I ate lunch with, who would repeatedly make jokes about how "vegans constantly need to talk about their veganism". During our shared time he brought that topic up probably a hundred times, while the single time veganism was brought up by anybody was by a female intern after she was asked by him why she doesn't like to try the meat.
This is what reflexive criticism of Rust starts to feel like. I get that this somehow grinds some peoples gears, but come on. Who cares what it is written in if it is good software. And as someone who tried all major ways of dependency management in Python I have to say it is the best. Don't like that it is written in Rust for ideological reasons? Go ahead and write it better in C¹ or whatever.
¹: Nothing against C, I regularily use it for embedded programming, but it appears many of the loudest Rust allergics come from there
1. Write code that crosses a certain complexity treshold. Let's say tou also need compiled wheels for a performance critical section of a library that was written in Rust, have some non-public dependencies on a company-internal got server
2. Try deploying said code on a fleet of servers whose version and exact operating system versions (and python versions!) are totally out of your control. Bonus points for when
your users need to install it themselves
3. Wait for the people to contact you
4. Now do monthly updates on their servers while updating dependencies for your python program
If that was never your situation, congrats on your luck, but that just means you really weren't in a situation where the strengths of uv had played out. I had to wrestle with this for years.
This is where uv shines. Install uv, run with uv. Everything else just works, including getting the correct python binary, downloading the correct wheel, downloading dependencies from the non-public git repo (provided the access has been given), ensuring the updates go fine, etc.
This explains a lot for me. On the server side, all my for-pay stuff is deployed using Docker. We have a single Python environment and complete control over it. We do multistage for compilation.
Client side, we don't get the privilege of deploying code: we need to build installers, which means again we have complete control over the environment because we package Python and all associated dependencies.
I'm sure there are marginal benefits to uv even with the above scenarios (better dependency management for example), but it seems that there's a middle ground here which I have largely avoided which is where uv really shines.
Yeah makes sense, with docker in the mix the things uv brings are less interesting, although using uv for small one-off scripts is also an interesting application (there is a way of making uv your shebang, declaring sependencies within the python file and essentially getting a uv-ran python script that will auto-download the needed dependencies).
Over the years I encountered many situations where other solutions (pip+pyenv, poetry, easy_install) lead to hour long stops in dependency hell. Meanwhile uv just works. Even the most complicated projects I transfered over since I decided to make the switch worked first try.
I am not the person who has to go for the newest shiniest thing just because, but if that new shiny thing does the job instead of wasting my time sign me up.
To be frank, the clear problem with configuration format is that people have configurations so complex they probably should use something else.
Example: We are programming a backend for a blog. If we were to not use templates, but instead try to get that functionality via the webservice configuration we would have to "invent" some format that gives us the flexibility of templates within let's say a YAML file.
Needless to say that would be a horrible idea. Maybe I am being naive here, but I have yet to be convinced of the fact that it is really configuration formats that are the problem and not what people try to abuse them for. I have yet to work on a project where TOML wasn't enough for actual configuration.
Usually when I need something more complex than what can be done with TOML it is a sign that this needs to be handled differently. Via templates or with a database or making a special DSL-like script file. E.g. if you're using python nothing (except security considerations) stops you from allowing users to use a python file for configuration. If your configuration needs are really that complex, why not use a real programming language for it?
Two examples of complex user facing configurations I can think of are pretty trivial to implement:
- Decision tree, where you only need comparison operators. The leaves are a specified list of actions.
- actions list with macros (variables). You can be fancy and add some conventions for arrays.
Anything more that that should just be a programming language. And if the relationship is adversarial (saas), you should really think hard about needing something that complex.
Started converting every repo over to uv. I had some weird and hard to deal with dependencies before. Every single one was easier to solve than before. It just works and is blazingly fast.
Arguments only matter if we assume totally rational actors. There is ample evidence that this could potentially be a faulty assumption.
A questiom: What do you think, do people first have an emotion and then try to rationalize it? Or do they first have a the rational judgment and only after that start to become emotional?
If you watch right wing media it is pretty clear that emotions play a huge role for them. And because nobody particularly likes having emotions they can't explain, the rationalizations come after: "Windmills are destroy the landscape" (unlike let's say an oilfield which is somehow totally fine), things about the infrasound (which if a concern you can get rid off by the same way it is done with nuclear waste in the US, just use that massive land mass to your advantage).
If we had rational, emotionally distanced actors they would change their mind once all doubts are addressed and the facts are on the table. But that is not the case here in my own experience. Once the last rationalization breaks they go back to the feeling of: "I just don't like it".
That means the much more fruitful question to investigate is that particular dislike and where it might come from, emotionally.
Surely this isn't just one root. For some it may be the "safe" opinion of their herd/tribe. Others say it, their entertainment (that under traditional media law wouldn't deserve the title "News") says it and so on.
For yet others this may be a question of their insecure masculinity. They feel insecure, but men have to be strong! So they try their best to appear strong, by buying manly products, driving manly trucks and spouting manly opinions. You know what isn't manly in their mind? Being sensible. Sensible with other people, the environment, wensible with thought. And then a sensible energy option come around. Guess what, that feels like an attack to them. Suddenly society wants to erect huge pillars thst remind them that being sensible is now required. That really touches their core fear of not being manly enough. Being sensible could be misread as being gay after all.
There are probably more reasons.
P.S.: I am not saying there are no rational critics of wind energy. Whwt I am saying is the bulk of categorical dislike comes from an entirely uninformed, purely emotional direction
My guess would be that most people just copy (mimic) what is already there. I sometimes work as a freelance web administrator and I can assure you 95% of people who create websites for a living have never read through a list of HTML tags, have only a slight idea of the semantic web and in the end they are more like people who cobble existing things together and are out of their depth pretty quickly.
Not that this is problematic per se, everybodies milage may vary and we're all out there to learn. But if I told one of them about the output tag thry probably wouldn't even understand why that would be important.
May the struggle for real democratic representation in countries like Venezuela act as a much needed reminder how fragile political systems can be and how hard it is to re-establish them once they are gone.
Is democracy sometimes slow or exhausting? Sure. But without it your country could be locked in decades of destructive power struggles where nearly everybody loses.
reply