4 ms·

>your apparently-perfect channels I've never used Go, but it has some interesting concurrency ideas. So do Node and Erlang. I naively expect Rust to adopt the

>your apparently-perfect channels I've never used Go, but it has some interesting concurrency ideas. So do Node and Erlang. I naively expect Rust to adopt the best ideas from each. >One can use channels to get all four of the conditions required for a deadlock, especially Go's synchronous-by-default channels. One can, yes. But it's pretty easy to avoid cyclic locking patterns when each request is handled by a separate goroutine, as is idiomatic. One thread per request in Rust will drag pretty quickly. Yes, the borrow checker is an impressive achievement. But is it enough for Rust to succeed? Marketing yourself as safer C++ is what Java already did (with tremendous success) 20 years ago. And the market for systems languages has only shrunk since then (my phone runs Java). >All the languages you mention are quite opinionated in their concurrency, imposing costs that Rust doesn't and can't, for its target space. And yet Rust has already partially standardized channels. Finish the channels, add coroutines and you've implemented Go! (I'll note there are already coroutine implementations for C and C++, which do not limit their use as systems languages). >(And, Go certainly doesn't provide any guarantees at all, not even data race freedom.) Which, interestingly, hasn't hindered its ability to become a successful language! A lesson worth remembering. >Wrong, it's very much on the roadmap, e.g. Alex Crichton (core team member) has been adding windows support to mio himself. I mean... https://github.com/carllerche/mio/graphs/contributors?from=2015-05-15&to=2015-09-09&type=a https://github.com/carllerche/mio/graphs/contributors?from=2... Could be worse, could be better? >Why is this particular pet feature any more important than everyone else's pet feature? I don't think "good concurrency is a pet feature" is the winning argument here. >I'm pretty confident that Rust can easily be much better (i.e. more performant and reliable) than both Node and Go and even Erlang. Me too! But I'm not sure that's going to happen with a single core developer on Mio and no timeline for standardization.

kibwen 11y ago
> I've never used Go, but it has some interesting > concurrency ideas. So do Node and Erlang. I naively > expect Rust to adopt the best ideas from each. This is where your naivete shows. Rust originally did have the same thread model as Go baked into the language and standard library, and it labored for years to find a usable compromise between Go's green thread model and the native threading model. And a compromise is indeed necessary, firstly because we don't just need another Go, and secondly because Go's threading model imposes horrific costs when trying to interoperate with non-Go code (literally thousands of times the overhead that you'd expect). For a language like Rust that intends to interoperate with the native ecosystem, that overhead is unacceptable. After about three or four complete redesigns and rewrites the entire green threading infrastructure was chucked to the curb. Fortunately, Rust is low-level enough that libraries like mio can pick up the slack on their own, and in the meantime libraries that don't need green threads don't have to pay the price.
- acconsta 11y ago
  >Rust originally did have the same thread model as Go baked into the language and standard library Ehhhhhh not quite. Go provides one threading API, and it's green threading. Rust tried to provide the both green threading and native threading using identical APIs. That was a unique and in retrospect quixotic decision. Most of the problems identified in the RFC stem from the unified API issue: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... I also understand Rust's implementation was backed by libuv, which, being designed for Node, was a poor fit for Rust: https://plus.google.com/+nialldouglas/posts/AXFJRSM8u2t https://plus.google.com/+nialldouglas/posts/AXFJRSM8u2t You're the third person in this thread to tell me that Go-like concurrency requires a big runtime, and it remains false. Here are analogous concurrency implementations in C and C++: http://libmill.org/tutorial.html http://libmill.org/tutorial.html http://www.boost.org/doc/libs/1_59_0/libs/coroutine2/doc/html/coroutine2/motivation.html http://www.boost.org/doc/libs/1_59_0/libs/coroutine2/doc/htm... And because of that fallacy, the future of concurrency in Rust is a one-man show, third party library. It's a tremendous loss.
  - dbaupp 11y ago
    The same approach can and does exist in Rust too, e.g. https://crates.io/crates/mioco https://crates.io/crates/mioco . (Concurrency in C and C++ is also third-party libraries... The whole point of languages like Rust and C++ is that powerful functionality like this can be built externally, so that different trade-offs can be made. Languages like Go and Node force one approach, and so when you need something outside it, you're forced to do something suboptimal.)
    - acconsta 11y ago
      >The same approach can and does exist in Rust Without the documentation, stability, portability, quality guarantees, and compiler support (that's a big one — code generation for coroutines needs to be good) of a standard library. >Concurrency in C and C++ is also third-party libraries C++ is on track to standardize concurrent file and network IO. Draft specifications have already been published, and Microsoft shipped coroutines in VS 2015. It would be a damn shame if C++ got concurrent IO before Rust. I would like to use Rust professionally, and I'm sure you do/would as well. But no one can possibly sell their boss on using a project with a single part time maintainer to provide critical functionality.

kibwen 11y ago

> I've never used Go, but it has some interesting > concurrency ideas. So do Node and Erlang. I naively > expect Rust to adopt the best ideas from each. This is where your naivete shows. Rust originally did have the same thread model as Go baked into the language and standard library, and it labored for years to find a usable compromise between Go's green thread model and the native threading model. And a compromise is indeed necessary, firstly because we don't just need another Go, and secondly because Go's threading model imposes horrific costs when trying to interoperate with non-Go code (literally thousands of times the overhead that you'd expect). For a language like Rust that intends to interoperate with the native ecosystem, that overhead is unacceptable. After about three or four complete redesigns and rewrites the entire green threading infrastructure was chucked to the curb. Fortunately, Rust is low-level enough that libraries like mio can pick up the slack on their own, and in the meantime libraries that don't need green threads don't have to pay the price.

acconsta 11y ago
>Rust originally did have the same thread model as Go baked into the language and standard library Ehhhhhh not quite. Go provides one threading API, and it's green threading. Rust tried to provide the both green threading and native threading using identical APIs. That was a unique and in retrospect quixotic decision. Most of the problems identified in the RFC stem from the unified API issue: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... I also understand Rust's implementation was backed by libuv, which, being designed for Node, was a poor fit for Rust: https://plus.google.com/+nialldouglas/posts/AXFJRSM8u2t https://plus.google.com/+nialldouglas/posts/AXFJRSM8u2t You're the third person in this thread to tell me that Go-like concurrency requires a big runtime, and it remains false. Here are analogous concurrency implementations in C and C++: http://libmill.org/tutorial.html http://libmill.org/tutorial.html http://www.boost.org/doc/libs/1_59_0/libs/coroutine2/doc/html/coroutine2/motivation.html http://www.boost.org/doc/libs/1_59_0/libs/coroutine2/doc/htm... And because of that fallacy, the future of concurrency in Rust is a one-man show, third party library. It's a tremendous loss.
- dbaupp 11y ago
  The same approach can and does exist in Rust too, e.g. https://crates.io/crates/mioco https://crates.io/crates/mioco . (Concurrency in C and C++ is also third-party libraries... The whole point of languages like Rust and C++ is that powerful functionality like this can be built externally, so that different trade-offs can be made. Languages like Go and Node force one approach, and so when you need something outside it, you're forced to do something suboptimal.)
  - acconsta 11y ago
    >The same approach can and does exist in Rust Without the documentation, stability, portability, quality guarantees, and compiler support (that's a big one — code generation for coroutines needs to be good) of a standard library. >Concurrency in C and C++ is also third-party libraries C++ is on track to standardize concurrent file and network IO. Draft specifications have already been published, and Microsoft shipped coroutines in VS 2015. It would be a damn shame if C++ got concurrent IO before Rust. I would like to use Rust professionally, and I'm sure you do/would as well. But no one can possibly sell their boss on using a project with a single part time maintainer to provide critical functionality.