4 ms·

As I mention in replies to sibling comments, Go works that way: every function is a Future, and there is no such thing as a non-async function. It works pretty

• skavi 2y ago
  A great bit about Rust async is that it’s sufficiently flexible for use in embedded environments. I would really not prefer a Rust that includes a more intrusive runtime. Especially given the API changes things like io-uring may require to exploit. As it works now, I can nearly always predict what assembly I’ll see when I compile a Rust program. It’s predictable enough to work anywhere C does. I would hate to lose that.
• arlort 2y ago
  The other comment implied it but I think it's worth pointing out that: > embedded applications that can't have asynchronous execution Is most definitely not the case. They can't have the same type of async runtime that would be optimal for a web server or the likes (and I'm not sure all desktop applications and web servers are going to always benefit from the same runtime in the same way), but that's a point in favour of Rust's model imho If you're interested this is an embedded async runtime that's expected to run in no-std and no-alloc environments https://embassy.dev/ https://embassy.dev/
  • adastra22 2y ago
    "embedded applications *that* can't have asynchronous execution" not "embedded applications can't have asynchronous execution" there are embedded applications that are compiled with no concurrency runtime. I'm not saying all embedded applications work this way.
    • arlort 2y ago
      Yeah, I think I added a comma while reading by mistake so I thought the "that" was preceding the explanation of why you singled out embedded, my bad The point about a runtime optimized to run bare metal on a single core probably being suboptimal on a desktop machine with 8 cores still stands though. (And the laptop one is possibly not going to work optimally on a server with hundreds of core either)
    • Dylan16807 2y ago
      I'm still skeptical that such a thing exists. A concurrency runtime doesn't have to be much more than a queue of function calls. What kind of hardware can run normal code but can't do that?
      • adastra22 2y ago
        Interrupt handlers, for example.
        • saagarjha 2y ago
          Depending on your implementation it is very possible to schedule interrupt handlers into a concurrent runtime. You'd have to be exceptionally careful about how it was designed with regards to, like, reentrancy, but Rust is quite good at encoding these kinds of things.
        • Dylan16807 2y ago
          An interrupt handler could schedule an asynchronous task just fine. In a lot of situations that would be a very good way to handle things. You shouldn't await in an interrupt handler, but there's a lot of things you shouldn't do in an interrupt handler. A rule like that doesn't mean you need a noasync mode. (And if you really wanted to use await there, you could make it work with priorities or with a separate task queue.)
• saagarjha 2y ago
  No, the reason this doesn't work for Rust (and even more so Swift) is that they need to call code that is not annotated. In Go the runtime knows what blocks and what doesn't, and this lets it effectively manage its thread pool based on the state of every goroutine. If you call outside of your runtime, you lose guarantees about what that code might do: it could block indefinitely or deadlock some other code in your program. Solving this is a pretty hard problem, which is why the solutions these languages have designed are limited. (Again: Swift ships with its own runtime; there is a default "executor". It doesn't actually solve this problem for the reasons I described.)
• pkolaczk 2y ago
  > It works pretty well and is super easy to use and reason about, with no hard edges. Oh,rly? https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf