Pre-RFC: flexible `try fn`

[skade]

@rvolgers

Python has the advantage of having an extremely clear “zen of Python” as well as a “benevolent dictator for life” who is the final authority. This creates a language that has a very clear sense of itself from the start, something that Rust does not really have (yet).

I find it interesting that Python is often mentioned like that. Python has a lot of baggage and a lot of weird things (like being a "batteries included" language that has no ISO 8601 dates in the stdlib...).

Ruby is also BFDL, which turns to a lot of oddities. You know that thing with "the principle of least surprise"? That surprise is explicitly Matz Surprise ("The principle of least surprise means principle of least my surprise.")

I also don't believe that BFDL improves things. The way C++ went has nothing to do with having a committee, it has to do with being a language from the 80s. Many ideas that sounded good back then turned out to be bad. We can avoid those mistakes.

We'll make our own instead. We've already made some.

Java is also design by committee and did turn out an extremely coherent language.

BFDL is an old-fashioned process of the 90s. Rust wouldn't be better if some of the leading figures where crowned king and having final say.

But the way the current RFC process is structured, I’m not sure there is a good forum for people who prefer the “do nothing” option. Thumbs-downing a lot of RFC’s and forum threads is content-free and not helpful. Commenting on a proposal about how it goes against what you feel should be the “zen of Rust” is derailing and requires unpacking a lot of context that is probably offtopic for many people who want to discuss the details of the proposal. And finally, people who like the language as is don’t want to hang out on the RFC repo all day commenting.

I'm one of the "wait a little" crowd, regularly. I have discussed in a couple of RFC (especially around the module path changes) to not make them (at least the first couple of RFCS). Be reminded that module path changes are a thing that were struck down multiple times before the RFC was accepted. These opinions are heard.

People are too attached to the RFC process directly. Yes, the RFC process gives no venue for overarching discussion. Because its focused on details. Also, if you want to work on an RFC level, yes, you totally have to make the time. But there are other things, like this forum.

Also, we do make offers for people that don't have time for RFC and encourage them to write about what they want to see in the language: The #rust2018 blogging campaign did that. Turns out, many people want to see changes. Not many people asked for a cooldown.

If you have a different plan for the wider evolution of Rust, everyone can write a long form text here or at your blog. People listen and take that stuff into account. Just be aware that not following your sketched path (in full) is also always an option :).

We are very aware of many problems the RFC process has.

I don't find @withoutboats comment derailing, it lands precisely at the right spot. Its point is not "don't say we should do this", its point is "this is a very cheap argument, frequently made, that we can't interact with". It asks for nuance. Pointing to C++ and saying "accumulating features is bad" doesn't help us. You can't interact with that - it would ask for freezing. Pointing out how this feature might not improve things enough to cover the implementation cost helps us. That's something that can be interacted with.