4 ms·

If only rust had concurrency / parallel programming primitives or library as nice as golang or elixir,i think i'll move to this language right away. For now i'm

• Ar-Curunir 10y ago
  Isn't the point of Rust to enable easy concurrency?
  • bsaul 10y ago
    I think it's to enable safe concurrency. The problem is they decided to let others build the primitives for concurrency, on top of the stdlib. Which means the language didn't decide between actor vs futures vs coroutine vs event loop, etc..
    • pcwalton 10y ago
      > Which means the language didn't decide between actor vs futures vs coroutine vs event loop, etc.. Having the language decide on one method of concurrency would make it useless for lots of people's purposes (including ours).
      • stshine 10y ago
        On the other hand, since these methods are not compatible it will create certain split in the ecosystem.
        • msbarnett 10y ago
          Those splits are inevitable. There is no One Size Fits All concurrency primitive. Embedded devs and web devs have vastly different requirements. Either the split is "every use-case finds the primitive that works best for it" (Rust), or the split is "here's the blessed primitive, other use-cases can pound sand" (Go)
        • Manishearth 10y ago
          Must it? In fact, I'd expect the reverse -- choosing a model for the language will make the ecosystem tied to that model For example, while tokio is being integrated with hyper, it does not affect the "usual" users of hyper at all, both in terms of API and in terms of what's going on under the hood, cost-wise. Having a blessed solution for async like tokio that is not in the stdlib seems to encourage folks to integrate with it, but not in an irrevocable manner; the core library stays intact and able to support potential other models in the future.
          • stshine 10y ago
            Sure, I do hope we can focus on one concurrency primitive, but the possibility that we may have async/await and coroutine at the same time seems kind of unfortunate to me.
            • Manishearth 10y ago
              AFAICT async/await the way Rust intends to have it (plans are rough right now) basically coroutines with extra sugar to specialize it with futures. The core language won't know about event loops, it will just know about futures, and you wire up your async/await or whatever to the event loop yourself. As both in the context of concurrency will involve futures they will probably work well together.
              • stshine 10y ago
                I'd love to see this goes well with highest performance.
                • Manishearth 10y ago
                  AFAICT It's all going to be a generator-like abstraction which is pretty zero-cost.
                  • stshine 10y ago
                    The real world is always more complicated, since cps carries stack in its arguments.
    • Ar-Curunir 10y ago
      Hmm. I guess the community will eventually decide on one particular primitive, hopefully soon.
      • Manishearth 10y ago
        I don't think it's a good idea for Rust to choose a particular kind of concurrency primitive. Rust is pretty broad in its use cases, and choosing a primitive may end up restricting other fields. Remember that Rust used to have a libuv based green threading model, and it was removed for precisely this reason -- it affected some use cases in major ways. Rather, it is important for subcommunities to rally around particular sets of libraries. E.g. the web and I/O related libraries seem to all be going in the direction of integrating with tokio. This means a web programmer can use tokio and it will work smoothly. OTOH, a different subcommunity that uses a different set of libs may use stuff built on rayon and crossbeam.
        • Ar-Curunir 10y ago
          That's fair; it allows for lots of flexibility.
        • deleted 10y ago
          [deleted]
        • deleted 10y ago
          [deleted]
      • bsaul 10y ago
        I hope the same, but i don't have great hopes. For a community to adopt a library as fundamental as this one would be, it would need to be of such a high level that i think only the language designer can create it ( or other really big names in the field). If you think of something like OTP, i don't see any equivalent anywhere else. Even akka isn't unanimously used as the foundation for server side dev on the jvm.
        • steveklabnik 10y ago
    • Lev1a 10y ago
      If I remember right, Rusts approach for their stdlib is that the bare minimum is actually in there and everything else is to be supplied by libraries, like the getopts crate that was split from the stdlib AFAIK.
      • steveklabnik 10y ago
        Generally speaking, yes. This is driven by three things, largely: Rust has a very wide variety of use-cases, we don't want to stabilize a poor API forever, and Cargo exists and works well.
    • mtanski 10y ago
      Problem? The goal of Rust is to be a general system programing language. In fact, Rust in the past had a runtime that included green threads a primitives; that ended up being a problem. The runtime and stdlib was only usable in some system programing task (defeating the whole goal).
• tupshin 10y ago
  while it's still in early days, keep you eye on the tokio project https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio which looks to be the foundation for higher level activity in this area
  • bsaul 10y ago
    I did have a look at it. I think the initiative is great, but i don't like the idea of basing concurrency on async io primitives. I like the idea of actors or coroutine better, because it lets you code in a synchronous manner, and make concurrency block a little coarser and more manageable... Maybe i didn't understand everything on this project though, so please correct me if i'm wrong.
    • Manishearth 10y ago
      Rust may eventually get async/await syntax that works with futures so coroutine-based programming would be easy to do, regardless of whether or not it is backed by an event loop like tokio or something else. I'm not sure I get your point here, from other comments it seems like you're annoyed that Rust didn't choose a solution, and when tokio (which is the "chosen" solution for server side async stuff) is talked about you wish it had chosen a different one. As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming.
      • stymaar 10y ago
        > As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming. Since he mention Go and Erlang, I think what the gp just wishes Rust had a built-in solution for M:N threading. Whether M:N threading is nicer than async APIs is highly subjective though. (I'm talking about ergonomics here. I think it's widely accepted that async is more efficient when performance really matters)
• Manishearth 10y ago
  Tokio/futures is going to be the "blessed" way of doing async IO (the way its done in server side apps). That should be ready sometime this year. It won't be in the stdlib but it will be integrated with most of the I/O related libraries in the ecosystem and the Rust team is involved in making it happen. It seems like you're talking specifically about async I/O here? Because Rust does have parallel programming primitives both in the stdlib and in the form of libraries like rayon and crossbeam. Rayon, in particular, is amazing for parallel programming.
• ekidd 10y ago
  I think some of issue here is that when you ask for "concurrency / parallel programming primitives", you're actually talking about more than one problem. We can divide things up as follows: - Data parallelism. This is where you have (for example) a giant array of data to process and want to use as many cores as possible. For this, rayon is gorgeous: https://github.com/nikomatsakis/rayon https://github.com/nikomatsakis/rayon Seriously, I can just not say enough good things about programming with rayon, and how nice Rust's "no mutable aliasing" makes coding. Also at some point, Rust will also need good libraries for talking to the GPU. - I/O concurrency. This is where you have a server that needs to respond quickly to 10,000+ sockets, for example. For this, it looks like everyone is standardizing on futures and tokio: https://github.com/alexcrichton/futures-rs https://github.com/alexcrichton/futures-rs https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio But it seems like you're most interested in Erlang-style actors with M:N green threads? The issue here is that—as best I remember the history of Rust—the Rust maintainers decided that green threads were simply too high a level of abstraction for Rust. I think Rust will eventually move back in that direction, first using futures+tokio+async I/O, and then by eventually adding async/await sugar on top. That way, you'll only pay for coroutines/green threads when you explicitly opt in. But it will take a year or so for all this to start maturing, I think. In the meantime, tokio's method-chaining syntax should actually be somewhat tolerable, especially because Rust has a `#[must_use]` attribute that prevents you from forgetting to use a future. If you're lazy, just run everything through rustfmt to get the indentation right.
  • steveklabnik 10y ago
    > as best I remember the history of Rust There's an RFC for that! https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... (A reminder that this was written in 2014, so statements are about Rust at that time period) > I think Rust will eventually move back in that direction Note that tokio is not "green threads" as they're conventionally thought of, though they are similar if you squint, kinda.
    • ekidd 10y ago
      > Note that tokio is not "green threads" as they're conventionally thought of, though they are similar if you squint, kinda. Well, I'm leaping ahead to the end of the story, here, and speaking far too loosely about technical details. ;-) Futures + tokio + a possible future async/await proposal would provide a reasonable enough syntax for actors/coroutines in Rust, I suspect.