The different philosophies of "explicitly annotate async functions" vs "implicit async" vs "create os threads with polling" etc will always continue because the

The different philosophies of "explicitly annotate async functions" vs "implicit async" vs "create os threads with polling" etc will always continue because they all have tradeoffs. So, the "simplification" or a "unification" of a concurrency model always comes at a cost that some programmers don't want to pay. Whenever you see, "Language <X> has solved the color problem so it's not an issue." -- the reflexive skepticism should be, "At what price, and do I want to pay it?" I think it's instructive that Rust had a clean-sheet start to design a new language and so far, they've rejected Go style "channels" as Rust core syntax and instead, adopted the async/await paradigm. You don't have to program in Rust to get the gist of the following previous comments about their thought process: https://news.ycombinator.com/item?id=21475154 https://news.ycombinator.com/item?id=21475154 https://lobste.rs/s/bfsxsl/ocaml_4_03_will_if_all_goes_well_support#c_whrcmk https://lobste.rs/s/bfsxsl/ocaml_4_03_will_if_all_goes_well_... https://lobste.rs/s/y3fsrm/what_is_zig_s_colorblind_async_await#c_wsg7e0 https://lobste.rs/s/y3fsrm/what_is_zig_s_colorblind_async_aw...