![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/1f7e5534-88d3-4d6f-bc57-7cda9553890f.webp)
I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async
thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.
I think I would put the emphasis slightly differently: I don’t feel the confusion is around the word “spawn”, but it spawns futures rather than tasks. For tasks you might indeed expect them to be picked up in the background (which is what work-stealing does), but futures only execute when polled.