> so in a sense it does have a longer pedigree than most other tools of that ilk.

That's true of most new languages. It seems like most projects these days can produce a LSP with minimal effort, make the obvious choice of sandboxing every project separately to avoid dependency hells across projects, have at least basic distribution systems even with small communities, etc.

The community learned a lot from the mistakes of yore.

All I know about Ruby is that I always seem to download three versions of documentation

Back when I used to use Ruby 10 years ago, I got used to doing the "no docs" args when I'd do a gem install. I always thought it was a cool idea to have local docs but, I never had an occasion to actually USE them. (never was I stuck in a non-internet-connected zone, wishing I had documentation)

Adding `install: --no-document` into ~/.gemrc is something of a reflex for me. Should only be getting `ri` docs these days by default though.

FWIW, the thing which really sucks about cargo is how it handles cross-compilation. Most "professional" workflows are always cross-compilation: even if you are technically on Linux already you don't want to build for the exact version you have so you create a sysroot and cross compile towards it... and cargo is somehow so bad at this that increasingly large numbers of projects are being forced to turn on a environment variable that has in the name of the variable DO_NOT_USE to shift cargo stable into accepting nightly flags so we can activate a patch that they begrudgingly committed to fix the behavior of targets to not get infected by host configuration if they happen to look similar. The goal was that this would eventually become the default but it's been years now and the related bugs are just stacking up. As a package manager I'm sure it's great... as a build system? Not so much.

The situation frankly really just sucks: as far as I am concerned--from the shear number of bugs I have run into trying to do what should be table-stakes, and which even autoconf handles trivially: doing deterministic builds across platforms of a library to be embedded into another language's build system--cargo optimizes for extremely simple use cases (hell: ones so simple they lead to the wrong mental model of compiling in the first place! like, people seem to seriously think you need to compile for old systems ON old systems using old tools as cross-compilation is somehow treated as esoteric) while throwing the people who know what they are doing under the bus, which isn't at all how one should build tooling; instead, the goal should be to make extremely difficult things easier to pull off, even if it means the simple things have to be a bit harder, as your overall workflow is then easier to manage and you can better grow with your tooling rather than having to eventually throw it away entirely.

Yeah, that tracks. That sort of cross-compiling isn't something you'd ever see in the Ruby world, as far as I can recall, so I guess it's a reversion to the mean.

Does `cross build` not work for your use cases?

You can set a default build target for a Cargo project with two lines of configuration, no nightly features necessary: https://doc.rust-lang.org/cargo/reference/config.html#buildt...

Can you clarify what this is referring to?

> the goal should be to make extremely difficult things easier to pull off, even if it means the simple things have to be a bit harder

There are dozens of existing build systems that have this philosophy, and personally I appreciate the default system being optimized for the average use case. The fact that the happy path is so easy is the reason that people overwhelmingly choose to use Cargo; we can lie to ourselves all we like about the appeal of things like memory safety and type safety, but at the end of the day Cargo is the reason that Rust is popular. (And to be clear, I'm not trying to say Cargo is perfect; I have a slew of my own bugs and feature requests filed against it.)

> ...but at the end of the day Cargo is the reason that Rust is popular.

FWIW, maybe that's true for you, but there are numerous other advantages to the language for which many people choose to use Rust--some even "despite" Cargo: you see Google having had to put in way way WAY too much work to get Bazel working for Rust :/--that it honestly feels a bit like belittling an extremely important language to make this claim so flippantly.

In my case, I often feel bad that I'm not using Rust more often, as I'm one of those developer churning out tons of C/C++ code. I do my best, but... I'm a security engineer! I know what I'm doing is stupid! But like, I'm having a hard enough time just dealing with the Rust library dependencies I've accumulated, so I'm not going to start developing even more Rust :(.

> You can set a default build target for a Cargo project with two lines of configuration, no nightly features necessary...

This doesn't work as, as soon as you start setting target-specific options, it infects the host's options, as they incorrectly modelled the problem as some kind of map from targets to flags. If you don't believe me, on your Linux computer, try cross-compile something complicated that will runs on a "least common denominator" Linux distribution, such as CentOS 7.

> Can you clarify what this is referring to?

Sure. I've Googled rust cargo target host bugs for you (which, FWIW, finds a number of bugs I've filed or have talked about, but it isn't as if I have a list anywhere). Note that one of these bugs is "closed", but I still provide them for context as a patch might have been merged but (as you'll find out if you read through all of these) it isn't stable.

https://github.com/rust-lang/cargo/issues/8147

https://github.com/rust-lang/cargo/issues/3349

https://github.com/rust-lang/cargo/pull/9322

https://github.com/rust-lang/cargo/issues/9453

https://github.com/rust-lang/cargo/pull/9753

The result of this work being left incomplete is that increasingly large numbers of "serious" projects--things I'd expect people in packaging land to have heard of, such as BuildRoot--are being forced to set the ridiculous environment variable __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS="nightly" in order to get access to a flag that makes Cargo sort of work.

I remember a bunch of other ones but I think they are linked from these bugs (I didn't want to dig too long on this); you can also find--either linked from these bugs (as people will tag the bug in their patch) or by searching for that variable (as no one else would use that in a sane project) the projects that are slowly being forced into this crazy workaround.

(What is sad is I often see people surprised at how long it is taking for various of the more important clients to fully get into using Rust, as the safety issues are so severe from continuing to use C/C++; as you made the contention that you believe the reason why people use Rust is Cargo, I will say the opposite: the reason why we don't see more Rust is also Cargo.)

Just do the build in a container modelling the appropriate environment. You don't need cooperation from the build tools (apart from controlling instruction selection), and you also don't need to trust that the build tool has implemented this feature correctly!

FWIW, it is easier to just not use Rust as the only serious build system I've had to work with that doesn't support this correctly is Cargo; and like, the mental model you are describing causes all kinds of other problems as it implies that if your build tooling simply can't run on a system old enough that you have to drop support for that system... people who are compiling serious apps (think Chrome or Ubuntu itself) and managing backports aren't sitting around with their CI systems running some old version of CentOS or Debian and praying their build tools continue to run on them: they just cross-compile.

And like, that Cargo doesn't handle this correctly is kind of silly as one of the engineers from BuildRoot seriously broke his back for a year jumping through hoops with them to come up with a compromise and satisfy all of their roadblocks (the Cargo people would rather spend hours talking with people about a patch than spend a few minutes touching it themselves... it was honestly demoralizing, but I've seen the same thing from projects like Flutter, so I think that it is just the reviewer / developer power dynamic that big tech taught a bunch of people) and the code is even in Cargo and yet is rotting in nightly.

(Meanwhile, I often see people bemoan how large projects aren't picking up Rust and using it to slowly cannibalize the C/C++ code in various projects, or are looking at distributions demanding answers for why there has been such struggle getting Rust code distributed, but the answers lie in the build model of the language and in no small part how difficult it is to use Cargo. If you just want to not care about those use cases and want to focus on self-compiled use cases--maybe you are doing web development!--that pick up all of the idiosyncrasies of the build system, then the community should just say that.)