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

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.

I’ve never in my life used JS, so I’ll have to take your word for it.

It's a language I'm familiar with that uses the `await foo` syntax and often will see more than one in a line, per the examples given. C# is the most prominent language that has similar semantics that I know well, but is usually less of an issue there.

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.

The postfix macro does sound like a better solution tbh. Did you write the static assertions crate? If so, thank you. I’m a daily user.

Ha, no, I did not write that crate. I think my use of this username probably predates rust, certainly that crate.

Postfix macros had some very tricky issues and it would have delayed things a lot to figure out the right resolution.

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() ```

Two spaces before a line make it a code block literal

  This is a code block

HN has never used markdown so the triple-tick does nothing but create noise here.

Thnaks for heads up, I'll keep this in mind in the future.

This hasn’t been true for some months. Claude has gotten better about adding latest versions of crates, and when it does encounter a breaking change from what it expects it is usually very quick about finding the change in the docs or crate source code.

What you are talking about used to be a pain point, but is now pretty much gone.

Rust can be a real superpower for AI-assisted dev work, because the compiler outputs very good errors, and the type system catches most safety bugs.

My release code uses `git rev-list --count $tag` to output the release number.

git rev-list --count HEAD

svn was absolutely in common use for a lot more than 2 years. I would totally believe that cvs was still in wider use though as there was sooo much legacy software hosted on it.

Their marginal inference cost is less than what they charge for it. Normally that is considered profitable...

Apple's built-in virtualization framework. For macOS guests, tart is probably the best out there. Apple's own `container` CLI tool for linux/docker-like containers.

brew install tart

That may be the intent, but it is very anti-science.

Partial disclosures are actively pro-science.

Evidence that a hard problem is solvable, and information on solution characteristics, are a big help to others.

Even non-disclosure is just science-neutral, not anti-science.

Partial disclosures are common where disclosures involve risky things, or where a problem was solved as part of an economic concern. But there are non-conflicting opportunities to partially inform others.