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.
> 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.
That argument doesn't hold up. Adding `#[tokio::main]` is opting in because it is that extra something that has to be done. Adding that line is opting in to the multithreaded runtime.
> 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.
I am eager to see what comes of tokio-uring, though. Especially if someone comes up with a good API for reads using shared buffer pools... that one might cause API changes everywhere.
> 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.
Honestly I don't think every user want top notch throughput when writing asynchronous Rust applications. Most users would just want the correctness of the Rust type system, and its "lightweight" runtime characteristics compared to CPython, Node.js etc., which can provide fairly good performance.
The thing is, using Arc in single threaded runtime does not greatly harm performance. If it matters, you should be handling 1M+ rps per core and using multithreaded runtime because it scales better, which benefits from using threadsafe primitives.
Yew (and comparable Rust frameworks) do however have a pretty slow compile time and with that a horrible debug-cycle. It's so bad that I in general opt for React-in-Yew for prototyping and only reimplement components with more complex state in Rust.
Not likely. The only thing that really matters to me is developer ergonomics. I've never seen a project struggle because it couldn't render a table with a 1,000 rows fast enough. I have seen many projects struggle because they hired a bunch of junior engineers who had difficulty writing clean, maintainable JavaScript.
Rust and WASM will definitely take on for doing things like WebGL. I can't imagine Rust becoming the de-facto solution for building UIs.
Author here. I've been working on-and-off on Ratel (JS parser/compiler toolchain) and earlier this year Lunarity (Solidity parser). Both projects share a lot of architecture, as one might expect, with lexers I've built for them being both an object of pride (because they were so fast) and shame (because they were so ugly). It seems I'll be working on more parsers in the future, so having that ugliness abstracted out behind an auto-magical derive macro seemed like a good idea.
So, today, after getting a PR for Lunarity that migrates its lexer to Logos coming up green, I'm happy enough with the crate to start talking about it. There are still kinks to iron out, docs to write, and it might need a blog post or some such, but right now I'm happy.
TL;DR: Here is a crate I wrote that allows you to quickly make a Lexer that reads source code at ~1GB/s on a 2016 i7 laptop.
I think you are also misjudging the effects, and to talk about ability is harmful to the very debate. There are some differences in ability, but they seem to even themselves out (men are better at mental rotation, women have better visual memory, etc.), the total effect on general intelligence appears to be none.
However, there are measurable psychological differences when it comes to preference of the role you want to take, how much risk you are willing to take, and what your priorities regarding status and family are, and we do have evidence that some of it is, at least partially, biological.
Not slow compared to what? Creating elements with the DOM API is faster than innerHTML roughly by a factor of 4 on Chrome Canary last I benchmarked it, DOM mutations with bindings are even faster. There is a reason why React switched from innerHTML to generating DOM.
> The author is amazingly willing to accord French bureaucrats the right to regulate the cultural consumption of Frenchmen. How is this defensible?
By the virtue of those bureaucrats being democratically elected officials responsible to implement the will of said Frenchmen.
Not to say that the situation is perfect, but while there are many things wrong with Europe, but the democracy does work better than it does in the States.
