Hacker News new | ask | show | jobs
by ComputerGuru 514 days ago
My problem with python is startup time, packaging complexity (either dependency hell or full blown venv with pipx/uv). I’ve been rewriting shell scripts to either Makefiles (crazy but it works and is rigorous and you get free parallelism) or rust “scripts” [0] depending on their nature (number of outputs, number of command executions, etc)

Also, using a better shell language can be a huge productivity (and maintenance and sanity) boon, making it much less “write once, read never”. Here’s a repo where I have a mix of fish-shell scripts with some converted to rust scripts [1].

[0]: https://neosmart.net/blog/self-compiling-rust-code/

[1]: https://github.com/mqudsi/ffutils

2 comments

I've often read that people have a problem with Python's startup time, but that's not at all my experience.

Yes, if you're going to import numpy or pandas or other heavy packages, that can be annoyingly slow.

But we're talking using Python as a bash script alternative here. That means (at least to me) importing things like subprocess, pathlib. In my experience, that doesn't take long to start.

$ cat helloworld.py #!/usr/bin/env python3 import subprocess from pathlib import Path print("Hello, world!\n")

$ time ./helloworld.py Hello, world!

real 0m0.034s user 0m0.016s sys 0m0.016s

34 milliseconds doesn't seem a lot of time to me. If you're going to run it in a tight loop than yes, that's going to be annoying, but in interactive use I don't even notice delays as small as that.

As for packaging complexity: when using Python as a bash script alternative, I mostly can easily get by with using only stuff from the standard library. In that case, packaging is trivial. If I do need other packages then yes, that can be major nuisance.

Python startup time gets much worse on low powered ARM systems executing from an sdcard — before the first import even occurs!

It certainly takes more effort for this to be a problem on modern x86 systems.

once you start importing more packages, you easily end up with 100+ ms startup time
At that point you're far beyond a bash script alternative though, aren't you?
Not necessarily. Shell scripts often embody the unix “do one thing and do it right” principle. To download a file in a bash script you wouldn’t (sanely) source a bash script that implements an http client;, you would just shell out to curl or wget. Same for parsing a json file/response: you would just depend on and defer to jq. Whereas in python you could do the same but most likely/idiomatically would pull in the imports to do that in python.

It’s what makes shell scripts so fast and easy for a lot of tasks.

Fair enough, although in your examples Python comes with JSON support, but not a (very usable) HTTP client, and Bash has the reverse problem.

I would like it if Python just had a sane nice HTTP client built in, but it can also just shell out to curl.

Take a look at Nim, it solves those problems and integrates well with existing Python code.