5 ms·

That's great. I look forward to seeing them evolve and hopefully become standardized. >(And the language can't have exactly the same stuff as Go or Erlang with

That's great. I look forward to seeing them evolve and hopefully become standardized. >(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: http://libmill.org/ http://libmill.org/

burntsushi 11y ago
> 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/ 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 https://crates.io/search?q=coroutine
- acconsta 11y ago
  >That is definitely too much runtime 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."
  - burntsushi 11y ago
    > 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.

burntsushi 11y ago

> 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/ 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 https://crates.io/search?q=coroutine

acconsta 11y ago
>That is definitely too much runtime 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."
- burntsushi 11y ago
  > 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.