I've been meaning to write a blog post on this topic. Maybe I'll do it tomorrow. But, I've been thinking about this question too, or at least a related one: how many new features does Rust get, and how often does it get them? I'd like to bring some data to this discussion.
In 2019, we had eight releases: 1.32 to 1.40.
- 1.32: one language adjustment, finishing off previous module work
- 1.33: const fn can do a few more things
- 1.34: you can do a bit more with procedural macros
- 1.35: a few minor details around closures
- 1.36: NLL comes to Rust 2015. Not really a new feature so much as backporting it to an older edition.
- 1.37: you can #[repr(align(N))] on enums
- 1.38: no real language changes
- 1.39: async fn! some adjustments to match. Some more borrow checker adjustments.
- 1.40: #[non_exhaustive]. The 1.39 borrow checker adjustments are ported to an older edition. Macros can go in a few more places.
Really, 1.39 was a huge release, and other than that... all language changes were very minor, mostly sanding off some edge cases, making some things more orthogonal, stuff like that.
Most releases these days add some standard library APIs, maybe we have some toolchain improvements... but for all of 2019, we had one feature I'd call truly major.
I suspect that things were a lot more hectic previously, but the language has slowed way, way down recently. We have had two releases so far this year, and I would argue that the only real language feature was an expansion around match patterns. Which again, isn't so much a new feature as it is adding a little bit to an old one.
Churn is real. It's important to keep in mind. We've said for a very long time that Rust's churn rate would slow down. It's really pretty low at this point. Or at least, in the language.
One person on the lang team writing two blog posts fleshing out an idea does not mean the sky is falling.
My main concern is with new syntaxes. Expanding use-cases for existing ones, loosening restrictions that can be safely loosened, etc. are all well and good. But layering on new sugar-syntaxes that aren't truly necessary makes the language much harder to mentally grok over time. All of a sudden you can't just derive what's happening by studying the code, you have to add new pieces of arbitrary information to your mental toolbelt first. The Ok(..) one mentioned, from a quick glance, seems really unnecessary.
Your general concern, which is that "new syntax makes things less explicit, and is therefore bad", isn't logical.
Adding new syntax has many costs (not only one), but it can also have benefits (hence why it is being proposed), and the real question is whether the benefits outweigh the costs.
That is, whether it is a trade-off worth making.
In the blog post, the author quantify the actual costs of not having Ok-wrapping on their own code, as well as the costs of adding Ok-wrapping to the language, and for them, their numbers suggest that the trade-off is worth it - so they went on and implement it as a proc macro, and are using it on their own code. They don't care whether anybody elses uses it, and they don't have to.
You could have disagreed with their quantification, maybe you have different numbers, and that leads to a different outcome of whether the trade-off is worth making or not.
Instead, you just disagree, without making an argument, and others are doing the same.
In my eyes, this kind of hurts your position, since it gives me the impression that those against Ok-wrapping can't really argue why. Whether they just can't argue in general, lack data to back their arguments up, or maybe even whether they are Rust users at all, is anybody's guess.
I can't imagine a Rust application writer that is using Result idiomatically and not doing _a lot_ of manual Ok-wrapping all over the place. I can't imagine anybody actually enjoying that manual Ok wrapping. Looking at servo, the Rust compiler, and all my applications, what people end up doing is writing their own one-shot local macros to hide that manual Ok wrapping. Having written some of these myself, it definitely did not happen because I was "enjoying it too much". On the contrary, once or twice per function is ok, but when I had to do it dozens of times per function, it was just too painful both for the people writing it and those maintaining that code.
it doesn't seem to me that your reading of brundolf's post is very generous. the post doesn't mention explicitness at all, but says that increasing the number of syntaxes that can be used for the same purpose increases mental overhead for reading code. also, the post says that this particular proposal "seems really unnecessary," strongly implying that the author does not believe the tradeoff is worth it.
personally, while I can't claim to love writing Ok around return values, I definitely value the enhanced readability that comes with it. rust is the most readable language I've ever coded in, and it's not even close. when I see the "throws" syntax that was proposed, I expect it would make it harder to read the code because the Result type is erased from the type signature. To me, whatever tradeoff I would gain in ease of writing code from this would be far outweighed by the cost in reading that code.
C# became that way to me. Some of the new syntactic sugar was redundant and wound up making code less easy to follow. I didn't adopt it all myself, but it made me less interested in parsing through others' codebases.
I still typically remove the LINQ defines from my own new code, and that seems to be one of the more acclaimed language features.
In 2019, we had eight releases: 1.32 to 1.40.
- 1.32: one language adjustment, finishing off previous module work
- 1.33: const fn can do a few more things
- 1.34: you can do a bit more with procedural macros
- 1.35: a few minor details around closures
- 1.36: NLL comes to Rust 2015. Not really a new feature so much as backporting it to an older edition.
- 1.37: you can #[repr(align(N))] on enums
- 1.38: no real language changes
- 1.39: async fn! some adjustments to match. Some more borrow checker adjustments.
- 1.40: #[non_exhaustive]. The 1.39 borrow checker adjustments are ported to an older edition. Macros can go in a few more places.
Really, 1.39 was a huge release, and other than that... all language changes were very minor, mostly sanding off some edge cases, making some things more orthogonal, stuff like that.
Most releases these days add some standard library APIs, maybe we have some toolchain improvements... but for all of 2019, we had one feature I'd call truly major.
I suspect that things were a lot more hectic previously, but the language has slowed way, way down recently. We have had two releases so far this year, and I would argue that the only real language feature was an expansion around match patterns. Which again, isn't so much a new feature as it is adding a little bit to an old one.
Churn is real. It's important to keep in mind. We've said for a very long time that Rust's churn rate would slow down. It's really pretty low at this point. Or at least, in the language.
One person on the lang team writing two blog posts fleshing out an idea does not mean the sky is falling.