3 ms·

How are you planning to limit the rate at which new features are added? * Restricting the rate of new releases doesn't necessarily mean you're reducing the ave

How are you planning to limit the rate at which new features are added? * Restricting the rate of new releases doesn't necessarily mean you're reducing the average feature development rate. It might instead mean that you're releasing hundreds of new features per release, which is definitely worse than releasing a hundred versions with one feature each, because it can force people to rush things out to meet a release window instead of releasing them when they're actually ready. * Restricting the number of feature bullet points per release doesn't necessarily mean you're reducing the amount of functionality being developed. It might instead mean that people try to develop huge "super-features" that technically count as one bullet point but actually gets used in dozens of different ways. Super-features are an easy way to wind up with a system where everything is possible, but the stuff you do every day is more difficult than it needs to be.

remram 4y ago
Yeah in practice the Rust community writes a lot of code that uses experimental features, that need an explicit feature gate and the nightly build of the compiler. This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. If the Rust team refuses to ship the features in stable releases, people are just going to use unstable releases and that will make the experience worse for everyone. There is no way to artificially restrict features unless you have multiple software in the ecosystem that needs time to update: for C it is the other compilers following the C standard, for Python it is the Python executable on your end- user's machine. The minute rustc updates, Rust developers have little reason not to use the features.
- estebank 4y ago
  > This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. How is this a problem? The crate authors targeting nightly features know full well that they are restricting their pool of users, while at the same time driving the testing and design of nightly features forward. If no one is actually using them, then they are unlikely to get quickly stabilized. > If the Rust team refuses to ship the features in stable releases Can you show a case of refusal to ship a needed feature? > Rust developers have little reason not to use the features. Rust developers of end user applications don't. Crate authors do, if they want to gain wide adoption.
  - remram 4y ago
    I feel like you read my entire comment wrong. Like you didn't read what I replied to, stripped all the "ifs" and arguments, and hyper-focused on points I wasn't trying to make. Surely I wasn't as clear as I thought but this feels so strange.

remram 4y ago

Yeah in practice the Rust community writes a lot of code that uses experimental features, that need an explicit feature gate and the nightly build of the compiler. This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. If the Rust team refuses to ship the features in stable releases, people are just going to use unstable releases and that will make the experience worse for everyone. There is no way to artificially restrict features unless you have multiple software in the ecosystem that needs time to update: for C it is the other compilers following the C standard, for Python it is the Python executable on your end- user's machine. The minute rustc updates, Rust developers have little reason not to use the features.

estebank 4y ago
> This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. How is this a problem? The crate authors targeting nightly features know full well that they are restricting their pool of users, while at the same time driving the testing and design of nightly features forward. If no one is actually using them, then they are unlikely to get quickly stabilized. > If the Rust team refuses to ship the features in stable releases Can you show a case of refusal to ship a needed feature? > Rust developers have little reason not to use the features. Rust developers of end user applications don't. Crate authors do, if they want to gain wide adoption.
- remram 4y ago
  I feel like you read my entire comment wrong. Like you didn't read what I replied to, stripped all the "ifs" and arguments, and hyper-focused on points I wasn't trying to make. Surely I wasn't as clear as I thought but this feels so strange.