exomancer · HackerTrans

2 ปีที่แล้วdiscuss

FWIW the pervious Polish government modeled its state capture after Hungary quite openly. They quite miraculously lost the elections after a major mobilization (historic attendance of over 74%), and have now been stripped of funding due to illegally using state funds during their campaign in 2023. This was possible in Poland because, unlike Hungary, Poland still had free (non-state) mainstream media, and not for the lack of trying.

exomancer

3 ปีที่แล้วdiscuss

> It is opt-in. If you're using Tokio then you can specify whether you want to use a single-threaded or multi-threaded runtime. Multi-threaded is "default" in the sense that if you just use `#[tokio::main]` then you get a multi-threaded runtime but you can also just do `#[tokio::main(flavor = "current_thread")]` to get a single threaded executor.

Doing something extra to get a behavior different than default is the definition of opt-out my friend.

exomancer

3 ปีที่แล้วdiscuss

> Also, IMO it's relatively easy to use Send-bounded future in non-Send(i.o.w. single-threaded) runtime environment, but it's almost impossible to do opposite. Ecosystem users can freely use single threaded async runtime, but ecosystem providers should not.

We have Send and non-Send primitives in Rust for a reason. You could use Arc/Mutex/AtomicUsize/... everywhere on a single thread, but you should use Rc/RefCell/Cell<usize>/... instead whenever possible since those are just cheaper. The problem is that in the ecosystem we are building the prevailing assumption is that anything async must also be Send, which means we end up using Send primitives even in non-Send contexts, which is always a waste.

> If you want every users to only use single threaded runtime, it's a major loss for the Rust ecosystem.

Running single threaded executors does not prohibit you from using threads, it just depends on how you want to do that. You can:

1. Have a single async executor running a threadpool that requires _everything_ to be Send. 2. Have a single threadpool, each thread running its own async executor, in which case only stuff that crosses thread boundaries needs to be Send.

The argument is that there are many scenarios where 2 is the optimal solution, both for performance and developer experience, but the ecosystem does not support it well.

comments