I really don’t have any good arguments here. It’s a gut reaction to “I need to get the current time. Wait, I have to install an external library just to get the current time? That’s crazy!”. Note that I don’t feel like this every time I run into something I need but isn’t in-tree. For example, when I needed a BigInt and I realized it had been removed, my gut reaction was “Well, this is inconvenient, but it makes sense”. Again, that’s a weak argument, but that’s what I was thinking.
To provide some more context, I’m talking to the guy who runs codeforces.com, a popular algorithms competition site, to allow the use of Rust on the website. He agreed and asked me to write some code snippets he could use for benchmarking. Originally I had used Rust’s built in benchmarking features, but he had his own benchmarking system set up so that each language could be compared with the same facilities. So I had to benchmark the old fashioned way, by getting the time before and after the code and subtracting it. At this point I converted the project to cargo, and resent him the code. I honestly felt a bit embarrassed explaining to him why I converted a one file program that I can build with rustc to a multi-file program with a package manager that pulls a dependency and builds the code just to get the current time. None of the other languages had to do anything like that.
But now that I think about it more, I wouldn’t have been as upset if the process was something like cargo install time, and after that the time crate is installed globally and the original code would be able to use extern crate time without using cargo. This is how things work with Python right now; you can just install libraries and then import them. Maybe getting something like that working is a better solution than bringing the time or chronos crates in-tree.