I mean, it is, yes. That post is talking about threads. And the “fearless” name meant that it solves a lot of issues at compile time, which it still does in an async context.

Like any static analysis, it’s a give and take between making sure your analysis is sound, while still allowing useful programs.

Whether it's kernel threads or green threads, the same patterns (locks, etc) are possible. Locks are supposed to be the borrow checker's bread and butter, because it can guarantee they are held before accessing shared state. But now you're saying "the borrow checker makes writing code without [async/await] difficult, inefficient, and unergonomic."

I'm not saying locks are better than async/await (although they are[1]). You're saying the borrow checker itself can't handle them in real world use?

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

I am not saying that the borrow checker cannot handle locks. Locks work great.

(The borrow checker does not understand locks as a special construct, to be extra clear.)

Did you read the post I linked? It lays out the details. I am happy to clarify if you don’t get the specifics.

I see now, I misunderstood your original post. You were saying async/await is necessary because futures work badly, not because all the alternatives (i.e. locks) work badly.

Sorry, my mistake!

Edit to add: futures work badly in every language, so there's no shame in the borrow checker not working with them.

Edit 2: But in that case we're back to "why would Rust want async/await over (potentially green) threads with its first-class support for locks?"

I believe these are the talks from Steve that he's referring to. It was enlightening for me:

1. Rust's Journey to Async/Await - https://www.youtube.com/watch?v=lJ3NC-R3gSI

2. The Talk You've been Await-ing for - https://www.youtube.com/watch?v=NNwK5ZPAJCk

The first video goes into all the bits you're concerned about and all the things that Rust has tried before arriving where they are now

Language support for green threads require a heavier runtime (so you'd pay the performance cost even when you didn't write async code).

Tokio basically is green threads as a library.

Regarding your edit 2, I linked two talks I have that go over this in great detail elsewhere in this thread.

Yes. There are some difficult technical issues. In practice, borrow checker works less well on async code than threaded code.

This is partly why I prefer threading over async in Rust. Look, we went through some enormous effort to make threading good and fun again. Why wouldn't you use threading?

> Why wouldn't you use threading?

Because the C10^nK problem where n increases periodically is still a thing?

I am not solving C10K problem.

Green threads.

Those are async tasks

Or rather -- async tasks are as close as you can get to green threads in rust without a runtime that would impose overhead on every program

Because you cannot win artificial benchmarks with threading.

It's still fearless, as in you don't need to worry that you might create data races, but can be clunky to write in some cases.

If the borrow checker has no representation of a memory model, for example relaxed/acquire/release, you can't write a concurrent queue without triple checking for statement ordering, resulting barriers and then formally verify it otherwise you are very likely to introduce data races.

The borrow checker doesn’t understand orderings, as it doesn’t specifically need to. You can get race conditions, but not data races. Yes, you need to be careful when writing this kind of code.