[mplanchard]

Some of the burnout no doubt being due to the catastrophizing of every decision by the community and the extreme rhetoric used across the board.

Great to see people wanting to get involved with the project, though. That’s the beauty of open source: if it aggravates you, you can fix it.

[selfhoster1312]

As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from.

Retrospectively, i think everyone is satisfied with the adopted syntax.

[zozbot234]

It makes sense that there was a huge debate, because the postfix .await keyword was both novel (no other languages had done it that way before) and arguably the right call. Of course, one can argue that the ? operator set a relevant precedent.

[jurgenburgen]

> Retrospectively, i think everyone is satisfied with the adopted syntax.

Maybe it’s a case of agree and commit, since it can’t really be walked back.

[diondokter]

Various prominent people have said years after that .await was the correct choice after all

[steveklabnik]

I was initially very against postfix await and I was wrong. It's great.

[staticassertion]

I'm not prominent but I disagreed with it at the time and I was wrong.

[adastra22]

I’m curious - why were you wrong? It still seems like a wart to me, all these years later. What am I missing?

[tracker1]

Contrast it with async in JS/ES as an example... now combine it with the using statement for disposeAsync instances.

    await using db = await sqlite.connect(await ctx.getConfig("DB_CONN"));

It's not so bad when you have one `await foo` vs `foo.await`, it's when you have several of them on a line in different scopes/contexts.

Another one I've seen a lot is...

    const v = await (await fetch(...)).json();
    

Though that could also be...

    const v = await fetch(...).then(r => r.json());

In any case, it still gets ugly very quickly.

[fluffybucktsnek]

I'll give my two cents here. I work with Dart daily, and it also uses the `await future` syntax. I can cite a number of ergonomic issues:

```dart (await taskA()).doSomething() (await taskB()) + 1 (await taskC()) as int ```

vs.

```rust taskA().await.doSomething() taskB().await + 1 taskC().await as i32 ```

It gets worse if you try to compose:

```dart (await taskA( (await taskB( (await taskC()) as int )) + 1) ).doSomething() ```

This often leads to trading the await syntax for `then`:

```dart await taskC() .then((r) => r as i32) .then(taskB) .then((r) => r + 1) .then(taskA) .then((r) => r.doSomething()) ```

But this is effectively trading the await structured syntax for a callback one. In Rust, we can write it as this:

```rust taskA(taskB(taskC().await as i32).await + 1).await.doSomething() ```

[staticassertion]

I was a proponent of the postfix macro solution. `.await!` or `.await!()`, essentially. The idea was that this could be generalized, it was closer to existing syntax, etc.

I was worried about features that I still don't love like `.match` etc (I'm more open to these now).

Post-fix macros would have been very complex. Scoping alone is complex.

`.await` kinda just works. It does everything you want and the one cost is that it looks like a property access but it isn't. A trivial cost in retrospect that I was a huge baby about, and I'll always feel bad about that.