pre-RFC: LTS for the Rust Toolchain

zackw: > I'm going to call this the "it's not actually hard to stay on the treadmill in Rust, people shouldn't be worried about it" reaction. It doesn't work on anyone who is already worried about it, for the same reason that it doesn't work to try to calm down a small child who's scared of the monster under their bed by assuring them the monster doesn't exist. No amount of assurance that it's easy to check and actual problems are rare will make someone stop being scared of tripping over some breakage that will take weeks to fix and by the time they're done there'll be another release bump and they'll have to do all this validation all over again again and they are never going to get to work on the fun part of this project anymore. Fear is irrational thst is true. I don't think we should make the language measurably worse for everyone else though, by decreasing the release cadence. The child analogy falls apart when it comes to tjr responsiblity: if it is my child I'm willing to go out og my way for them, if it is some random enterprise user who isn't paying or contributing back, dealing with their fear is on them. That said, features like cfgs to check language festures / versions doesn't have much of a downside (depending on how complicated the implementation of it is), so I'm not against that. zackw: > You may be right about this! Does anyone want to pay my expenses to go to RustConf or EuroRust and run another field study on current Rust developers? I will be happy to do this if someone pays my expenses. Me too! I too would like a paied trip. zackw: > Case Rust: Once every six weeks, you need to spend one or two hours reading the release notes, running rustup, and testing your code with the new compiler. That is not a realistic number of hours for that. How it actually works as a hobbyist is that I set dependabot or renovate to create two PR once a month to lift dependencies. One for semver compst deps and one for semver breaking. If it builds and passes automated tests I can merge it. Otherwise I can look at the particular failure (sometimes new clippy lint and I deny warnings. If you don't want to deal with that just don't deny warnings in CI). That is nowhere near "a couple of hours". It might become a couple of hours in the worst case for semver major dependencies. zackw: > This is possible in C not just because C moves so very slowly, but also because C's metaprogramming capabilities are more powerful than Rust's in a couple of critical aspects, especially when augmented by a "configure" script -- it's no burden at all for me to put the handful of C2011 features that are useful to me under #ifdefs because I can trivially express "does this compiler have support for _Generic?" (for example) independently of "does this C library include the function strsignal?" As a hobbyist this isn't something I would aim for. Now I need to write the code twice, once for having the feature and once for not having it. Given my 1-2 hours per week for hobby programming, I'd rather not. Either I use the new way of doing things, or the old. Not both.