7 ms·

>Rust is targeting more than one domain. Concurrent IO is not important in all domains. Well, what domains is Rust targeting? Rust still isn't a good fit for e

>Rust is targeting more than one domain. Concurrent IO is not important in all domains. Well, what domains is Rust targeting? Rust still isn't a good fit for embedded/kernel stuff without allocators and OOM handling (not to mention every architecture not targeted by LLVM). That leaves userland applications, and how many applications don't need concurrent IO? I'm definitely being impatient, and I'm sorry for that. It's just frustrating to see only one core member working on it.

dbaupp 11y ago
The standard library is different to the language itself: the language certainly doesn't disallow allocators/OOM handling, it's just the design of std. Furthermore, the standard library is layered: there's `std` with various OS-required routines (IO, etc.) and `core` that is the core stuff that doesn't require any of that. Operating systems/embedded applications can generally use `core`. However, even that is better than C/C++, where one usually has a from-scratch "standard" library (which is possible to do with Rust too): not being able to use the compiler-bundled `std` doesn't seem like a point against Rust. Many user-space applications don't do heavy network work, which is where concurrent IO is most necessary. E.g. games or a scientific simulation, even web-browsers don't need of concurrent IO (they're not trying to juggle thousands of connections).
- acconsta 11y ago
  >Operating systems/embedded applications can generally use `core`. Which doesn't, correct me if I'm wrong, provide a stable allocator API or OOM handling yet. >E.g. games When your client pings 400 servers, how is it doing that? How is the game server implemented? >a scientific simulation That runs on one machine, and doesn't do a lot of disk IO? (concurrent file IO matters too). >even web-browsers Open the Chrome dev tools "network" tab, and then open Gmail. How many requests did it make? Again, concurrent IO is important.

dbaupp 11y ago

The standard library is different to the language itself: the language certainly doesn't disallow allocators/OOM handling, it's just the design of std. Furthermore, the standard library is layered: there's `std` with various OS-required routines (IO, etc.) and `core` that is the core stuff that doesn't require any of that. Operating systems/embedded applications can generally use `core`. However, even that is better than C/C++, where one usually has a from-scratch "standard" library (which is possible to do with Rust too): not being able to use the compiler-bundled `std` doesn't seem like a point against Rust. Many user-space applications don't do heavy network work, which is where concurrent IO is most necessary. E.g. games or a scientific simulation, even web-browsers don't need of concurrent IO (they're not trying to juggle thousands of connections).

acconsta 11y ago
>Operating systems/embedded applications can generally use `core`. Which doesn't, correct me if I'm wrong, provide a stable allocator API or OOM handling yet. >E.g. games When your client pings 400 servers, how is it doing that? How is the game server implemented? >a scientific simulation That runs on one machine, and doesn't do a lot of disk IO? (concurrent file IO matters too). >even web-browsers Open the Chrome dev tools "network" tab, and then open Gmail. How many requests did it make? Again, concurrent IO is important.