>(And the language can't have exactly the same stuff as Go or Erlang without adding a runtime, which is contrary to the goals of the project.)
Here is 90% of what Go gives you as a C library. No heavyweight runtime necessary:
Rust has channels in its standard library. Admittedly, they do not have the same functionality as Go's concurrency primitives. The two most significant omissions are probably a multi-producer/multi-consumer channel and a more complete (and stable) `select` construct.
There is also my `chan` library, which replicates Go functionality with respect to channels: http://burntsushi.net/rustdoc/chan/ --- Notably, you still have to use native threads.
Your `libmill` example is a coroutine library with a scheduler and everything. That is definitely too much runtime for standard Rust. However, there are people working on coroutines in Rust, on which something like `libmill` could be built: https://crates.io/search?q=coroutine
Is it incompatible with native threads? (no) Does it affect non-coroutine functions? (no) Does it have any effect whatsoever when not using the library? (no)
I encourage you to look over the code before dismissing it as "definitely too much runtime."
I encourage you to take a look at ongoing work on coroutines in Rust, which was the part of my comment where I didn't dismiss your point.
I think the portion of my comment you quoted was taken out of context.
(And the language can't have exactly the same stuff as Go or Erlang without adding a runtime, which is contrary to the goals of the project.)