NeutralForest

I can understand the sentiment somewhat. It's another layer of complexity and it makes working on projects more difficult. The fact pip or mypy code is all Python makes it much easier to interact with and patch if needed.

You can also write Cython for more perf oriented code but I can totally understand the value Rust brings to the table, it's just now another language you'll need to know or learn, more layers like maturin or pyO3, while cffi is just there.

All the tooling coming from astral is amazing and I use it everyday but I can see the increasing complexity of our toolchains, not in ergonomics (it's much better now) but the tools themselves.

I'm very glad to hear about your experience, it also touches on something deeply human when we can elevate ourselves and reach for the sky =)

Yes, you got it.

Hmm ok, let's see where this goes. I don't mind them experimenting with ARM or whatever.

I've been looking at Pine64 stuff to play around (the laptop mainly) but in Europe at least, it's constantly out of order.

indeed, thanks! it does so much for a tool that's like a year old, crazy stuff.

I'm not personally releasing a ton of internal packages where I work but I know of https://github.com/tox-dev/tox-uv. Haven't tried it yet though but it seems to do what you want. I also saw that nox (tox but in python instead of a tox.ini file https://nox.thea.codes/en/stable/config.html), is supporting uv from what I understand.

I don't think there's a definite answer yet.

- uv is aware of your dependencies, you can add/remove development dependencies, create group of development dependencies (test, lint, dev, etc) and add or remove those and only those at will. You can add dependencies and optional dependencies for a project as well, think my_app[cli,standard]. You don't need to have different requirements.txt for each case nor do you need to remove things by hand as you'd do in pip, since it doesn't remove deps when you remove a package for example. As a result, you can remove {conda,poetry,...} from your workflows.

- uv can install python and a virtualenv for you. Any command you run with `uv run` from the root of a repo will be aware of its environment, you don't even need to activate a virtualenv anymore. This replaces {pyenv, pyenv-virtualenv, virtualenvwrapper,...}.

- uv follows the PEPs for project config (dependencies, optional dependencies, tool configs) in the pyproject.toml so in case uv dies, it's possible to migrate away for the features are defined in the PEPs. Which is not the case for say, poetry.

- uv has a lock file and it's possible to make deps platform specific (Windows, Linux, MacOS, etc). This is in compliance with a PEP but not supported by all tools.

- uv supports custom indexes for packages so you can prefer a certain index, for example your company package index or pytorch's own index (for ML work).

- very fast, makes local dev very seamless and is really helpful in CI/CD where you might just setup and tear down python envs a lot.

Also, the team is responsive on Github so it's easy to get help.

Pretty much my take any time I see all the convoluted Bicep and YAML we have since there's a bunch of conditional logic and more in our pipelines.

100% agreed, it just takes a task that was a 10-15min setup depending on your environment and personal knowledge to a 2min thing. It just makes life easier and it puts the bar for starting lower, a win in my book =)

That's fair, it's also nice if you have a backend in Python and a frontend in JS since mise also handles node.

I used to install Python through mise but now I just use uv tbh.

There's also workspaces (https://docs.astral.sh/uv/concepts/projects/workspaces/) if you have common deps and it's possible to act on a specific member of the workspace as well.

Sure, I've basically replaced pyenv, pyenv-virtualenv, poetry; with uv. I can't think about cons personally, though you might need to dig into the docs at times.

Can someone ELI5 for a Muggle?

Agreed and they don't have good escape hatches. What was supposed to be declarative always ends up requiring some logic here and there and then you're stuck with a terrible language like YAML and you have to turn to templating, references to anchors and whatnot.

What I don't like is when you need to use a configuration language like Bicep or Terraform when the underlying architecture cannot be represented declaratively. You can create resources and provision them, that's fine. But any time you need forking paths, specific conditions, iterations over some resources, etc. You're done for, unless the configuration language has built a command or keyword for your specific use case. You can always tell me that I'm holding it wrong but when the platform requires me to use those config files or the SDKs for whatever languages are useless, it's infuriating.

Side note and not related to configuration languages but how they're used on $cloudProvider. But when you declare resources or operations that are legal in the language but invalid on the plateform, I die a little bit inside. The platform has all the knowledge about the existence of resources, policies, behavior; there's a whole class of problems that shouldn't exist before you're even trying to run a pipeline!

Thanks for the explanation! I was vaguely aware of those issues but not in depth. It all makes sense of course and now PDF is so deeply entrenched it's very difficult to push other formats. It's interesting that the contention between content and layout is still such an issue. I don't know what the fix is, maybe just the web?

I agree with this so much. I've tried to sometimes push friends and family to use text formats (at least I sent them something like Markdown), which is very easy to render in the browser anyways. But often you have to fall back to PDF, which I dislike very much. There's so much content like books and papers that are in PDF as well. Why did we pick a binary blob as shareable format again?

When I find a blog post/article I'm interested in, I save it to my laptop with the SingleFile extension and I take quick notes as well I write my thoughts about it in org-mode. It has a very low cognitive threshold and I can always read it back in the browser. I'm find if not all the outbound links are still working, I'd just like to read back sometimes.

Thanks, I haven't touched Typescript in a while so it might be the occasion for that. When do you feel like you have a handle on the behavior, do you have complex integration tests then?

That's an interesting approach, I'd like to see an implementation of what you're talking about. What language are you using that has such an expressive type system?

Oh, I agree that there usually isn't a scientific method to programming. I think there could be though. Not for everything of course, some things will always be up to personal taste and interpretation but the cursor could probably be moved with some effort in analyzing existing codebases at scale, doing surveys, internal testing of different approaches in large companies. Something more akin to what you see in social sciences, even if it might be a bad word in some circles!

We probably won't agree but I legitimately enjoy hearing about how people code.

I don't really agree, unit test should test behavior, having types or not should not be a defining factor in the coverage.

I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.

I don't really agree, unit test should test behavior, having types of not should not be a defining factor in the coverage.

I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.

But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software.

Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies.

If we don't do that then it's just vibes right? Where's the engineering part?

uv is so much better than everything else, I'm just can't afraid they can't keep the team going. Time will tell but I just use uv and ruff in every project now tbh.

It looks cool ngl and I might get around to try it out but I wouldn't bring it at work for example.

I just don't trust Google with a programming language. I feel like Golang has escaped the orbit of Google and could survive without it (I might be wrong). But for Dart I'm pretty sure it would die fast and I don't want to invest time into it as a result.

I was at his talk as well and I found it interesting. Maybe you could open an issue in the Whippet repo to point at possible improvements?

There are too many confounding factors still.

Even languages like Python and Javascript who are huge show a decline after 2022 which suggests ChatGPT is probably responsible. It would be better to have some other measure imo.