I'd like to hear something like "This is how our team used Rust to do (really hard thing involving heavy concurrency and lots of state)". From someone not involved with the development of Rust.

I was recently looking at a large, non web related C++ program which needs to be made multi-thread to increase capacity. I realized that if it was in Rust, it would be much easier to break out functionality into another thread. You need to classify data as immutable, locked, or unshared to make the program multi-thread. Rust has language support for that. C++ does not.

I'm still learning the language, so I haven't touched the "fearless concurrency" stuff, but so far it's looking very good.

~30% CPU time, 1-5% RAM use at peak; compared to the JVM.

I plan on writing about it, and open-sourcing the code (both Kotlin and Rust repos). Chasing a hectic work deadline at the moment.

Our team uses Rust for moderately complex concurrency.

TL;dr: There are tradeoffs, but Rust can be quite nice when you care about performance.

In my experience, concurrency is actually pleasant in Rust. The borrow checker eliminates 99% of problems before they ever occur. As for libraries, the popular crossbeam library provides scoped thread pools, which make it easy to spin up a bunch of local worker threads. https://docs.rs/crossbeam/0.3.2/crossbeam/struct.Scope.html#... For "parallel iterators", Rayon is excellent. https://github.com/rayon-rs/rayon For async I/O, the tokio library still demands solid Rust skills (at least until Rust 2018 lands), but once you figure it out, it Just Works. https://tokio.rs/

As for our other experiences using Rust:

- Rust is amazing for fast, cross-platform CLI tools.

- For most kinds of programs, I barely notice the borrow checker any more. But this is partly because I don't write programs with giant webs of objects that all try to mutate each other (like some game engines, for example). Also, I've never needed to implement a non-hierarchical data structure in Rust (the gory details of which are described at http://cglab.ca/~abeinges/blah/too-many-lists/book/), mostly because anything I needed was already on crates.io.

- Library support is much better than I would expect for a young language, but I do occasionally find myself overhauling the guts of an AMQP library or something. This costs me maybe a week or two per year?

Flavor-wise, Rust feels like a simpler C++ without the sharp edges or footguns. It has much better package-management tools. Safe Rust code doesn't have data races or buffer overflows. If you fuzz Rust code, the worst that will normally happen is a controlled panic caused by an invalid array index.

But Rust is going to be more challenging to somebody who has never thought about stack allocation versus heap allocation, or who has never written "my_list.map(some_function)". And sometimes the type names can get a bit hairy, if somebody uses too many parameterized types.

But overall, I'm really enjoying Rust at work. It's basically the language I spent the entire 90s desperately wanting, back when performance was always a big deal.

`impl Trait` just landed in stable! I think the most interesting use cases (putting an impl Trait in a struct) aren't stable yet? But the basics are working great.

Maybe you will find you want here if you didn’t know this website already.

https://hn.algolia.com/?query=rust&sort=byPopularity&prefix&...

https://www.ponylang.org/

Glad you liked TRPL! I agree that some of the examples can be too abstract at times, it’s tough. Totally open issues if you want to talk about it; I’m open to improving things, but I’m also pretty particular about the book.

What about Automatic Reference Counting a la Swift / Objective-C?

Seems like a nice blend: compiler assisted, much less runtime overhead than traditional garbage collection, simple programming model.

While this is an honest comment, why and how can you be critical of a language you don't know. Skeptical sure, but critical?

1. The parent didn’t say if they compiled with optimizations. I bet they did, as the code would probably look even worse without, but who knows.

2. This isn’t apples to oranges, as you’re not doing formatting here, right?

3. The formatting code makes various trade offs; it’s not optimized for speed, more for size, in my understanding.

4. Codegen bugs do happen. Maybe this is a degenerate case.

In general, if the code is significantly worse, then it’s a bug.

    use std::io::{self, Write};

    fn main() -> io::Result<()> {
        io::stdout().write(b"hello world")?;

        Ok(())
    }

AFAIK (not too familiar with rust or c++), you can do something like this:

    if (Maybe may = whatever; may.issome)

  if let Some(x) = y {
      println!("y has a value, {}", x);
  }

  if y.is_some() {
      println!("y has a value, {}", /* uh… */);
  }

  pub fn is_some(&self) -> bool {
      match *self {
          Some(_) => true,
          None => false,
      }
  }

Furthermore, the field of programming is so vast that it's unreasonable to expect someone to know every nuance of a given language, especially if it's one that they don't use heavily.

So I don't think there's any good reason to dismiss the whole article as nonsense.