3 ms·

Not sure who pushed async Rust, but at least async JS does work without having to hunt down for runtimes, and naturally the answer is always Tokio.

by pjmlp 8mo ago

VorpalWay 8mo ago
Usually the answer is embassy for me. And embedded systems vastly outnumber classical computers. Every classical computer includes several microcontrollers, every car, modern appliance, camera, toy, etc does too. Safe languages for embedded and OSes is very important. Rust just happens to be pretty good for other use cases too, which is a nice bonus. But that means the language can't be tied to a single prescribed runtime. And that it can't have a GC, etc.
- pjmlp 8mo ago
  PTC and Aicas would disagree there. As might microEJ, Meadows, F-Secure, Astrobe and a few others.
  - VorpalWay 8mo ago
    > PTC and Aicas would disagree there. Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.
    - pjmlp 8mo ago
      They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades. I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.
      - VorpalWay 8mo ago
        Java on smartcard etc is a thing. I haven't met anyone who used that and actually like it. And it is apparently nothing like normal java. Many microcontrollers are indeed still running C, but things are starting to change. Esperif has official support for Rust for example, and other vendors are experimenting with that too. Many other microcontrollers have good community support. > if there is Rust support, most likely only no_std fits, thus no async anyway. This is just plain incorrect. The beauty of async in rust is that it does work on no_std. You don't need an allocator even to use Embassy. Instead becuause async tasks are perfectly sized, you can reserve space statically at compile time, you just need to specify with an attribute how many concurrent instances of a given task should be supported.
        pjmlp 8mo ago
        PTC and Aicas aren't Java on smartcards, they are Java on high integrity computing where human lives might be at stake. Interesting how compiler specific extensions are ok for C, with a freestanding subset, or Rust no_std, but when it goes to other languages it is no longer the same. I stand corrected on async Rust then.
        VorpalWay 8mo ago
        > Interesting how compiler specific extensions are ok for C, with a freestanding subset, or Rust no_std, but when it goes to other languages it is no longer the same. Not sure what you mean here. For Rust there is only one de facto compiler currently, though work is ongoing on gccrs (not to be confused with rustc_codegen_gcc, which only replaces the llvm backend but keeps the rest of the compiler the same). Work is also ongoing on an official spec. But as it currently stands there are no compiler specific extensions. If you meant the attribute I mentioned for embassy? That is just processed by a rust proc-macro, similar to derives with serde is used to generate (de)serialisation code. It too adds custom attributes on members.
        pjmlp 8mo ago
        It means that being constrained to C compiler dialect for tiny CPUs instead of ISO C proper, or being constrained to [no_std] instead of the whole Rust capabilities and ecosystem, isn't seen under the same light as when it is C++, Swift, Go, Java or whatever else might also be constrained for the same purpose.

Not sure who pushed async Rust, but at least async JS does work without having to hunt down for runtimes, and naturally the answer is always Tokio.

by pjmlp 8mo ago

Not sure who pushed async Rust, but at least async JS does work without having to hunt down for runtimes, and naturally the answer is always Tokio.

VorpalWay 8mo ago

Usually the answer is embassy for me. And embedded systems vastly outnumber classical computers. Every classical computer includes several microcontrollers, every car, modern appliance, camera, toy, etc does too. Safe languages for embedded and OSes is very important. Rust just happens to be pretty good for other use cases too, which is a nice bonus. But that means the language can't be tied to a single prescribed runtime. And that it can't have a GC, etc.

pjmlp 8mo ago
PTC and Aicas would disagree there. As might microEJ, Meadows, F-Secure, Astrobe and a few others.
- VorpalWay 8mo ago
  > PTC and Aicas would disagree there. Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.
  - pjmlp 8mo ago
    They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades. I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.
    - VorpalWay 8mo ago
      Java on smartcard etc is a thing. I haven't met anyone who used that and actually like it. And it is apparently nothing like normal java. Many microcontrollers are indeed still running C, but things are starting to change. Esperif has official support for Rust for example, and other vendors are experimenting with that too. Many other microcontrollers have good community support. > if there is Rust support, most likely only no_std fits, thus no async anyway. This is just plain incorrect. The beauty of async in rust is that it does work on no_std. You don't need an allocator even to use Embassy. Instead becuause async tasks are perfectly sized, you can reserve space statically at compile time, you just need to specify with an attribute how many concurrent instances of a given task should be supported.
      - pjmlp 8mo ago
        PTC and Aicas aren't Java on smartcards, they are Java on high integrity computing where human lives might be at stake. Interesting how compiler specific extensions are ok for C, with a freestanding subset, or Rust no_std, but when it goes to other languages it is no longer the same. I stand corrected on async Rust then.
        VorpalWay 8mo ago
        > Interesting how compiler specific extensions are ok for C, with a freestanding subset, or Rust no_std, but when it goes to other languages it is no longer the same. Not sure what you mean here. For Rust there is only one de facto compiler currently, though work is ongoing on gccrs (not to be confused with rustc_codegen_gcc, which only replaces the llvm backend but keeps the rest of the compiler the same). Work is also ongoing on an official spec. But as it currently stands there are no compiler specific extensions. If you meant the attribute I mentioned for embassy? That is just processed by a rust proc-macro, similar to derives with serde is used to generate (de)serialisation code. It too adds custom attributes on members.
        pjmlp 8mo ago
        It means that being constrained to C compiler dialect for tiny CPUs instead of ISO C proper, or being constrained to [no_std] instead of the whole Rust capabilities and ecosystem, isn't seen under the same light as when it is C++, Swift, Go, Java or whatever else might also be constrained for the same purpose.