exomancer

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.

> 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.

Fair enough, I've only seen the one benchmark I've linked.

Rust already has [React-like web framework](https://github.com/yewstack/yew) with a macro for [declarative components](https://github.com/yewstack/yew/blob/ce020d6eb8409b2063cc150...) that compiles to wasm and, last I checked, [runs circles around JS frameworks](https://github.com/DenisKolodin/todomvc-perf-comparison).

I agree that it won't reach the popularity levels of JS due to the learning curve, but on technical side of things future is _now_.

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.