111–120 of 136 posts
Earlier quoted context omitted.
Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available. If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.
Because he is talking about massive concurrency, not embedded or wasm or other contexts where there not be as many resources available.
> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…
> > The problem is that threads just don’t work in practice for massive concurrency. > That's an assumption that is repeated very often recently, and measured very rarely. I would go further--there is a whole infrastructure that needs to appear when massive concurrency is involved and very few times is that taken into account. For those people interested in genuine massive concurrency, I encourage people to investiga…
Re concurrency. I learned Erlang before Akka. It took me a bit but I find Akka more ergonomic. Akka will easily handle millions of actors on a single machine, too. But I always miss matching on binaries.
Another good one is protoactor for golang. That will also do a million actors no problem. Comes really close to Erlang in terms of how concise the syntax is. But again, no binary matching.
Earlier quoted context omitted.
I'm aware of the history there. I think the decision not to ship a builtin async runtime was probably correct. I also think shipping async syntax sugar and allowing people to build their own custom runtimes is just fine. I just think that the cultural decision in the wider ecosystem to make, practically speaking, everything io related, async is possibly a mistake.
Well I think it happened because a large number of Rust committers, core-devs doubled down on multi-year Rust async effort. What larger ecosystem would take away from this? IMO the message was Async is the future so everyone better hop on this train.
Earlier quoted context omitted.
Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available. If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.
Embedded is much less likely to need async in the first place at all.
Earlier quoted context omitted.
What happens if you need to do computational work on a go routine? Isn’t that going to block the carrier thread and then murder throughput?
Yes, you have to manually insert yield points. Exactly the same as with every cooperative threading system, including Lunatic and Rust's native async/await. Kind of feels like we need user space preemptive threading somehow.
Earlier quoted context omitted.
Seems like Rust is better in every way right? I can't help but wonder why is it that Go is so much more popular when it comes to language of choice for networked and multi-threaded applications.
It's not better in every way at all - it is more flexible. I regularly bounce between Go and Rust in different contexts.
Earlier quoted context omitted.
What happens if you need to do computational work on a go routine? Isn’t that going to block the carrier thread and then murder throughput?
Yes, you have to manually insert yield points. Exactly the same as with every cooperative threading system, including Lunatic and Rust's native async/await. Kind of feels like we need user space preemptive threading somehow.
Async rust lets you implement different combinators on async tasks and cancel them effortlessly.
As for performance, tokio is not exactly a zero cost abstraction. Just run perf on a tokio program to see how big of overhead it introduces. It has claimed to be zero cost from the start, and since then it has done at least two major performance overhauls, to prove the point. That being said I love tokio and its ecosystem, but it is ergonomics, not speed that I love. That being said async-std was much slower for the networking use case that I had, so overall tokio is as good as it gets.
For me async is about ergonomics first of all. When you perform parallel tasks on multiple threads it is hard and ugly (in cross platform Rust at least) to implement any sort of intricate cross communication, as communication between threads is asynchronous by nature. And it is very much impossible to stop a thread externally. Async rust lets you implement different combinators on async tasks and cancel them effortle…
For me async is about ergonomics first of all. When you perform parallel tasks on multiple threads it is hard and ugly (in cross platform Rust at least) to implement any sort of intricate cross communication, as communication between threads is asynchronous by nature. And it is very much impossible to stop a thread externally. Async rust lets you implement different combinators on async tasks and cancel them effortle…
Why do you say async-std is so much slower? If there any result or report shows that? I'm also curious about the `perf` you mentioned.