Hacker Newsnew | past | comments | ask | show | jobs | submit | micik's commentslogin

It’s not hard to master. It’s not a skill to be learned —- it’s a tool that comes with a manual. You read the manual and now you can use the tool. Most people never will read the manual which is what gives the false impression that there’s something “to master” here. It’s like saying vím is harder to use than notepad. Not if you read the entire manual first.

I'm not sure how you define skill acquisition, it's reading documentation and doing the skill, yes? The AI landscape shifts rather quickly still, and a new LLM + harness has a different set of functionality, but more importantly different fuzzy failure cases Things a model is particular good at, things that work better if you combine certain systems. All of it is documented, but also fast moving and new things are discovered frequently. In comparison, Vim has been around for decades.

And vum is absolutely harder to use than notepad. Otherwise it's like saying that rocket science isn't hard because you just have to read the documentation to know how to engineer a rocket.


i found uv frustrating. i dont know what problem is it trying to solve. it's not a tool for managing virtualenvs, but it does them as well. i guess it's a tool for dependency management. the "uv tool" stuff. kinda weird. i gave it an honest try but i was working around it with shell functions all the time.

in the end i went back to good old virtualenvwrapper.sh and setting PYTHONPATH. full control over what goes into the venv and how. i guess people like writing new tools. i can understand that.


Maybe I "entered" the Python ecosystem at a different time, but I never used virtualenvwrapper.sh nor sat PYTHONPATH manually ever. When I first came into contact with Python, I think doing `virtuelenv venv && source venv/bin/activate` was what was recommended to me at the time. Eventually I used `python -m venv` but always also with `pip` and a `requirements.txt`. I pretty much stuck with that until maybe 1 year ago I started playing around with `uv`, and for me, I just use `uv venv|pip|init|add` from uv, and nothing else from any other tools, and generally do pretty basic stuff.

Maybe for more complex projects and use cases it's harder, but it's a lot faster than just pip and pyproject.toml is a lot nicer to manage than `requirements.txt`, so that's two easy enough wins for me to move over.


uv solves many problems, but one textbook case is the problem of running some arbitrary Python-based command-line tool, where 1/you don’t have any Python interpreter installed, 2/your OS-provided Python interpreter isn’t compatible with the tool, or 3/you want to run single or multiple tools from any arbitrary folder where your data already is, as opposed to adapting your workflow to fit the virtualenv or running the risk that two tools have conflicting dependencies that would make the virtualenv not work well.

Isn't what you're describing solved by `uv tool install`?

I’m describing the use cases that uv addresses.

oh boy. you served GP a portion so generous they'll have plenty left over to take home and chew on for a while.

that last sentence rung like a bell & will reverberate until Larry Ellison's police drones follow you home because you blocked the drive-in of a Larry-owned fastfood franchise by way of a peaceful sit-in, protesting the mistreatment of human workers by robot overseers at Larry's Lasagna, nation-wide.

orwell it not come to that?


that's a long time between edits. as a single contributor to my own posts, i usually achieve a like iteration within minutes. did they have to have a board meeting in between the changes? lovely conservative process. "rookies", love it


anything. we're doing anything.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: