Hacker News Reader

Comment by npalli | Hacker News Reader

But to flip this around, let's say you want to use this third party in some other "modern" language how would this become better?. Clearly if someone hadn't done the work to package in vcpkg/conan you can expect it wouldn't exist in pip/cargo/npm either. So if you had a bad time in C++, you would have a dramatically worse time in other languages. Goes to show what everyone else is saying here, there are parts of historic C++ which are in very bad shape particularly the build story. However, if it's in vcpkg it is exactly as easy to install as the other ones.

View on HN

The main difference being that Cargo is both for distributing and building locally AND it’s the blessed way of building all Rust projects. This means that as long as you have a copy of the codebase, it’s going to be using Cargo & you can add it with Cargo regardless of it being published formally to crates.io (the copy can even be remote since you can build from a git reference directly). Python packaging requires more work although there’s typically no build step so you can probably just __import__ the path and move on. JS is closer to Rust in that package.json is the standard way to manage components and you can import them even if they’re not published via the npm registry.

Pretending the situation isn’t very different for C++ is completely ignoring the standard committee’s complete abdication of standardizing a build system (which by the way if they’re not going to do, why are they bothering to standardize anything?)

> But to flip this around, let's say you want to use this third party in some other "modern" language how would this become better?. Clearly if someone hadn't done the work to package in vcpkg/conan you can expect it wouldn't exist in pip/cargo/npm either. So if you had a bad time in C++, you would have a dramatically worse time in other languages.

Err, no?

In case of Rust usually there is really no work that's necessary to package it and upload. You just type `cargo publish` and you're done (after filling out metadata in Cargo.toml). Even if someone wouldn't upload it to crates.io as a Rust crate you can just add a single line to your Cargo.toml:

    package_name = { git = "https://github.com/user/repo", rev = "revision" }

and you're done, you can use it as a dependency.

I think you moved the goalposts. I can configure a CMake file to pull a GitHub repo, which seems similar enough.

I think the difference is that you can pip install a github url and it will work, it will even work if the upstream has done nothing to package it.

I think the issue could be broadly defined as how difficult it is how difficult it is to take someone else's code and use it as part of your project. For C/C++ the answer can be completely trivial to a massive pain in the ass.

Oh I dunno. With cmake it really is pretty straight forward. You can pull from VCS, a tarball, even use a git submodule.

If it's another Cmake project, that's the happy path. Easy peasy. If it's not you still have the ability to run ./configure && make or evoke whatever incantation is in the dependency's requirements. I'm not the hugest fan of cmake, but I've worked with it quite a bit and it's a much more pleasant story than other languages I've used a lot like python, JavaScript, OCaml (which I love), etc.

I do find rust and go dependency management a little simpler due to the prescribed nature of them, but once you get off the happy path, the flexibility of C land is tough to beat. It sort of matches the language stories themselves; you have more control and have to do a bit more yourself. It's all about trade offs.

How often do folks venture off the happy path with Rust dependencies? Personally I’ve never once found myself in that situation.

I've done it before to integrate rust into polyglot build systems. There's a surprisingly long history of build systems trying and failing to implement rust builds without the "happy path" of simply wrapping cargo. As far as I know no one's ever succeeded.

Reply on news.ycombinator.com