Comment by vvanders | Hacker News Reader

Comment by vvanders | Hacker News Reader

Parent Full thread

Long time C++ dev here(~15 years) currently loving Rust. Someone can probably put together a more eloquent comment however here's my top marks.

1. No memory corruptions/null pointers. Legit holds up to the promises here.

2. The path of least resistance is single-ownership which is far and away the best way I've seen to structure C/C++ applications.

3. Cargo: Pure awesome. Simply one of the best dependency management/build tools I've used.

4. Dead simple x-platform support. Windows, Linux, all just works. Heck I just built an android arm-eabi target yesterday on windows with no NDK/etc.

5. Tagged unions, pattern matching. The best effing iterator class I've seen bar none. Once you've used these you don't want to go back.

6. Great built-in unit testing support(combines with Cargo above).

7. Amazing community, no ego and tons of people happy to help.

I still work regularly on C++0x11 codebases but any greenfield stuff I've moved over to Rust fulltime.

I still like C++ but it's so much more painful to use. Heck just earlier today I got bit by <locale> not compiling on OSX due to some obscure compiler differences that worked on MSVC and GCC. There's certainly good improvements coming to C++ but they have to support so much legacy code that I don't think they could ever make the large breaking changes that Rust has to produce a better experience.

>I still work regularly on C++0x11

... but that's not due for another year!

The C++ compiler teams have done heroic work to get their implementations on-track and have been ahead of the spec for several years now.

Many compilers are already supporting a number of C++17 features, and by the time the spec is out it might be almost complete for most major vendors.

http://en.cppreference.com/w/cpp/compiler_support

0x11 == 17

That's not a code name I've ever heard of: https://en.wikipedia.org/wiki/C%2B%2B17

C+0x was what turned into C++11. The 0x part was just a placeholder for 08 or 09, but it actually ended up taking a few years longer to ratify.

Maybe people confuse C++11 with C++0x to get C++0x11.

Yes, the OP used C++0x11 when he probably meant either C++11 or C++0x. By chance, C++0x11 happens to be the hex encoding of the next expected C++ revision. My admittedly content free joke was an attempt at pointing out the error.

Yeah, never can tell how literal people are being around here.

I've only used Rust lightly, but can someone explain what Cargo does differently from pip-tools?

As far as I can tell, you have two files in both systems: One with the dependencies you'd ideally like to use, and one with the ones you actually used (and tested with). That way, you can update when convenient, but people who get your software have an exact known good environment.

What makes Cargo that much better than pip-tools?

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.

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.

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-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...

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.

When people talk about `cargo` being awesome, they're comparing it to the similar tools for, say C++ or C or other systems programming languages. No one is comparing `cargo` to `pip-tools`.

First of all, I agree that cargo blows the C/C++ tools out of the water in terms of ease of use. But I think it's even easier than newer stuff too. It's by far the best dependency manager I've used.

I haven't used pip-tools, but I have used pip, npm, bower, and other more modern dependency mangers that work for non-systems programming languages. Cargo has never given me any trouble. Pip has occasionally given me weird issues about things not being installed in the right places or on my path. NPM regularly required `rm -r node_modules` and starting from scratch. Bower has had the same trouble as npm. It's not that these tools don't work for me, I've always been able to google the error message and find someone with the same problem. It's that Cargo has never given me an error message that wasn't my fault like "This package doesn't exist" when it's a typo. It just works.

Hmm, I've had problems with npm too, but none with pip. The trick there is to make sure you're working in the virtualenv of your project, by activating it or using something like virtualfish or the bash equivalent (virtualenv-wrapper, I think).

One problem with pip is that it requires tricks. But seriously, I avoid using python mostly due the headache when trying to use pip. But I'm sure without pip python would be a real hell.

One thing that's nicer is that because Rust is a compiled language, Cargo produces a (statically-linked) binary. Python and your Python environment always needs to be set up on the machine that you're going to run it on.

statically-linked by default except for on Linux where it links to glibc dynamically by default IIRC, but going fully static there is easy, and going fully dynamic is easy too.

fully static (including libc) can cause a lot of trouble on Linux.

Static binaries (with system libc) on Linux are okayish, if all the systems are the same distro, or at least have a libc of the same vintage, but breaks frequently if you try to go further (eg. deploying to LTS distros like deb oldstable, centos, ...).

Doesn't really compare to eg. Windows, where you just bundle the MSVCRT with the installer and unless you're API incompatible the application will just work everywhere.

That's why on Linux, by default, Rust link everything statically except the libc. But you sill can make a fully static executable by using the "musl" target.

Reply on news.ycombinator.com