alternatively, uv lets you do this:

  #!/usr/bin/env -S uv run --script
  #
  # /// script
  # requires-python = ">=3.12"
  # dependencies = ["foo"]
  # ///

Yeah, but you need `uv`. If we are reaching out for tools that might not be around, then you can also depend on nix-shell,

    #! /usr/bin/env nix-shell
    #! nix-shell -i python3 --packages python3

That shebang will work on GNU link based systems, but might not work elsewhere. I know that’s the most popular target, but not working on macOS, BSDs, or even busybox.

And with some small shebang trick, you don't even need to have uv installed [1], just curl and a posix shell

[1] https://paulw.tokyo/standalone-python-script-with-uv/

> Then you don't even need python installed. uv will install the version of python you specified and run the command

What you meant was, "you don't need python pre-installed". This does not solve the problem of not wanting to have (or limited from having) python installed.

That's my experience. I'm not a Python developer, and installing Python programs has been a mess for decades, so I'd rather stay away from the language than try another new tool.

Over the years, I've used setup.py, pip, pipenv (which kept crashing though it was an official recommendation), manual venv+pip (or virtualenv? I vaguely remember there were 2 similar tools and none was part of a minimal Python install). Does uv work in all of these cases? The uv doc pointed out by the GP is vague about legacy projects, though I've just skimmed through the long page.

IIRC, Python tools didn't share their data across projects, so they could build the same heavy dependencies multiple times. I've also seen projects with incomplete dependencies (installed through Conda, IIRC) which were a major pain to get working. For many years, the only simple and sane way to run some Python code was in a Docker image, which has its own drawbacks.

There's definitely a philosophical shift that you can observe happening over the last 12-15 years or so, where at the start you have the interpreter as the centre of the world and at the end there's an ecosystem management tool that you use to give yourself an interpreter (and virtual environments, and so on) per project.

I think this properly kicked off with RVM, which needed to come into existence because you had this situation where the Ruby interpreter was going through incompatible changes, the versions on popular distributions were lagging, and Rails, the main reason people were turning to Ruby, was relatively militant about which interpreter versions it would support. Also, building the interpreter such that it would successfully run Rails wasn't trivial. Not that hard, but enough that a convenience wrapper mattered. So you had a whole generation of web devs coming up in an environment where the core language wasn't the first touchpoint, and there wasn't an assumption that you could (or should) rely on what you could apt-get install on the base OS.

This is broadly an extremely good thing.

But the critical thing that RVM did was that it broke the circular dependency at the core of the problem: it didn't itself depend on having a working ruby interpreter. Prior to that you could observe a sort of sniffiness about tools for a language which weren't implemented in that language, but RVM solved enough of the pain that it barged straight past that.

Then you had similar tools popping up in other languages - nvm and leiningen are the first that spring to mind, but I'd also throw (for instance) asdf into the mix here - where the executable that you call to set up your environment has a '#!/bin/bash' shebang line.

Go has sidestepped most of this because of three things: 1) rigorous backwards compatibility; 2) the simplest possible installation onramp; 3) being timed with the above timeline so that having a pre-existing `go` binary provided by your OS is unlikely unless you install it yourself. And none of those are true of Python. The backwards compatibility breaks in this period are legendary, you almost always do have a pre-existing Python to confuse things, and installing a new python without breaking that pre-existing Python, which your OS itself depends on, is a risk. Add to that the sniffiness I mentioned (which you can still see today on `uv` threads) and you've got a situation where Python is catching up to what other languages managed a decade ago.

Again.

Do you think a non-python user would piece it together if the shebang line reveals what tool to use?

> If you've never used Clojure and start a Clojure project, you will almost definitely find advice telling you to use Leiningen.

I thought the current best practice for Clojure was to use the shiny new built-in tooling? deps.edn or something like that?

> you might find someone saying to use uv, but also potentially venv, poetry or hatch.

This is sort of like saying "You might find someone saying to drive a Ford, but also potentially internal combustion engine, Nissan or Hyundai".

uv has been around for less than two years. It’s on track to become the default choice, it’s just a matter of time.

sounds awesome. Just out of interest, why do you think pyflow didn't catch on, but UV did?

Ive been away from python for awhile now, I was under the impression uv was somehow solving this dependency hell. Whats the benefit of using uv/pip together? Speed?

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.

> Third, virtual environments are literally just a place on disk for those dependencies

I had a recent conversation with a colleague. I said how nice it is using uv now. They said they were glad because they hated messing with virtualenvs so much that preferred TypeScript now. I asked them what node_modules is, they paused for a moment, and replied “point taken”.

Uv still uses venvs because it’s the official way Python stores all the project packages in one place. Node/npm, Go/go, and Rust/cargo all do similar things, but I only really here people grousing about Python’s version, which as you say, you can totally ignore and never ever look at.

uv uses a global cache but hardlinks the dependencies for your script into a temp venv that is only for your script, so its still pretty fast.

Nope! uv takes care of that. uv is a work of art.

> All I had to do was embed a primitive AI generated TOML parser in it.

The standard recommendation for this is `tomli`, which became the basis of the standard library `tomllib` in 3.11.

Also, for Go oneliners: https://github.com/dolmen-go/goeval

(Disclaimer: author here)

Gtk makes that simple python program way more complex since it'll need more than pure-python dependencies.

It's really a huge pain point in python. Pure python dependencies are amazingly easy to use, but there's a lot of packages that depend on either c extensions that need to be built or have OS dependencies. It's gotten better with wheels and manylinux builds, but you can still shoot your foot off pretty easily.

Python is near the top in languages that have given me trouble in other peoples' production software. Everything can be working fine and then one day the planets fall out of alignment or something and the Python portion of the software breaks and the fix is as clear as mud.

I'm pretty sure the gtk dependencies weren't built by Astral, which, yes, unfortunately means that it won't always just work, as they streamline their Python builds in... unusual ways. A few months ago I had a similar issue running a Tkinter project with uv, then all was well when I used conda instead.

How were the dependencies specified? What kind of files were provided for you to instantiate the venv?

I haven't had the same issue with anaconda. Give it a try.

I think there is still space for an alternate Go syntax for scripting with the following constraints:

* a single file exposing a "main" package and its "func main()"

* import syntax that merges requires from go.mod (import both packages and modules)

* simplified error handling (just ignore returned errors in code, and they are caught by the transpiler to be handled as fatal)

Those are my ideas to go beyond my own goeval that already allows to run Go oneliners. https://github.com/dolmen-go/goeval

Have to disagree, "technically" yes, both are interpreted languages, but the ergonomics and mental overhead of doing certain things are wildly different:

In python, doing math or complex string or collection operations is usually a simple oneliner, but calling shell commands or other OS processes requires fiddling with the subprocess module, writing ad-hoc streaming loops, etc - don't even start with piping several commands together.

Bash is the opposite: As long as your task can be structured as a series of shell commands, it absolutely shines - but as soon as you require custom data manipulation in any form, you'll run into awkward edge cases and arbitrary restrictions - even for things that are absolutely basic in other languages.

I love Python and dislike Bash, but just look at the difference between listing a folder in Bash vs Python, for example.

Well said. I’m in the same boat of being on the fence about python. I’ve been burned too many times in the past.

And even if uv was perfectly solves all of our woes, it still seems worse than languages that solve packaging and deployment with a first-party built tools.

There’s only so much lipstick and makeup you can put on a pig…

Yeah, the difference between static and dynamically typed languages are massive with LLM coding, and the difference seems to me exponentially larger with larger codebases.

Libraries, yes. Tooling around packages/building/managing runtimes? I'm not convinced. Perl has been using CPAN like two decades now, and I wouldn't consider that ecosystem to exactly be an example of "there's only one way to do it". I feel like you're extrapolating in the wrong direction; older languages are less likely to have first party tooling for this, so they're more likely to have multiple ways of doing it, but I don't think there's much evidence that a language that started out with first party tooling will always follow that same trend. I don't think the issue with Python is it's age as much as the tooling it has was just really not good for a long time. People will probably want to replace subpar tooling regardless of the official status if there's a better alternative, but I'd expect that I'm the presence of good enough first-party tooling, people will eventually stop bothering.

I do actually think Go is a bit of an illustrative example here because it started out with just `go get` and liberal use of vendoring, then accumulated a variety of attempted replacements (e.g. godep and dep, which confusingly were not the same thing), but eventually the first party tooling around modules became a thing and after some time it seems like pretty much everyone dropped those interim tools and standardized on the official tooling. I feel like this actually shows that the proliferation of tooling can actually be stopped even if it didn't exist early on, provided that there's a process for making it official.

I don't see your point. The kind of user who will struggle to type out `uv run` will find it even more difficult to type out `//usr/local/go/bin/go run "$0" "$@"; exit`. Neither approaches are the "default, officially recommended ways to run" scripts.

I strongly encourage you to read the article to acquire the context for the conversation before commenting, which is what I assume is happening here.

> Is uv the default, officially recommended way to run Python?

Yes, seems like it is de facto default, officially recommended way.

> Is uv the default, officially recommended way to run Python? No? Remember to wave goodbye to all the users passing the language by.

uv was invented basically yesterday. But it is becoming the default faster than any tool I've ever seen.

So I'd say: Yes - it is, effectively, the default now.

> The user just wants to run the damn program.

I don't agree, the user wants to run the program in a way the user wants to, but is frustrated when it doesn't.

If all dependencies were installed on the machine the script would run no problem. I have some scripts with dependencies that are installed on the system.

The author writes:

> The built in tooling within the go ecosystem is another large selling point. We don't need a .pyproject or package.json to configure ad-hoc formatting and linters, backed by pipelines to ensure consistency.

Maybe shebangs is not the solution to that problem? It's a convenience to run scripts as executable, but the user is supposed to setup the environment. Then he continues to explain that go has a great stdlib which makes it perfect for scripting. This is the reason I usually reach for python for complex scripts, the stdlib is big enough to solve most my problems.

Now that node includes sqlite the choice isn't as easy, but I wouldn't be pissed at node and javascript if I have to setup the environment to make sure the script runs. I understand how it runs, where it gets the dependencies. If I forget to run `npm i` before running the scripts that's my error, I prefer errors that remind me of my stupidity over magic.

> hate trying to install other people’s scripts.

This phrasing sounds contradictory to me. The whole idea of scripts is that there's nothing to install (besides one standard interpreter). You just run them.

> I just hate trying to install other people’s scripts.

This notion is still strange to me. Just... incompatible with how I understand the term "script", I guess.

If they use https://packaging.python.org/en/latest/specifications/inline... then it becomes a breeze to run with uv. Not even a thing.

It’s not worse, but Python has better batteries out of the box. Toml, csv, real multi-threading (since 3.13), rudimentary gui, much better repl (out of the box and excellent, installable ipython), argparse and a lot more.

This is more than just trivially true for Python in a scripting context, too, because it doesn’t do things like type coercion that some other scripting languages do. If you want to concat an int with a string you’ll need to cast the int first, for example. It also has a bunch of list-ish and dict-ish built in types that aren’t interchangeable. You have to “worry about types” more in Python than in some of its competitors in the scripting-language space.

Nonsense.

> How does uv solve the “write once, run anywhere” problem like go?

Here's an examply Python script from the uv website[0]:

  #!/usr/bin/env -S uv run --script
  #
  # /// script
  # requires-python = ">=3.12"
  # dependencies = ["httpx"]
  # ///

  import httpx

  print(httpx.get("https://example.com"))

[0] https://docs.astral.sh/uv/guides/scripts/#using-a-shebang-to...

UV is a drop-in for pip, rather than a replacement. It functions differently than pip behind the scenes, which is why it's faster, but when you use it, it's basically still pip. Except it makes everything easy. You create your venv with uv venv, you update packages with uv sync, you run things without activating your venv with uv run... It uses the pyproject.toml, so it's very easy to share things like linters and build tools. Then when it's time to deploy, you can compile your pyproject.toml to a requirements.txt file and use it in any Python container image. Which is very handy when you work with something like Azure Container Functions which don't come with UV (and you probably don't want to use an UV image or install UV in your build process).

I've been using it for so long now that I recently couldn't remember how to use Python without it, when one of our BI guys needed some help. Which was ridiculously embarrassing.

I don't think it really compares to Go though. It's not as straight forward if you work on different python distributions. It's also not as easy to work with something like micro Python compared to targeting a specific embedded platform with Go.

What about Elixir?

https://pragprog.com/titles/smelixir/machine-learning-in-eli...

A Practical Guide to Machine Learning in Elixir - Chris Grainger

https://www.youtube.com/watch?v=Es08MRtSkoE

> The world deserves a Python-like language with a better type system, a better distribution system, and not nearly as much dynamism footguns / rope for people to hang themselves with.

Nim. The tooling is still immature though.

C#/.Net? (Their too strong focus on worthless backwards compatibility and slow (very slow) development speed on basic language features not withstanding.)

It’s called Java.

> NodeJS does not have a good FFI story, and neither does Rust or Go. Yes, there's support, but Python's FFI support is actually better here.

Huh. I've found Rust's FFI very pleasant to work with. I understand that Zig's is second to none, but what does Python offer in this domain that Rust (or Go) doesn't?

Its type system is miles better than Python and it has some basic stuff Python doesn't have like block scope. Functional programming is also intentionally kind of a pain in Python with the limited lambdas.

If TypeScript had the awesome python stdlib and the Numpy/ML ecosystem I would use it over Python in a heartbeat.

Typescript is a really nice language even though it sits on a janky runtime. I’d love a subset of typescript that compiles to Go or something like that.

Typescript is ubiquitous in web, and there are some amazing new frameworks that reuse typescript types on the server and client (trpc, tanstack). It's faster (than python), has ergonomic types, and a massive community + npm ecosystem. Bun advances the state of the art for runtime performance (which anthropic just bought and use for Claude code).

TypeScript is great!

Has shortcomings like all languages but it brought a lot of advanced programming language concepts to the masses!

Typescript is a lot nicer than Python in many ways. Especially via Deno, and especially for scripting (imports work like people want!).

There are some things that aren't as good, e.g. Python's arbitrary precision integers are definitely nicer for scripting. And I'd say Python's list comprehension syntax is often quite nice even if it is weirdly irregular.

But overall Deno is a much better choice for ad-hoc scripting than Python.

Have you tried Nim? Strong and static typed, versatile, compiles down to native code vía C, interops with C trivially, has macros and stuff to twist your brain if you're into that, and is trivially easy to get into.

https://nim-lang.org

Yes, Go can hardly be called statically typed, when they use the empty interface everywhere.

Yes, OCaml would be a decent language to look into. Or perhaps even OxCaml. The folks over at Jane Street have put a lot of effort into tooling recently.

You can replace Python with Nim. It checks literally all your marks (expressive, fast, compiled, strong-typing). It's as concise as Python, and IMO, Nim syntax is even more flexible.

https://nim-lang.org

I bounced off OCaml a few years ago because of the state of the tooling, despite it being almost exactly the language I was looking for. I'm really happy with Gleam now, and recommended it over OCaml for most use cases.

Rust might be worth a look. It gets much closer to the line count and convenience of the dynamic languages like Python than Go, plus a somewhat better type system. Also gets a fully modern tooling and dependency management system. And native code of course.

I suppose you could try typescript which can compile to a single binary using node or bun. Both bun and node do type stripping of ts types, and can compile a cli to a single file executable. This is what anthropic does for Claude code.

https://dev.to/yawaramin/practical-ocaml-314j

You might want to try Dart. It is simple, has great tooling, and compiles to native code.

Disclaimer: I work on Flutter at Google.

Modern Java with Graalvm.

Gee, I wonder why the tooling for ML in Lisp is missing even though the early ML frameworks were in Lisp. Perhaps there is something about the language that stifles truly wide collaboration?

What sort of tooling is missing in Lisp? I'd love to check out your framework if you've shared it somewhere

Perhaps some people that cared moved to other languages.

And part of those who still complain are momentarily stuck with it.

Just like survivorship bias. It's productive to ponder on the issues experienced by those who never returned.

The people we happen to work with is an incredibly biased sample set of all software engineers.

As an example, almost everyone I’ve worked with in my career likes using macOS and Linux. But there are entire software engineering sub communities who stick to windows. For them, macOS is a quaint toy.

If you’ve never met or worked with people who care about typing, I think that says more about your workplace and coworkers than anything. I’ve worked with plenty of engineers who consider dynamic typing to be abhorrent. Especially at places like FAANG.

Long before typescript, before nodejs, before even “JavaScript the good parts”, Google wrote their own JavaScript compiler called Closure. The compiler is written in Java. It could do many things - but as far as I can tell, the main purpose of the compiler was to add types to JavaScript. Why? Because googlers would rather write a compiler from scratch than use a dynamically typed language. I know it was used to make the the early versions of Gmail. It may still be in use to this day.

You're thinking only about the final step where we're just doing a bunch of matrix computation. The real work Python does in the ML world is automatic differentiation.

Python has multiple excellent options for this: JAX, Pytorch, Tensorflow, autograd, etc. Each of these libraries excels for different use cases.

I also believe these are cases where Python the language is part of the reason these libraries exist (whereas, to your point, for the matrix operations pretty much any language could implement these C wrappers). Python does make it easy to perform meta-programming and is very flexible when you need to manipulate the language itself.

Not really applicable to ML. The massive amount of compute running on the GPU is not executing in Python, and is basically the same regardless of host language.

You say he's narrow-minded, but you focus on the least relevant thing of everything he said, speed, and suggest that, somehow, something with "fast" in its name will fix it?

Speed is the least concern because things like numpy are written in C and the overhead you pay for is in the glue code and ffi. The lack of a standard distribution system is a big one. Dynamic typing works well for small programs and teams but does not scale when either dimension is increased.

But pure Python is inherently slow because of language design. It also cannot be compiled efficiently unless you introduce constraints into the language, at which point you're tackling a subset thereof. No library can fix this.

Yes. Have you ever tried trpc?

dwight shrute detected

Yes. Yes, I'm doing all of that with Javascript :P

Don't be that guy.

True, so less fun, but more practical in that it's supported.

This was a relatively old project that used a C program as build system / meta generator. All you needed was a working C compiler (and your shell to execute the first line). From there, it built and ran a program that generated various tables and some source code, followed by compiling the actual program. The final program used a runtime reflection system, which was set up by the generated tables and code from the first stage.

The main reason was to do all this without any dependencies beyond a C compiler and some POSIX standard library.

Unfortunate! Yet another little bit of Go design decision that makes things worse for, in my opinion, no reason.

Any time you have to resort to the no true scotsman fallacy you are telling me everything I need to know to run in the other direction.

No, I'm being cheeky. It's not fun. It's a "15 standards" situation https://xkcd.com/927/

No, it just felt a tad cleaner to have the comment slashes separate from the path leading slash.

The blog says that in regard to finding bash with env. My reading is that it does not make the same claim regarding finding go with env. bash is commonly found at /bin/bash (or a symlink there exists) as it is widely used in scripts and being available at that path is a well known requirement for compatibility. Go does not so much have a conical path and I have personally installed it at a variety of paths over the years (with the majority working with env). While I agree with the author of the blog that using env to find bash may or may not improve compatibility, I also agree with the parent comment that using env to find go probably does improve compatibility.

I wish this was faster, in my tests it’s about 200ms startup consistently on my M4 MacBook. Otherwise very cool

Cool!

Good thing you asked before I destroyed this ubuntu instance I was messing with:

    root@t:~# cat $(which scapy)
    ++ which scapy
    + cat /usr/bin/scapy
    #!/usr/bin/python3
    # EASY-INSTALL-ENTRY-SCRIPT: 'scapy==2.5.0','console_scripts','scapy'
    import re
    import sys
    
    # for compatibility with easy_install; see #2198
    __requires__ = 'scapy==2.5.0'
    
    try:
        from importlib.metadata import distribution
    except ImportError:
        try:
            from importlib_metadata import distribution
        except ImportError:
            from pkg_resources import load_entry_point
    
    
    def importlib_load_entry_point(spec, group, name):
        dist_name, _, _ = spec.partition('==')
        matches = (
            entry_point
            for entry_point in distribution(dist_name).entry_points
            if entry_point.group == group and entry_point.name == name
        )
        return next(matches).load()
    
    
    globals().setdefault('load_entry_point', importlib_load_entry_point)
    
    
    if __name__ == '__main__':
        sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
        sys.exit(load_entry_point('scapy==2.5.0', 'console_scripts', 'scapy')())

I feel like this principle could be codified as "the system is not a workspace."

The use of the system as a workspace goes back to when computers were either very small and always personal only to one user, or when they were very big and administrated by dedicated system administrators who were the only ones with permission to install things. Both these conditions are obsolete.

Yep, this is a common misunderstanding, and the blog post itself repeats it.

The only way to "pass the file contents" would be through the standard input stream, but the script might want to use stdin like normal, so this isn't an option.