8 ms·

Wait, what? What happened to "fearless concurrency"? I thought this was supposed to be one of the borrow checker's selling points! https://blog.rust-lang.org/2

• steveklabnik 6y ago
  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.
  • btrask 6y ago
    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-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
    • sanxiyn 6y ago
      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?
      • jen20 6y ago
        > Why wouldn't you use threading? Because the C10^nK problem where n increases periodically is still a thing?
        • btrask 6y ago
          Green threads.
          • coolreader18 6y ago
            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
        • sanxiyn 6y ago
          I am not solving C10K problem.
      • darthrupert 6y ago
        Because you cannot win artificial benchmarks with threading.
    • steveklabnik 6y ago
      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.
      • btrask 6y ago
        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?"
        • steveklabnik 6y ago
          Regarding your edit 2, I linked two talks I have that go over this in great detail elsewhere in this thread.
        • dwoot 6y ago
          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 https://www.youtube.com/watch?v=lJ3NC-R3gSI 2. The Talk You've been Await-ing for - https://www.youtube.com/watch?v=NNwK5ZPAJCk 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
        • ragnese 6y ago
          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.
• timClicks 6y ago
  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.
  • mratsim 6y ago
    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.
    • steveklabnik 6y ago
      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.