4 ms·
> Can you give an example of a Rust project where you have had this experience? Trying to make a better experience I just randomly picked "Weylus" from Github'
by jstimpfle 5y ago
> Can you give an example of a Rust project where you have had this experience?
Trying to make a better experience I just randomly picked "Weylus" from Github's rust/trending list and wasted more than 1 hour building it on Windows 10 and Debian Bullseye, ultimately quitting both. Yes, it was a lot of C library related issues, but also other executables missing, like tsc, or in case of Windows, make. On both systems, the number of transitive dependencies was about 300, and so I guess it was inevitable that there were going to be some problems.
I've had similar problems before that trying to build other, less ambitious programs than Weylus using cargo.
> it's hard to claim this as a weakness of Rust relative to C when it's no worse than what you'd get in a pure C project.
It seems to me that making it more reliable to depend on other modules (like cargo does) does not lead to easier to use projects, since it doesn't change the amount of bullshit that most developers and users are willing to endure. This is an instance of Parkinson's law and I think it was already a learning from the node.js ecosystem.
As a consequence, with a system like cargo programs end up having far more dependencies (which is empirically true), but the programs aren't easier to build by a random user. For developers, the situation is changed compared to e.g. C, in that it is easier to add more dependencies before the software becomes unmaintainable. This might shift the development situation to a place where the average developer in this ecosystem is more competent in plumbing things than understanding the problems and coming up with reliable solutions that are easy to maintain without a system like cargo.
I'm not sure if this is good or bad - probably it's an evolution that can't be stopped, and which creates new types of developers. What I'm saying is I'm not positive that this attitude is compatible with a central piece of infrastructure, like the Linux kernel is.
> Can you be more specific about which of these crates provides functionality which you do not think qualifies as generally foundational?
I'm not a Rust developer and I don't know any of these, but looking at those names I'm wondering: which is not some arbitrary helper thing, where it would be easy to maintain an alternative in-tree? At least that's better than each developer bringing their own slightly different preference, resulting in more bloat and maintainability problems.