An Intern's Experience with Rust

Depends on what you're doing, doesn't it? If you're using Rust for its original design-goal purpose—as a systems language—then you're probably writing some kind of daemon that keeps persistent in-memory state between RPC requests from clients; or some kind of UNIX-ish CLI tool that reduces over IO streams. And as soon as a request, or a stream event, wants to persist some state into a longer-lived scope, lifetimes rear their head.

This turned out to be quite challenging in Rust, even when starting from a working single threaded server. Threading the needle on borrows was quite a challenge.

This is one of the hardest parts about writing examples: you want something that's real, but also not long. Very difficult.

Worst thing ever. I was trying a gfx-rs example to do some drawing. One smallish function took another function as a parameter (a closure actually) so they just wrote an entire drawing function inline. The pipes helped clue me in that something strange was going on.

My own code pulled that function out into a clean definition eventually. As it should have been in example code.

It's not in the name of conciseness. Not sure what it is, but it's not that.

And what I realized was that, as fashionable as it is to say these days that imperative code is the devil, Rust's (deeply) const-by-default local variables remove one of the main reasons people have for nesting their expressions inline: avoiding the creation of state that has the chance to be mutated. And I also found that giving names to those intermediate steps can really help improve legibility. For me, Rust has made imperative code cool again, while also allowing for maximally expressions-based code (even more than JS in some ways!) where it makes sense.

Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, so why would be expect it to have C-like speeds? Should we not also expect C to have compile speed improvements in that period, which might leave them relatively unchanged with respect to each other?

It feels sort of like you're comparing a Mercedes sedan and Land Rover. Both very capably vehicles, but targeted to excel in slightly different circumstances, and when people suggest a Land Rover for rougher terrain, you're noting that when they can provide the same acceleration and gas mileage as the sedan then you'll be interested, which is both unlikely to happen and missing the point, since an off-road vehicle can do things a sedan just can't. Preferring one over the other is fine, expecting one to be superior to the other in every way is a tall order.

One of the main reason we stopped using C++ is because Rust compiles much faster than clang. That was 3 years ago, and in this time frame Rust has improved compile-times significantly (e.g. reductions of ~30% per year).

There are only three (or is it four?) rules about when you can elide. Personally? I never write lifetimes, and then the compiler yells at me, and then I fix it by adding them. It's not something that you need to actively think about. You see

    error[E0106]: missing lifetime specifier
     --> src/lib.rs:2:8
      |
    2 |     x: &i32,
      |        ^ expected lifetime parameter

It's the same with Rust ownership and lifetimes. C programmers know the concept of ownership, but don't have to be rigorous about it. They can use `char *` for both owned and borrowed stings, and make a mess of them (using `need_to_free_that_pointer: bool` as a crutch). When Rust has owned String and borrowed str, it's a surprise.

Sure, there's syntax to learn, and it has a few obscure bits if you're into generic programming. But the fighting with the borrow checker Rust is infamous for comes from using a C mindset of "will it crash or leak?" rather than "is this owning or borrowing?".

Yes, Rust is a very symbol rich language, but it also is very information dense which makes it easier to read than many other languages once you learn it.

I think it looks awesome. Pattern matching, short keywords, types on the right... It accomplishes this beauty while also carrying lifetimes, pointer types, and traits. I personally like it much better then Java or similar static typed languages.

You can't compare it to a scripting language because it has type information.

Like, to me, the human language of Vietnamese looks like a mess of accents, and I'm baffled by why they're necessary. But I'm not a fluent speaker of Vietnamese; and I can imagine that, for someone who is fluent in Vietnamese, and another sibling language like Chinese, maybe the extra accents actually compare very well and help readability compared to e.g. the reduced set of accents in Chinese pinyin.

Likewise, I would suspect that for someone fluent in both C++ and Rust (i.e. someone who knows how to write code that takes advantage of arcane language features in both), Rust might be more readable than C++ because of some of the initially-offputting syntax, whereas C++ might seem less readable because it eschews extra syntax in favor of using template constructors for everything.

I think this is more a problem with what you're used to. You see the same criticisms of every language: Basic dialects are too wordy, Lisp dialects too bracketty, C dialects too symbolly, etc. etc. It's hardly the measure of a language.

Python on the other hand is awesome, and I also begun looking at Go which seem to be quite okay.

The only exception is the method::<Type>() that's sometimes necessary.

When I write or read rust code the symbols just sort of disappear.

I find Rust readability a mixed picture. Being a Rust novice I sometimes find the details hard to follow precisely (as in: I often wouldn't be able to reproduce the code without error myself). But the type system, stdlib & generics make it sufficiently expressive that it's usually pretty easy to understand broadly how things work. In my journey so far I've been able to follow large library codebases more easily than in other languages I've used.

Rust seems anecdotally better at onboarding new engineers than C/++. We're going to start seeing more articles like this.

Rust can express ownership and lifetime of objects statically at compile time, as opposed to dynamically at run time. For beginners this is a new aspect of programming they need to learn, and it adds to the learning curve (same as you need to think about types in C++, instead of winging it in JavaScript), but it has very nice side benefits:

• Deterministic destruction. You don't need to remember about closing handles/cleanups, and all things are freed immediately when their scope ends (rather than "finalized" sometime later). Some languages have `defer` or `withFoo(callback)` to handle these. In Rust it's automatic and more flexible.

• Ownership adds useful information to the program. You know which args will be kept or shared, so you don't get shared mutable state by accident. Libraries don't have to copy their args just in case the caller changes them unexpectedly later. And as a caller you know what each function does to the data you pass in.

The last point is especially useful for passing buffers around, because you control at all times when you give exclusive or shared access, and how long each part of the program can keep them.