I think whether to deeply integrate concurrency into a framework or not is quite an interesting tradeoff. Without a preferred concurrency solution (like Swift, C++, Java, ...) users of the language are can leverage from a lot of different concurrency solutions, from real threads to eventloops&#x2F;Rx and everything in between. However I think in the meantime that this hurts the ecosystem around the language. When some libraries built around primitive 1 (which might require an eventloop or async&#x2F;await) and others around primitive 2 (M:N scheduled fibers) these libraries might not be easily combinable in your application. Languages with a preset solution (like Go or Erlang) avoid this problem.