4 ms·

Yeah, the position you articulated is my main concern. Do you think it makes any differences if the features are enabled-by-default? If so, the "default" expe

• mplanchard 5y ago
  Yeah I think default features resolve a fair bit of the pain. I wonder though how many consumers are actually going to go through the hassle of slicing just what they need out of a library. For something as large and featureful as Tokio it makes sense, or for optional additions to core functionality, but we at least haven’t yet found ourselves going around and looking for places to trim the fat. One dependency like diesel or something similar eats up easily 10x the compile time of any other single dependency, so we’ve been more focused on rooting out those big offenders when we can. I definitely wouldn’t want to ask that OSS maintainers take on extra maintenance burden unless there’s a good reason. Features are super neat, but it’s easy to see them overused. It’s also a bit hard to adequately test arbitrary combinations of features. It’s a different concern from a library, but we saw this with one of our applications. We had a situation where we were using features where we should have just been using env vars for feature flagging, and it caused a fair bit of hassle. We’ve since ripped out that usage, because we never in practice tested or deployed with anything other than “all features,” and even in the case where we want to use some functionality to upsell, enabling an env var and restarting is way easier than recompiling the project.