Falling in love with Rust (dtrace.org)

I can't denied rust is hard and a lot of time I get lost thinking "why rust don't let me do...". But is truly a good teacher...

I would be interested if they're wrong, hehe

In all fairness... the "carefully implemented C" was all wrapped up as an external lib for the node application they reimplemented so no having to convert values to/from js and deal with all that other stuff.

One thing that we have noticed in our work on our Rust AV1 encoder, rav1e, is that Rust autovectorizes a lot better than C. In particular, it does a better job of proving that slices have nice sizes (e.g., multiples of 8 or 16 elements). That allows it to leave off all of the boilerplate for handling odd sizes. Rust also does not automatically promote every arithmetic operation to an int. That makes working on 8- or 16-bit types a lot more efficient. The stronger type system, memory safety, and the preference for idioms that avoid bounds checks mean the compiler can successfully autovectorize a lot more code than C, too. We used to joke that the only C code that gets autovectorized is the initialization loops that run exactly once and just set everything to zero.

It's still not as good as hand-written SIMD (maybe within a factor of 2), but it's a lot better than no SIMD.

That said, it makes it hard to do straightforward performance comparisons with C, especially for code where you know you will write the hand-written SIMD, but you just haven't gotten to it yet. There is a lot of code like this in a freshly-implemented video encoder. Rust is using a tool, autovectorization, that it won't get to use when you manually vectorize, and C isn't. That threw off a lot of our early attempts at benchmarking Rust vs. C.

Of course, most things are not video encoders, and most code won't be manually vectorized, so the better autovectorization is an absolute win in the real world.

The metric "my naive Rust" vs "my carefully implemented C" might be OK, once you figure out a consistent way to check code passes as "my naive Rust" or "my carefully implemented C".

Until then it's just an anecdote.

Might there be programmers whose "naive Rust" performs a lot worse than their "carefully implemented C"?

Might that be unsurprising to them and uninteresting as a blog post?

I think both languages made the correct decisions for what they're trying to accomplish as a language.

So `foo?.bar` is something like

    match foo {
      Ok(inside_foo) => Ok(inside_foo.bar), // .bar the lambda.
      Err(v) => Err(v),
    }

Iterators are a typical example of this.

vec![0, 1, 2, 3].into_iter() .filter(|x| x % 2 == 0) // Keep the evens .map(|y| y + 1 ) // Add 1 to elements .rev(); // Reverse the iterator

Adding intermediates would just add noise for code like this.

    let sum = vec_of_ints
        .iter()
        .filter(|x| x > 5)
        .map(|x| x.pow(2))
        .take(3)
        .sum()

Consider the imperative code:

    let mut sum = 0;
    let mut n = 0;
    for x in vec_of_ints {
        if x > 5 {
            sum += x.pow(2);
            n += 1;
            if n == 3 {
                break;
            }
        }
    }

  int.__add__(a, b)

  a.add(b)

I'm not a Rustacean - I only speak to the syntax difference.

I wonder what if in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... how about use Rust for most of the UI logic and off-load the final steps for a native layer. I call it a "almost cross-platform" UI.

I've seen promising things about Qt/QML. Qml in particular helps avoid having to deal with lots of C++ interop.

GTK seems to be rallying around Rust, and it actually looks pretty good nowadays. relm is a really interesting elmish wrapper around GTK.

Others have put rust components behind an Electron GUI.

So tl;dr it's quickly moving from "terrible and immature" to "terrible, like other languages".

They made some good decisions like using real native controls and writing it in c to allow bindings to many languages, including 3 for rust. The biggest catch for me is the lack of table controls: https://github.com/andlabs/libui/issues/310

I wish I had a copy (..link) to that article. Byte, Computer Shopper... something like that.

There are a few pieces of code I wrote in the 90's (in C) that I know are still in use and may survive a few more decades; as long and the companies that I worked for at the time are still in operation anyhow.

That said, I can give you at least one thing where Rust needs to, and will be, improving over the next months: the async story is finally settling into place, but hasn’t settled yet. Async/await is coming and will improve things so so much. Right now things are a bit boiler-platey, and you can’t always write what would be equivalently idiomatic to the sync code. See here: http://aturon.github.io/2018/04/24/async-borrowing/

> This book digs into all the awful details that are necessary to understand in order to write correct Unsafe Rust programs. Due to the nature of this problem, it may lead to unleashing untold horrors that shatter your psyche into a billion infinitesimal fragments of despair.

It's surprising how many things in that book don't have anything to do with unsafe per se. It's just that, when you can't rely on the inference system to "do the right thing", you now have to actually think about subtype variance and the order that destructors run in, instead of letting the compiler worry about all that bookkeeping.

Try writing some Rust, it will surprise you in a few ways. These are not warts (though there are some), but more features of the language. For some these features, move-by-default, single-mutable-reference, strongly-typed-errors, they will be struggles to deal with initially.

It's a language that restricts you in many ways, and this is startling for many. It was for me for sure.

My two major pain points in Rust are (1) the compile times, (2) the high variance of quality in the ecosystem.

The compiler for Rust is very slow, it takes minutes to build software from scratch. Things are getting better with incremental compilation, but it's definitely not as fast as D or Go to compile, and that can be very grating during development.

Anyone can easily contribute to the crates ecosystem and post their libraries and programs to crates.io. Unfortunately, there is no real way to know what's production-quality and what's a toy. You can try and rely on the number of downloads, the names of the contributors, etc., but there is no system that tells you what other Rustaceans think of a crate. For instance, I tried using an HTTP client with few dependencies (because the most downloaded option, reqwest, has a lot of dependencies), but I found that (a) the library issued a read(2) syscall for each byte that it downloaded, (b) did not always return the full payload for HTTPS. There was no way I could tell from just looking at the crates.io page.

- Type inference pretty much being killed by method calls. For instance, code like this won't work:

    fn x() -> Vec<i32> {
        let mut x = (0..3).collect();
        x.sort(); // Calling any method of Vec
        x // Cannot infer that `x` is `Vec<i32>` because a method was called
    }

- Negative modulo follows C semantics. This means `-2 % 12` is `-2`, not `10`. There is a sane implementation in `mod_euc` method, but it's not the default.

- Lexical lifetimes reject code that should be valid necessitating weird workarounds. NLL will fix that one.

- Trait objects types used to be written using a trait name like `Display`. There is a new syntax which is more clear: `dyn Display`, but for backwards compatibility reasons the old syntax is accepted.

- Macros (including procedural derives) cannot access private items in a crate, requiring workarounds like exporting private items in a crate, and having `#[doc(hidden)]` attribute to hide them from documentation.

- Trait version incompatibility issue. That one is weird, but essentially it's possible for a program to have two versions of the same library. It's possible for a library to say, have a function that requires an argument implementing `Serialize` interface from serde 0.9. If you try to implement `Serialize` interface from serde 1.0 then you will get an error message complaining about not implementing `Serialize`, despite you having implemented it, just in the wrong version of a library.

- Missing higher kinded polymorphism.

- Missing const generics.

- The compiler is slow. Like, really slow.

- The language is hard to learn because of many complicated features like ownership and borrow checking. That said, I think those features are a good thing, I'm missing those in other programming languages, but they are problematic when you are learning the programming language.

But really, there is much more I would complain about in other programming languages, so it's not that bad.

Good IDE support, with autocomplete and integrated debugging, was also missing but that should have improved i believe?

awk, vim, whatever Dos 3.1 GUI the guys at B&H use to fulfill my orders, why shouldn't I expect to be using these programs in 50 years? They solve a problem and work every time.

*BSD, vim, Emacs, Perl, C, Apache & Linux in some way, gcc, the GNU userland, Air company & banks infrastructure come to mind, and they still do the work.