Comment by tcfhgj | Hacker News Reader

Comment by tcfhgj | Hacker News Reader

Parent Full thread

> Sure, it takes 30x longer to parse the data the author has with a Python script than in <insert-a-compiled-language>, but sharing your Python script is easy as... sharing the script. The other party does not need to install anything or learn anything new. It just works.

The only thing which will just work is viewing the script. For execution, you first need to install the correct python interpreter. Probably you need to activate a environment, because the global one is incompatible. Then you need to install the dependencies, which hopefully are 100% specified and restricted to pip, otherwise you might run into hours of SAT resolving.

For a compiled language, you need to install a Compiler instead of a interpreter or even nothing if you just get the executable.

With a modern language and required dependencies, running the script in a modern compiled language is probably simpler than doing it with Python (e.g. cargo run takes care of fetching deps which python doesn't)

Those issues are annoying but I'm not sure they're all that common. The default interpreter is perfectly fine for most cases as long as it's not years behind in versions, and I honestly have no idea where you'd get a Python dependency outside of pip, literally never seen one before. The company I worked for that did a lot of Python code had an internal Artifactory with a pip repo so even private packages went through it.

Cargo is great, I agree it's approaching the usability of running a Python script there. But now you're compiling Rust, which is going to take orders of magnitude longer than any time you'd save from the script itself running faster. Plus for most of the scripts Python is used for from what I can tell, more time is spent writing them than running them anyways. So as much as I do love Rust I'm not buying that it's the better choice here.

> dependency outside of pip, literally never seen one before.

You don't know Anaconda?

> Cargo is great, I agree it's approaching the usability of running a Python script there

I think it's clear that the usability of cargo run is much higher than "prepare everything yourself, then python script.py"

> which is going to take orders of magnitude longer than any time you'd save from the script itself running faster.

In this case: no, otherwise obv. depends on the code and dependencies

I thought of conda after I made the post, I've used it a handful of times. But still it's just another package manager, has a GUI installer and env setup usually takes max two commands that will be in the README. My point essentially is that the extra friction in running a script in Python vs Rust is minor relative to extra friction in learning and writing Rust vs Python, so the comparison in some ways misses the purpose of a scripting language. Personally I write a lot of Rust lately and very little Python, I'd absolutely choose it for a script but I understand why it doesn't always make sense.

I love python but I find the above issues to be very common. If I make a script for a non-computational colleague I often get asked, "nice, how can I run it?", and then it usually gets converted into a flask app because I can't be bothered to explain anaconda environments, or trying to install scipy and fortran compilers on their windows laptop. With nim I can just hand them a binary and tell them to double-click it.

It is easy to come up with strawmen, but that is not the reality. Again remember the context of the post. We are talking about parsing some data. At most you would use numpy and pandas which are standard for any scientific install anyway.

Reply on news.ycombinator.com