5 ms·

Async took years, burned out everyone involved, and many people complained about how long it took.

Ygg2 6y ago
I know I am in the minority, but for me async is an anti-feature. I'm not sure who is it for, but if it's responsible for Pin and it's related unsoundness issues, that just makes me dislike it even more. A language with BDFL could have, took a more principled stance and said no async until we prove Pin is safe.
- steveklabnik 6y ago
  They could have said "we won't ship this yet," and they also could have said "ship it" to the initial design in 2015. > took a more principled stance This is very insulting. Bugs are often found in every kind of software. Virtually no languages that exist, let alone popular ones, require proofs before landing new features.
  - Ygg2 6y ago
    > This is very insulting. Bugs are often found in every kind of software. To me it's not a bug. It's a foundational flaw. If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation. If standard library is unsound, that means pretty much everything derived from/relying on that functionality is unsound. Adding unsoundness for the sake of pushing a feature out is just bad. It's cutting corners on essential things. > they also could have said "ship it" True. But if I know that BDFL is an asshat, then I avoid that project.
    - steveklabnik 6y ago
      There is a difference between saying "I believe new features should have proofs of soundness before landing" and saying that developers are "unprincipled." The former is a specific technical critique, the latter is an insult directed at the people making decisions. Specific technical critiques are great. Suggesting a lack of principle from the developers is not. Here's why this matters. This response from you is much better! Because: > If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation. Yes. Everyone agrees, in principle, that Rust being sound is an important property. Your criticism isn't actually about principles, it (appears to me, anyway) that it is about the specific methods in which we figure out if something is sound or not. You can argue that nothing should be added without formal proof, and that's a fine position to take, but at least it is a specific, actionable criticism that can be discussed directly. By this standard, virtually all languages have "unprincipled" designers. This isn't even true of only async! We didn't (and still sort of don't) have a formal model of the borrow checker. So you can't really criticize async specifically in this way, you'd have to criticize the entire language.
      - Ygg2 6y ago
        > the latter is an insult directed at the people making decisions The way I see unprincipled is two fold: 1) You're breaking your promise 2) In a similar situation behave differently 1) Pin was a problem from the start. Allowing it into std/core was a mistake. The fact they allowed an almost blatantly unsound feature is unprincipled. I'm not 100% sure of the timeline, but near or before the release there were examples floating of a possible Pin unsoundness. And defense was, it's an obscure thing, no one would really use that in practice. The moment designer says, no one would use that in practice, is the moment they lost. 2) Yeah, I get async was a feature everyone wanted. By same measure, why not add self-referential struct. People want it. It's probably unsound but you can't tell. Maybe there exist a model that allows self-referntial structs. Similar situation, different behavior
        steveklabnik 6y ago
        Nobody promised full formal specifications before landing features. The pin soundness issue was found close to release, but a plan was made to fix it before it was released. Pin is not fundamentally unsound. People do want it, and in fact, it is part of async, and directly related to the soundness issues you’re complaint about. The reason such things aren’t in stable is that, while people do want it, people wanted async more, and did the work. The work has to happen, features don’t just magically come into existence.
- ChrisSD 6y ago
  The only unresolved soundness issue for Pin that I can find seems to only affect nightly not stable. https://github.com/rust-lang/rust/issues/68015 https://github.com/rust-lang/rust/issues/68015 It doesn't appear to be unresolvable.
  - Ygg2 6y ago
    I never said they were unresolvable. I'm glad they are resolvable. But what if the issue was unresolvable? Rust would either have to rollback a feature or basically say, we're sound, except for that part.
- carols10cents 6y ago
  You don't have to use async if you don't want to.

Ygg2 6y ago

I know I am in the minority, but for me async is an anti-feature. I'm not sure who is it for, but if it's responsible for Pin and it's related unsoundness issues, that just makes me dislike it even more. A language with BDFL could have, took a more principled stance and said no async until we prove Pin is safe.

steveklabnik 6y ago
They could have said "we won't ship this yet," and they also could have said "ship it" to the initial design in 2015. > took a more principled stance This is very insulting. Bugs are often found in every kind of software. Virtually no languages that exist, let alone popular ones, require proofs before landing new features.
- Ygg2 6y ago
  > This is very insulting. Bugs are often found in every kind of software. To me it's not a bug. It's a foundational flaw. If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation. If standard library is unsound, that means pretty much everything derived from/relying on that functionality is unsound. Adding unsoundness for the sake of pushing a feature out is just bad. It's cutting corners on essential things. > they also could have said "ship it" True. But if I know that BDFL is an asshat, then I avoid that project.
  - steveklabnik 6y ago
    There is a difference between saying "I believe new features should have proofs of soundness before landing" and saying that developers are "unprincipled." The former is a specific technical critique, the latter is an insult directed at the people making decisions. Specific technical critiques are great. Suggesting a lack of principle from the developers is not. Here's why this matters. This response from you is much better! Because: > If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation. Yes. Everyone agrees, in principle, that Rust being sound is an important property. Your criticism isn't actually about principles, it (appears to me, anyway) that it is about the specific methods in which we figure out if something is sound or not. You can argue that nothing should be added without formal proof, and that's a fine position to take, but at least it is a specific, actionable criticism that can be discussed directly. By this standard, virtually all languages have "unprincipled" designers. This isn't even true of only async! We didn't (and still sort of don't) have a formal model of the borrow checker. So you can't really criticize async specifically in this way, you'd have to criticize the entire language.
    - Ygg2 6y ago
      > the latter is an insult directed at the people making decisions The way I see unprincipled is two fold: 1) You're breaking your promise 2) In a similar situation behave differently 1) Pin was a problem from the start. Allowing it into std/core was a mistake. The fact they allowed an almost blatantly unsound feature is unprincipled. I'm not 100% sure of the timeline, but near or before the release there were examples floating of a possible Pin unsoundness. And defense was, it's an obscure thing, no one would really use that in practice. The moment designer says, no one would use that in practice, is the moment they lost. 2) Yeah, I get async was a feature everyone wanted. By same measure, why not add self-referential struct. People want it. It's probably unsound but you can't tell. Maybe there exist a model that allows self-referntial structs. Similar situation, different behavior
      - steveklabnik 6y ago
        Nobody promised full formal specifications before landing features. The pin soundness issue was found close to release, but a plan was made to fix it before it was released. Pin is not fundamentally unsound. People do want it, and in fact, it is part of async, and directly related to the soundness issues you’re complaint about. The reason such things aren’t in stable is that, while people do want it, people wanted async more, and did the work. The work has to happen, features don’t just magically come into existence.
ChrisSD 6y ago
The only unresolved soundness issue for Pin that I can find seems to only affect nightly not stable. https://github.com/rust-lang/rust/issues/68015 https://github.com/rust-lang/rust/issues/68015 It doesn't appear to be unresolvable.
- Ygg2 6y ago
  I never said they were unresolvable. I'm glad they are resolvable. But what if the issue was unresolvable? Rust would either have to rollback a feature or basically say, we're sound, except for that part.
carols10cents 6y ago
You don't have to use async if you don't want to.