Rust’s standard library should not require “special” initialization in order to be happy with getting called as a library; down that path lies languages with runtimes.
The thread name doesn’t seem like a problem at all; even threads spawned by Rust don’t have names by default.
On some platforms we can potentially get arguments after the program starts, and on others we can’t; as long as we don’t crash on any platform, that seems fine. Having a function to set the arguments won’t work on all platforms (if you want the concept of changed arguments to apply to code not written in Rust). This doesn’t seem like a problem to me; if you want to handle arguments, you need to get them from the code implementing
main(), even if written in another language. Perhaps we should have a convenient way of constructing an Args that way.
Regarding the stack guard initialization: as far as I can tell, that only exists to set up a signal handler to handle stack overflow and produce a friendlier error message. That’s a rather unexpected behavior, and programs that expect to handle SIGSEGV (or platform equivalent) themselves may find it surprising. I’d argue that we should document that better than we do, and ideally not do that by default. Could we have a compile-time option to select that behavior?
sys::init() itself does very little: on unix-like platforms it sets SIGPIPE to ignore (also not documented anywhere as far as I can tell), and on every other platform it does nothing.
So, overall, I don’t think there’s anything necessary in that initialization, and what is there we should either document or consider carefully removing or making optional.