LocalSet is quite frankly a hack, because tokio's multi thread runtime by design needs Send for efficiency.

Also if the futures exposed by a library (public or internal in a larger project) nearly every user will run into issues if they are not Send.

github.com/influxdata/d...

There are companies where I'm excited when they are using my open source code.... and then there are companies for which I would rather burn everything down and become a farmer.

Also eine Art "Fidget Toy" für den Mund? 🤔

In Hamburg hat die Werbewirtschaft erfolgreich ne riesige Aktion gegen die Initiative gefahren, teilweise mit moralisch fragwürdigen Methoden ("hi, ich bin X von der Tafel. Danke , dass es Außenwerbung gibt, sonst könnte ich meine Arbeit nicht machen").

That said, I think your video was good. It shows what you've tried and how you did NOT find a conclusion, something that is super underrepresented. So I think it was good 👍

Color spaces and Co are super confusing and the internet also seems to contain a lot of misconceptions. It's specific to HDR, but I found this video here a good intro:
yedlin.net/DebunkingHDR...

Both could be worked around though using a private helper trait like in github.com/apache/arrow...

Thinking about this more, I think there might be other reasons for these vtables:

1. Trait upcasting isn't stable yet (scheduled for 1.86).
2. Some interfaces like `Clone` aren't dyn safe, so you cannot dyn dispatch through a `Box`/reference.

Well, I'm not actually sure it IS faster. At least I haven't seen a good explanation of why that would be the case.

For example:
- doc.rust-lang.org/std/task/str...
- github.com/tokio-rs/tok...

I've been thinking about vtables recently. Why is a manual implementation that captures function pointers faster than `Box<dyn Trait>`?