Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”
In small print it says the data is collected over 2022 and 2023.
this post was submitted on 28 Mar 2024
247 points (94.3% liked)
Rust
5958 readers
11 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I won't disagree, but what Rust did is not the correct answer. Better than C++ perhaps, but not good enough. In the real world my code is more than Rust. I'm having trouble using rust because all my existing code is C++ and the dependency management does not work well with my existing build system and dependency management. If you want a dependency manager it needs to cover all languages and be easy to plug in whatever I'm doing currently. This is NOT an easy problem (it might not even be possible to solve!), but if you fail you are useless for all the times where dependency management is hard.
It's hard to say that what Rust did was not correct when it's better than what C++ has (nothing, or rather it punts to the OS and user to handle it). I agree it's far from perfect but it's as good as pretty much any other languages dependency management system that I'm aware of. If you know a better one I'd love to hear about it because yes, there are still gaps and pain points. I'd argue many of those gaps and pain points are a legacy of C and C++ though. The fact that C/C++ never had an actual dependency management system meant that the OS had to provide one, and every OS more or less went about it in an entirely different fashion (and even worse in the case of Linux, every distro went about it in a different fashion). This has massively complicated things because there is a HUGE body of C/C++ libraries that are very desirable to use with absolutely no consistent way to do so. It's not as simple as just adding the ability to pull from the C/C++ repo for any of those dependencies, because there is no such thing.
OCaml's OPAM. They actually took into account that it could be desirable to use software written in other languages in your OCaml project. It even has a bunch of stuff packaged that's written in Rust. Imagine that the other way around. It only has stub packages for compilers like gcc but I assume that's likely because they don't want to have people spend hours building the whole thing themselves when there's a perfectly good one on their system, rather than it not being possible to do.
I love Rust but I will die on this hill that combining package manager and build system like Cargo does and then only making it work for a single language is a lot worse than what C++ does, because if it doesn't work for your project you're screwed. Everything expects you to use Cargo, especially if you intend to publish a library, with C++ you can at least pretty much always get the build setup to do what you need, and you can import whatever as long as it comes with a pkg-config file.
You're looking for Nix (unless you're a Windows developer, work on getting that to work is ongoing). There's very likely other good ones too, but this is the one I like and am familiar with. The difference is that it's not a package manager for C++, but a package manager that also packages C++ packages. Which makes it so much more versatile than something like Cargo, because you can accurately represent dependency chains regardless of what language each package is written in. My Nix + CMake projects will build consistently on every Linux or Mac computer (you can't say the same for Rust crates because they will look for stuff in system directories because Cargo can't package anything that isn't Rust), and you can depend on them similarly to how you would a Rust crate, with the difference that you can depend on them not only in another C++ project, but also in a Python package, a Go package, or whatever else that can be packaged with Nix. And if you can't use Nix, then you can always build the CMake project directly, package it somewhere else maybe, because the two parts are not coupled together at all.
I'll look into OPAM, it sounds interesting.
I disagree that combining build and package management is a mistake, although I also agree that it would be ideal for a build/package management system to be able to manage other dependencies.
A big chunk of the problem is how libraries are handled, particularly shared libraries. Nix sidesteps the problem by using a complex system of symlinks to avoid DLL hell, but I'm sure a big part of why the Windows work is still ongoing is because Windows doesn't resemble a Linux/Unix system in the way that OS X and (obviously) Linux do. Its approach to library management is entirely different because once again there was no standard for how to handle that in C/C++ and so each OS came up with their own solution.
On Unix (and by extension Linux, and then later OS X), it was via special system include and lib folders in canonical locations. On Windows it was via dumping everything into C:\Windows (and a lovely mess that has made [made somehow even worse by mingw/Cygwin then layering in Linux style conventions that are only followed by mingw/Cygwin built binaries]). Into this mix you have the various compilers and linkers that all either expect the given OSes conventions to be followed, or else define their own OS independent conventions. The problem is of course now we have a second layer of divergence with languages that follow different conventions struggling to work together. This isn't even a purely Rust problem, other languages also struggle with this. Generally most languages that interop with C/C++ in any fashion do so by just expecting C/C++ libraries to be installed in the canonical locations for that OS, as that's the closest thing to an agreed upon convention in the C/C++ world, and this is in fact what Rust does as well.
In an ideal world, there would be an actual agreed upon C/C++ repository that all the C/C++ devs used and uploaded their various libraries to, with an API that build tools could use to download those libraries like Rust does with crates.io. If that was the case it would be fairly trivial to add support to cargo or any other build tool to fetch C/C++ dependencies and link them into projects. Because that doesn't exist, instead there are various ad-hoc repositories where mostly users and occasionally project members upload their libraries, but it's a crap-shoot as to whether any given library will exist on any given repository. Even Nix only has a tiny subset of all the C/C++ libraries on it.
Dependency management has to deal with the real world where what we didn't know in 1970 hurts us.
I'm having trouble understanding the point you're trying to make here. You seem to be angry at the Rust dependency manager for not being perfect, but also admit that it's better than C++. Is there some dependency manager you like more than what Rust provides? Do you have any suggestions for how Rust could improve its dependency management?
I said this is a hard problem and might not even be solvable.
rust is not better than C++ if you are in any of those cases where rust doesn't work. Not really worse, but not better either. If it works for you great, but it is worse for me as rust fight our homegrown system (which has a lot of warts )
So you're point is that your custom home grown workaround to a failure of C++ doesn't play well with Rusts official solution to the same problem? And therefore Rusts solution isn't better than C++ lack of a solution?
While that is unfortunate for you and you certainly seem to have tech-debted yourself into a particularly nasty corner, I'm not sure that logic follows.
Rust's package manager doesn't manage c++, python, or anything else. Since the real world should not be one language to rule them all any package system must handle all possible languages. Otherwist they are lacking.