3 ms·

I'm not super-familiar with pip-tools however I'll try and explain what I like about Cargo. You're right on the dependencies, there's a lock file to make sure

I'm not super-familiar with pip-tools however I'll try and explain what I like about Cargo. You're right on the dependencies, there's a lock file to make sure you get the exact build environment. So from a dependency management perspective it sounds similar. What I like about Cargo is it's just slightly opinionated about how you want to build a Rust project. Creating a new project is as simple as "cargo new myproject" and boom, away you go. Same thing with unit testing, running all tests in a Rust project is as simple as "cargo test". If you've worked on a moderately large C/C++ codebase you'll know that those two things alone can be a huge source of annoyance. It also makes it really easy to install Rust-based tools like racer/rustfmt/etc with "cargo install <tool>" which pulls the source, builds and puts the executable on your path. In short, all the annoying stuff around project management that in C/C++ is neatly handled into a few short commands. In my mind it's a huge productivity win.

StavrosK 10y ago
Ah, I see. The main difference I can see is that it's opinionated, because everything else can be done by pip too (you can install utilities right in your path with it). I agree that being opinionated is a big help. Everyone in Python-land uses virtualenv and pip, but it would be great if (as is actually happening now), they were bundled with the language and were the One Blessed way of creating a new project: virtualenv myenv source env/bin/activate pip-compile requirements.in pip-sync requirements.txt Rust does get a few benefits from being statically linked, but yes, I see now that people compare cargo to mostly C/C++ tooling, and not to something like Python, thank you.
- dpc_pw 10y ago
  So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install? `pip` and Python are riddled with problems. Native modules fail to compile all the time and since Python is so slow, it requires a lot of native code. python2 vs python3 share `PYTHONPATH` and `virtualenv` is inheriting it: http://stackoverflow.com/questions/24583777/why-does-virtualenv-inherit-pythonpath-from-my-shell http://stackoverflow.com/questions/24583777/why-does-virtual... which leads to many weird problems. Not to mention some python stuff is not available on `pip` (like PyQt, last time I tried). Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D Python software really works only in it's developer sandbox, or when very carefully prepared by Linux-distribution maintainers. Otherwise it's a mess. Part of the reason why Docker got so popular was because it solved an impossible task of running several separate programs written in Python reliably side by side, on many boxes. Since it works reliably only in developer's sandbox, we now ship the whole sandbox and call it "application container". I've gave up on using any software written in Python on my boxes. I just avoid it. Not to mention that Python software rarely works reliably...
  - dom0 10y ago
    I won't bother replying to most of what you said (bit tired), just this one here: > Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D You don't need to activate a virtualenv to run an application from it. Eg. some_virtualenv/bin/some_binary just works, regardless of other active virtualenvs or what Python/Java/C program invokes that. And maybe this bit here: > So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install? The commands he mentioned would be used to create a new project, not to install anything.

StavrosK 10y ago

Ah, I see. The main difference I can see is that it's opinionated, because everything else can be done by pip too (you can install utilities right in your path with it). I agree that being opinionated is a big help. Everyone in Python-land uses virtualenv and pip, but it would be great if (as is actually happening now), they were bundled with the language and were the One Blessed way of creating a new project: virtualenv myenv source env/bin/activate pip-compile requirements.in pip-sync requirements.txt Rust does get a few benefits from being statically linked, but yes, I see now that people compare cargo to mostly C/C++ tooling, and not to something like Python, thank you.

dpc_pw 10y ago
So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install? `pip` and Python are riddled with problems. Native modules fail to compile all the time and since Python is so slow, it requires a lot of native code. python2 vs python3 share `PYTHONPATH` and `virtualenv` is inheriting it: http://stackoverflow.com/questions/24583777/why-does-virtualenv-inherit-pythonpath-from-my-shell http://stackoverflow.com/questions/24583777/why-does-virtual... which leads to many weird problems. Not to mention some python stuff is not available on `pip` (like PyQt, last time I tried). Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D Python software really works only in it's developer sandbox, or when very carefully prepared by Linux-distribution maintainers. Otherwise it's a mess. Part of the reason why Docker got so popular was because it solved an impossible task of running several separate programs written in Python reliably side by side, on many boxes. Since it works reliably only in developer's sandbox, we now ship the whole sandbox and call it "application container". I've gave up on using any software written in Python on my boxes. I just avoid it. Not to mention that Python software rarely works reliably...
- dom0 10y ago
  I won't bother replying to most of what you said (bit tired), just this one here: > Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D You don't need to activate a virtualenv to run an application from it. Eg. some_virtualenv/bin/some_binary just works, regardless of other active virtualenvs or what Python/Java/C program invokes that. And maybe this bit here: > So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install? The commands he mentioned would be used to create a new project, not to install anything.