3 ms·

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 t

by 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.)

by arlort 2y ago

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.)