Oh hell no.

Sun was widely criticized for that boneheaded move, and for the whiplash everyone experienced in Java 5 when they changed that policy too fast.

The mass of changes in 5 left a lot of tools and thus people stuck in 1.4 for years. I started on a project a bit before 6 came out. It was processing data and I couldn’t use the collections API, because it had to run on an embedded system and Aicas was taking their sweet time catching up with all those changes. Four years later I was still using arrays for everything.

Ok-wrapping isn't a change that's been made. At best it's a hypothetical change that one person wanted to have a calm, rational discussion about with the community. Instead we get this.

So what? Then don't use them. The whole point of full backward compatibility is that you don't have to use new features. This perceived need to always use the newest feature is only in the head of some developers.

Neither in the blog post nor here do I see any reason to not make the experience better for people who want it. Even if it's just a "minor" (very subjective, I love the match ergonomics enhancements) annoyance that's fixed by it.

Is there ? This is a genuine question - I've tried rust back in 2013 and have been following it from the outside not using it for anything serious since I haven't had a use case. My impression is that it's still a niche language with and their user base seems to be very involved and engaged. It don't have the impression that there are a lot of companies that are "just doing their job with Rust and not making a lot of noise about it" - if a company is using Rust for something it's probably writing an engineering blogpost about it and the guy who spearheaded it is probably active within the community. I'm just basing this on the amount of Rust posts vs the amount of Rust use/job postings in those quiet, doing their thing companies.

This should be the norm for serious programming languages. Anything else is a hyperactive children's toy.

I think current rough consensus is anyhow/thiserr depending on if you're writing an application or library. I haven't actually used them myself, though. You don't have to keep up with the cool new libraries.

This lets me write code like this:

    #[derive(From, Debug)]
    pub enum SomeSpecificError {
        Io(io::Error),
        SomeAppLevelErrorCondition,
    }

    fn do_something() -> Result<(), SomeSpecificError> {
        do_some_io()?;
        // ...
    }

    fn do_something() -> Result<(), SomeSpecificError> {
        do_some_io().map_err(SomeSpecificError::Io)?;
    }

[0] https://jeltef.github.io/derive_more/derive_more/from.html#e...

Might suit some people.

https://github.com/rust-lang-nursery/failure

I gave up on EmberJS around the same time because I only got a five hour chunk of time every couple of weeks and they were making semantic changes so frequently then that it felt like I spent half of my time upgrading my code to work with the changes. It ended up being a major factor in killing that project for me and I’m just now getting back to it.

Rust designers did consciously try to minimize innovation. To that end, Rust error handling is linguistically parsimonious: the standard library Result type used idiomatically, plus the ? operator (itself very simple). To the extent it innovated, it did so by excluding dynamic exception throw/catch and dedicated error result syntax from the language.

Rust async/await is also not unnecessarily innovative. At heart it is the same as async/await in JS and C#. Getting it to work with the Rust ownership model was hard and did require some innovation. LWT was dropped from Rust because it was not compatible with Rust's goals.

Likewise, higher-kinded types aren't especially innovative but will require significant work to flesh out for Rust because of the ownership system.

Otherwise, it seems to me that what you are asking is "Why didn't the Rust developers ship a 20 year old language on day 1?".

So I can see why they went with something different for error handling.

[1] https://os.phil-opp.com/async-await/

I know that's not technically right, but it still seems a better approximation to reality.

How so? Aren't await and ? both new special cases?

And in a way it is :) given who worked on it, and where it was created.

Despite my opinion regarding its design, Go was definitely a C replacement for F-Secure TamaGo, Google's gVisor, Android GPGPU and CoreBoot projects.

I haven't used Go beyond tutorials and some very basic programs, but I am pretty comfortable with Java. What about Go makes you feel it's relatable to Java? From what I've read the lack of generics is a hot topic in the Go community, but they're pretty crucial to most programs written in Java. Is this still true?

Just today someone posted in /r/rust about how they took a two year old project, compiled it with the latest compiler, no issues. Other than it magically took less time to compile and the end result ran faster.

Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust). "Have you considered giving up?" is obviously not a very interesting question and not one that's going to get much traction.

Syntax is something very emotional and beauty is very subjective. Thanks to the Rust team, the discussion around await syntax was mostly focussed on rational arguments, not around perceived beauty. The outcome is great in my opinion.

Most new language getting added to Rust, are added to the Rust 2015 edition (e.g. NLL). If you need a language feature that is added to a later edition only (like the `try` keyword), that's because the feature is incompatible with code being used in earlier editions (which declared a macro with the keyword name).

You can continue using the macro by just using raw-literal syntax.. but my old Rust code tends to "just work", so I don't really need to update it. My crates are also very small, so if I'd ever need an update, it wouldn't take too long - but haven't had to do that yet, so can't comment.

I tend to write most of my new code on new crates, so I default them to whatever edition was the default when I create them, and never look back.

I have lot of 2015 crates in my dependency tree, and that works just fine.

Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.

...can't you upgrade and choose not to make that change? Did something happen to make that not compile?

(not a Rust user)

The one mentioned in the article seemed fairly frivolous to me. I don't know if I can name one that's already been accepted into the language which I would call frivolous, per se, though they're all varying degrees of necessary. But most of the "sugar" syntaxes have made the language harder to understand for newcomers, even the ones that are arguably necessary. They all come with a cost.

The ? syntax for Results, for example, rubs me the wrong way a little bit. In that case it really does eliminate a large amount of code and is probably worth the trade-off. But now instead of Results just being a monad that can be picked apart like any other data structure, they become a Language Feature that gets special, magical treatment not expressible by the type system. You just have to know what the question mark translates to underneath. Worthwhile or not, this makes me sad. Async/await is a similar case.

> Also compile times have been a big focus of the compiler team, and have been going down YoY.

Yes but adding complexity to the language immutably increases the difficulty of that task. Even if only by a little bit, it adds debt that will have to be reckoned with for the rest of the language's lifetime.

Often I think I have understood something, try to verify by doing the wrong thing, but then because of sy tactic sugar it still works.

Two recent things come to mind:

- Automatic dereferencing, which can dereference arbitrarily long chains of indirection. This makes it hard to figure out which types I have.

- That `match` somehow accepts a reference to an enum, and then magically turns it into an enum over references.

Not that I don't think these will be worth it in the long run, but it makes the language harder to learn.

https://doc.rust-lang.org/std/result/enum.Result.html

Do you ever write code that returns, e.g., an `Iterator` ? e.g.

    fn my_map<T: Mul, I: Iter<Item=T>>(it: I, x: T) -> impl Iterator<Item=T> {
        it.map(|i| i * x)
    }

I use it a lot. What before required a lot of boilerplate, now is a one liner.