Great post, digestible without experience in capn proto specifics.
I really like that they talk in terms of “features carrying their own weight” and survey real world code to see what cases features solve for, and how (surprisingly little) certain features are actually used.
A side effect of dropping features when designing for code generation (in this case) is that it makes things more concise for everyone else as well, including the users.
There are generally no easy answers, but as a principle I think the burden of proof for new features should be high. “Oh it’s nice” is not enough, unless it’s trivial syntactic sugar. It should really be at least a strong need and ideally multiple needs per feature, so to say.
Premature optimization is the root of all evil - again. Applies to performance and features. Unless you can proove (not formally, but for yourself) that feature will make things better, don't implement it.
I really like that they talk in terms of “features carrying their own weight” and survey real world code to see what cases features solve for, and how (surprisingly little) certain features are actually used.
A side effect of dropping features when designing for code generation (in this case) is that it makes things more concise for everyone else as well, including the users.
There are generally no easy answers, but as a principle I think the burden of proof for new features should be high. “Oh it’s nice” is not enough, unless it’s trivial syntactic sugar. It should really be at least a strong need and ideally multiple needs per feature, so to say.