6 ms·

The Rust community makes a car: "Check out our awesome new car! It makes driving 'easy and safe'!" "Does it prevent crashes?" "No, that's impossible! But her

The Rust community makes a car: "Check out our awesome new car! It makes driving 'easy and safe'!" "Does it prevent crashes?" "No, that's impossible! But here, look at our onboard computer that prevents many types of driving errors." I like Rust. I want it to succeed. But I think the rhetoric gets ahead of the language sometimes, and not prioritizing higher level concurrency tools because you have the borrow checker is a mistake.

steveklabnik 11y ago
> not prioritizing higher level concurrency tools because you have the > borrow checker is a mistake. Ahh, but to mix up your analogy here, the borrow checker is the engine, and the higher level tools are like building fancier cars. You have to get your foundations built before you can build higher-level things on top of them. Now that we have a foundation, these things are starting to appear. See https://news.ycombinator.com/item?id=10131429 https://news.ycombinator.com/item?id=10131429, for example.
- acconsta 11y ago
  In general, there are many reasons (fragmentation, quality, portability, dependency management, compiler support) it's preferable to have concurrency tools standardized. Standardization is only going to get harder in the future. Specifically, it's great that Rust has a capable atomics library. I'm sure we'll see many good concurrent data structures come from it. But that's not quite what I meant by concurrency tools. The thread primitives Rust offers are the same ones POSIX standardized twenty years ago. It would be very valuable to have something like OpenMP (parallel loops, etc.) and something for concurrent IO (either asynchronous or coroutine-based). There's no reason Rust can't have the performance of C++ and the easy concurrency tools of Go or Erlang.
  - Manishearth 11y ago
    >It would be very valuable to have something like OpenMP (parallel loops, etc.) and something for concurrent IO (either asynchronous or coroutine-based). https://crates.io/crates/mio https://crates.io/crates/mio for the async IO. There was another library out there that provided tons of concurrency utilities, but I can't find it now. Parallel loop-like syntax should be easy with scoped_threadpool and a macro though. Rust tries to avoid stuffing everything into the standard library. So the lack of utilities in the stdlib isn't an artifact of some ignorance of concurrency, it's because Rust doesn't want to keep everything in the stdlib. Rust keeps the basic framework for thread safety in the stdlib (though it doesn't need to, not exactly), but the rest is built upon by the community.
    - acconsta 11y ago
      >Rust tries to avoid stuffing everything into the standard library That's a valid philosophy, but also one that leads to problems with fragmentation, quality, portability, dependency management, and compiler support. Concurrent IO is surely important enough to standardize.
      - burntsushi 11y ago
        > That's a valid philosophy, but also one that leads to problems with fragmentation, quality, portability, dependency management, and compiler support. No, not necessarily. We would like for the standard library to remain minimal, but one of its important functions is to collect common interfaces to maximize interoperability between crates. This has worked well in practice so far. Similarly, the standard library provides portable facades on top of platform specific APIs, for example, for performing IO. Crates can take advantage of this so that they can be portable themselves. Moreover, crates themselves can also provide portable facades over platform specific APIs, so I'm not convinced that this will be a problem in practice. Dependency management is handled quite well by Cargo. It has been a wonderful tool to have at our disposal and is really the crux of what makes a small standard library possible. Compiler support is a good argument, but one that I hope becomes weaker in time as we stabilize more functionality. To be clear, I agree that a small standard library has its own downsides. In particular, quality is IMO on of the best arguments against a small standard library. Fortunately, we trying to mitigate this by adopting officially blessed libraries into the `rust-lang` organization: https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... --- This allows us to avoid the problems with a big standard library (too much stuff that is hard to evolve because of stability) while still providing quality with crates that we promise to maintain.
        15155 11y ago
        > so I'm not convinced that this will be a problem in practice. Historically, it's been a massive problem. See my other post. Rust is already seeing IO-related fragmentation. C, C++, Ruby, Python, etc. are all massively-fragmented ecosystems regarding IO, concurrency, (safe) parallelism. I don't think we need to soil a great language (Rust) with these same mistakes.
  - steveklabnik 11y ago
    We do have libraries for asynchronous io, and co routines, they're just not ready yet. I absolutely agree with you that these things are useful, but the code needs to be written by someone. We're just at the stages where these things are getting good enough to try out. (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.)
    - acconsta 11y ago
      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."
kibwen 11y ago
It's incorrect to say that Rust hasn't prioritized higher-level concurrency tools. Many of the design decisions over the previous years have been made with an eye towards supporting every concurrency paradigm. For example, here's a post of Niko Matsakis' from Feb 2014 about changing a fundamental aspect of the borrow checker in order to better support data parallelism in the future: http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust-rfc-stronger-guarantees-for-mutable-borrows/ http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust... For another example, here's an RFC from Nov 2014 about fundamentally altering Rust's concurrency support in order to better support fork-join parallelism in the future: https://github.com/rust-lang/rfcs/blob/master/text/0458-send-improvements.md https://github.com/rust-lang/rfcs/blob/master/text/0458-send... I'm also confused about your perception that the rhetoric gets ahead of the language. The type system does indeed make things easier and safer. When people ask what that means, we're eager to elaborate on the precise guarantees that Rust provides. Misleading people as to Rust's capabilities is not on the agenda.
- acconsta 11y ago
  >It's incorrect to say that Rust hasn't prioritized higher-level concurrency tools I think it's a fair characterization given 1.0 shipped without them, and there doesn't seem to any timeline for standardization (please correct me if I'm wrong). I don't think I have to tell you that concurrency is one of the most important challenges in modern programming. But all Rust gives you today (and for the foreseeable future) is a pthreads wrapper. >I'm also confused about your perception that the rhetoric gets ahead of the language The parent comment says verbatim "Rust goes out of its way to make it easy and safe to write multithreaded code". This apparently doesn't include preventing deadlocks, a problem that is common, hard-to-avoid, and difficult to recover from. Does that not strike you as a bit of an overreach?
  - the_why_of_y 11y ago
    > deadlocks, a problem that is common, hard-to-avoid, and difficult to recover from Deadlocks are by far the easiest concurrency problem to debug, since it's very obvious when your program is deadlocked, and in most cases a stack trace of the involved threads is sufficient to debug and fix a deadlock. Also, if your program is deadlocked it won't corrupt user data. Rust's std::sync::Mutex is fortunately non-recursive, which makes it easier to find deadlocks during testing. Data races are far worse since they may cause arbitrary effects at a later point in program execution, so they take a lot of developer time to track down and very likely lead to data corruption.

steveklabnik 11y ago

> not prioritizing higher level concurrency tools because you have the > borrow checker is a mistake. Ahh, but to mix up your analogy here, the borrow checker is the engine, and the higher level tools are like building fancier cars. You have to get your foundations built before you can build higher-level things on top of them. Now that we have a foundation, these things are starting to appear. See https://news.ycombinator.com/item?id=10131429 https://news.ycombinator.com/item?id=10131429, for example.

acconsta 11y ago
In general, there are many reasons (fragmentation, quality, portability, dependency management, compiler support) it's preferable to have concurrency tools standardized. Standardization is only going to get harder in the future. Specifically, it's great that Rust has a capable atomics library. I'm sure we'll see many good concurrent data structures come from it. But that's not quite what I meant by concurrency tools. The thread primitives Rust offers are the same ones POSIX standardized twenty years ago. It would be very valuable to have something like OpenMP (parallel loops, etc.) and something for concurrent IO (either asynchronous or coroutine-based). There's no reason Rust can't have the performance of C++ and the easy concurrency tools of Go or Erlang.
- Manishearth 11y ago
  >It would be very valuable to have something like OpenMP (parallel loops, etc.) and something for concurrent IO (either asynchronous or coroutine-based). https://crates.io/crates/mio https://crates.io/crates/mio for the async IO. There was another library out there that provided tons of concurrency utilities, but I can't find it now. Parallel loop-like syntax should be easy with scoped_threadpool and a macro though. Rust tries to avoid stuffing everything into the standard library. So the lack of utilities in the stdlib isn't an artifact of some ignorance of concurrency, it's because Rust doesn't want to keep everything in the stdlib. Rust keeps the basic framework for thread safety in the stdlib (though it doesn't need to, not exactly), but the rest is built upon by the community.
  - acconsta 11y ago
    >Rust tries to avoid stuffing everything into the standard library That's a valid philosophy, but also one that leads to problems with fragmentation, quality, portability, dependency management, and compiler support. Concurrent IO is surely important enough to standardize.
    - burntsushi 11y ago
      > That's a valid philosophy, but also one that leads to problems with fragmentation, quality, portability, dependency management, and compiler support. No, not necessarily. We would like for the standard library to remain minimal, but one of its important functions is to collect common interfaces to maximize interoperability between crates. This has worked well in practice so far. Similarly, the standard library provides portable facades on top of platform specific APIs, for example, for performing IO. Crates can take advantage of this so that they can be portable themselves. Moreover, crates themselves can also provide portable facades over platform specific APIs, so I'm not convinced that this will be a problem in practice. Dependency management is handled quite well by Cargo. It has been a wonderful tool to have at our disposal and is really the crux of what makes a small standard library possible. Compiler support is a good argument, but one that I hope becomes weaker in time as we stabilize more functionality. To be clear, I agree that a small standard library has its own downsides. In particular, quality is IMO on of the best arguments against a small standard library. Fortunately, we trying to mitigate this by adopting officially blessed libraries into the `rust-lang` organization: https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... --- This allows us to avoid the problems with a big standard library (too much stuff that is hard to evolve because of stability) while still providing quality with crates that we promise to maintain.
      - 15155 11y ago
        > so I'm not convinced that this will be a problem in practice. Historically, it's been a massive problem. See my other post. Rust is already seeing IO-related fragmentation. C, C++, Ruby, Python, etc. are all massively-fragmented ecosystems regarding IO, concurrency, (safe) parallelism. I don't think we need to soil a great language (Rust) with these same mistakes.
- steveklabnik 11y ago
  We do have libraries for asynchronous io, and co routines, they're just not ready yet. I absolutely agree with you that these things are useful, but the code needs to be written by someone. We're just at the stages where these things are getting good enough to try out. (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.)
  - acconsta 11y ago
    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."

kibwen 11y ago

It's incorrect to say that Rust hasn't prioritized higher-level concurrency tools. Many of the design decisions over the previous years have been made with an eye towards supporting every concurrency paradigm. For example, here's a post of Niko Matsakis' from Feb 2014 about changing a fundamental aspect of the borrow checker in order to better support data parallelism in the future: http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust-rfc-stronger-guarantees-for-mutable-borrows/ http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust... For another example, here's an RFC from Nov 2014 about fundamentally altering Rust's concurrency support in order to better support fork-join parallelism in the future: https://github.com/rust-lang/rfcs/blob/master/text/0458-send-improvements.md https://github.com/rust-lang/rfcs/blob/master/text/0458-send... I'm also confused about your perception that the rhetoric gets ahead of the language. The type system does indeed make things easier and safer. When people ask what that means, we're eager to elaborate on the precise guarantees that Rust provides. Misleading people as to Rust's capabilities is not on the agenda.

acconsta 11y ago
>It's incorrect to say that Rust hasn't prioritized higher-level concurrency tools I think it's a fair characterization given 1.0 shipped without them, and there doesn't seem to any timeline for standardization (please correct me if I'm wrong). I don't think I have to tell you that concurrency is one of the most important challenges in modern programming. But all Rust gives you today (and for the foreseeable future) is a pthreads wrapper. >I'm also confused about your perception that the rhetoric gets ahead of the language The parent comment says verbatim "Rust goes out of its way to make it easy and safe to write multithreaded code". This apparently doesn't include preventing deadlocks, a problem that is common, hard-to-avoid, and difficult to recover from. Does that not strike you as a bit of an overreach?
- the_why_of_y 11y ago
  > deadlocks, a problem that is common, hard-to-avoid, and difficult to recover from Deadlocks are by far the easiest concurrency problem to debug, since it's very obvious when your program is deadlocked, and in most cases a stack trace of the involved threads is sufficient to debug and fix a deadlock. Also, if your program is deadlocked it won't corrupt user data. Rust's std::sync::Mutex is fortunately non-recursive, which makes it easier to find deadlocks during testing. Data races are far worse since they may cause arbitrary effects at a later point in program execution, so they take a lot of developer time to track down and very likely lead to data corruption.