Rust concepts I wish I learned earlier (opens in new tab)

You do get better about using the functional operators as you use them, and they can be incredibly powerful and convenient in certain operations, but in this case he's missing the simplest implementation of this function using the `?` operator:

    fn add2(x: Option<i32>, y: Option<i32>) -> Option<i32> {
        Some(x? + y?)
    }

TLDR; learning Rust through canonical code in tutorials often requires the student to learn bits about the language that are more advanced than the actual problem the resp. tutorial tries to teach how to solve in Rust. ;)

I prefer the latter now that I understand how all the Result/Option transformations work. As a beginner this would be hard to read but the former looks clunky.

Clippy also got pretty good lately at suggesting such transformations instead of if... blocks. I.e. I guess that means they are considered canonical.

In general I find canonical Rust often more concise than what a beginner would come up with but it does require deeper understanding. I guess this is one of the reasons why Rust is considered 'hard to learn' by many people.

You could actually teach Rust using pretty verbose code that would work but it wouldn't be canonical (and often also not efficient, e.g. the classic for... loop that pushes onto a Vec vs something that uses collect()).

I'd probably write this

    fn add(x: Option<i32>, y: Option<i32>) -> Option<i32> {
        match (x, y) {
            (Some(x), Some(y)) => Some(x + y),
            _ => None,
        }
    }

I think the idiomatic way to write that is:

  fn add(x: Option<i32>, y: Option<i32>) -> Option<i32> {
      Some(x? + y?)
  }

> Do folks really prefer the latter example? The first one is so clear to me and the second looks inscrutable.

Literally everything in programming is inscrutable until you learn it the first time. The latter should be trivial to understand for anyone who's spent even a little amount of time in a language with functional elements.

A day-one beginner doesn't understand a `for` loop. You probably think they're trivial. Bitwise operations are the same. They might be new to you, but `zip` and `map` frankly don't take much more effort to understand than anything else you probably take for granted. `zip` walks through everything in two separate wrappers and pairs up each element inside. `map` opens up a wrapper, lets you do something with what's inside, and re-wraps the result.

For instance, you can do the exact same thing with arrays. Pair up each element inside (like a zipper on clothing), then for every element inside, add them together:

    [1, 3].zip([4, 1]).map(|(a, b)| a + b ) # [5, 4]

That said, you can write this specific function even simpler:

    Some(x? + y?)

The latter is a lot clearer and simpler. The former requires me to reason about control flow, if, and early return, a whole bunch of magic concepts. The latter is just an expression made of normal functions; I could click through and read their implementation if I was confused.

Both are rather ugly. This is much more idiomatic:

    match (x, y) {
        (Some(x), Some(y)) => Some(x + y),
        _ => None,
    }

Once you know what map does with an option I'd say it is mostly pretty readable. Basically map (when run against an Option value) is a way to say "if the value passed in has a value run this function on it otherwise return None.

The first one is very clear, I agree. However if I wrote Rust daily, I would probably be familiar with the second one and would prefer it. Here's an article kind of related to that, in this case talking about APL, that I think explains very well the tradeoffs: https://beyondloom.com/blog/denial.html.

To try with my own words: programming is about shared understanding of a problem, but also the tools used to solve the problem. Code is text, text has a target audience. When it is experts you can use more complex words, or more domain-specific words. When it's intended for a wider audience, taking the time to explain and properly define things, sometimes multiple times, can be necessary.

According to Rust's documentation of Some:

> zip returns Some((s, o)) if self is Some(s) and the provided Option value is Some(o); otherwise, returns None

> zip_with calls the provided function f and returns Some(f(s, o)) if self is Some(s) and the provided Option value is Some(o); otherwise, returns None

Using zip_with seems more appropriate (x.zip_with(y, +) or something) but zip_with is nightly. I also don't like how object chaining makes so that x seems more "fundamental", or "in another category" than y and +, while really x and y are the same, and + is something else. The if solution shows clearly that x and y are the same, by treating them exactly the same. The second solution also introduces a and b from nowhere, doubling the number of variables used in the function. All small things, but I think it can help put words on why precisely the second isn't as readable as it may seem.

It's interesting how much can be said about a simple "add" function.

First one isn't idiomatic anyway with return. You can just do Some(x? + y?) though.

Using `zip` feels excessively clever to me. I'd probably prefer something in between, like `and_then` followed by `map`, or just matches.

What’s there to say? It works the same way as `zip` does for an iterator over a `Vec`. So if you understand `zip` as applied to an iterator over `Vec`, then you might understand `zip` applied to `Option`.

In other words:

Y is clear if you already understand X. Like how returning early is simple to understand if you understand if-blocks.

That’s the problem with replying to these kinds of questions: the response is so short and context-dependent that it can look curt.

EDIT: the first code is also inelegant in that it effectively checks if both values are `None` twice in the `Some` case: once in the if-condition and once in `unwrap()` (the check that panics if you try to unwrap a `None`).

Yea the latter code is unreadable to me and feels obfuscated, like the author is trying to force functional programming where it doesn't belong.

I'd prefer a match approach

As someone new to Rust, I look at the latter and see `.zip()` (apparently unrelated to python zip?), and then a lambda/block which intuitively feels like a heavyweight thing to use for adding (even though I'm like 90% sure the compiler doesn't make this heavyweight).

By comparison, the first one is straightforward and obvious. It's certainly kinda "ugly" in that it treats Options as very "dumb" things. But I don't need to read any docs or think about what's actually happening when I read the ugly version.

So TLDR: This reads a bit like "clever" code or code-golfing, which isn't always a bad thing, especially if the codebase is mature and contributors are expected to mentally translate between these versions with ease.

"Eschew flamebait. Avoid generic tangents."

https://news.ycombinator.com/newsguidelines.html

We detached this subthread from https://news.ycombinator.com/item?id=34429403.

Because, what, Python doesn’t have any language details related to method lookup that might require a sentence or two of technical explanation? __getattr__, __getattribute__, __get__, base classes, metaclasses, __mro__, __mro_entries__, __dict__, __slots__, __call__, bound and unbound methods—none of this has ever confused someone looking at it for the first 3–4 times?

I assume you’re going to reply that you don’t need to think about all this when writing most Python. And that’s true of most Rust too. Don’t get me wrong, Rust does have some unique complexity that Rust programmers need to learn in exchange for its unique safety guarantees—but method lookup isn’t where the complexity is.

It’s basically as complicated as “If a subclass and a parent class both define a `bar()` method, and you have an instance of the subclass named `foo`, calling `foo.bar()` will call the subclass version”

I actually find that simpler than some of the spaghettis you can create with Python’s multiple inheritance :P

Those types are wrappers that keep a reference to some data. In any language, it's common to encounter issues when people confuse copying the underlying data with copying just the container around the data and keep pointing to the same thing.

In Python, a list of lists has the same behavior.

    l = [ [ 1, 2, 3 ] ]
    l2 = l.copy()

    l[0][0] = 99

    print(l)  // [[99,2,3]]
    print(l2) // [[99,2,3]]

The complexity exposed by Rust is overwhelming for people that haven't done any low level programming.

It's not just lifetimes, a basic Rust function can expose the ideas of exclusive and non-exclusive ownership, traits, generics with and without trait bounds, algebraic data types, closures, closures that move, async, async blocks, smart pointers, macros, trait objects, etc etc.

There is absolutely a learning curve and it makes me understand why Golang is the way it is. The language authors of Golang saw the business needs of Google, realized that they need to get domain experts that are not programming savants to write code and created a language that would allow the largest number of non programmer domain experts be productive coders.

That being said, the Golang developers went too far and let too many of their biased ideas for what is "simple" infect the language. In what way is it simple for a language to not be null safe. I have a bunch of other complaints too.

But anyway, I don't think Rust is going to be a revolution in writing software unfortunately. I don't think enough people will be able to learn it for companies to be able to hire for Rust positions.

Certainly, many applications don't need this kind of complexity.

But if you're working on one who does, you're typically glad to use Rust :)

Python is not immune to this (for different reasons though)... If you want to be snide online, make sure you're correct first :)

RE: Any article about the GIL

Yeah. Speed and memory efficiency don’t come for free. Use Rust when you benefit enough to compensate for the cost of grokking the plumbing.

Python is not even remotely an option for the sorts of programs Rust is intended for.

Footguns is the exactly what rust doesn't have.

Some might criticise it for forcing you through a complex process to acquire a firearms license, selling you gun with an efficient safety and then insisting that you wear extremely heavily armoured shoes.

I consider footguns to be things that cause me to waste a ton of effort and build architecturally unsound code. The things in the article are actually just basic language concepts you need to understand to be productive.

So to use the foot gun analogy, if you don't know the stuff in the article you wont even be able to pull the trigger.

An actual footgun is something like monkeypatching in python or ruby. Or running for_each with an async callback in javascript.

Now that's a strawman if I've ever seen one.

Quite the opposite. Rust won’t even let you pull the trigger. C++ on the other hand is very much littered with footguns.

> I suspect Rust does not implement as many FP-oriented optimizations as GHC

It's more complicated than this; sometimes FPish code is super nice and easy and compiles well (see the zip example in this very thread!) and sometimes it's awkward and hard to use and slower.

Personally I’ve done a small amount of reading of the Hands On Functional Programming in Rust book. I’ve also found Scott Wlaschin’s F# resources quite transferable (though you may run into some issues with passing async functions around as arguments).

I think proper immutable data structures can be quite fast without sophisticated compiler magic if they are read and cloned often (cloning is an abstraction) and are generally long lived.

Rust makes mutations safe, but immutability has benefits outside of safety.

As I understand it &impl Meower also uses dynamic dispatch, whereas the generic version will generate a specialized version for each concrete type it is called with.

> Universal impl trait arguments can't be turbofished, so you're placing an unnecessary constraint on your caller.

What does this mean?

hah got me there. Content on that topic will be coming soon after this post :). This was my first foray into writing about the language

In addition to containers, it seems to be useful for 'wrapper' types adding decorators to the 'base' object without having to wrap/unwrap the new type in each operation.

Classic OOP would use inheritance to achieve this, while something like Deref allows you to use it with all the added behavior - without losing the possibility to assign to it values of the base type.

Not quite, it doesn’t tell the compiler much about how Foo relates to its bar field unless you also constrain the public API for creating a Foo. If Foo is constructed out of a ‘new’ method with this signature:

    impl<'a, T> Foo<'a, T> {
        pub fn new(bar: &'a T) -> Self {
            Self { bar, _marker: PhantomData }
        }
    }

… AND the bar field is private, then you are ensuring the Foo container doesn’t outlive the original bar pointer. If you don’t constrain creation and access to the bar field then people can just write foo.bar = &new_shorter_borrow as *const T; and then the lifetimes are absolutely unrelated, foo.bar will become invalid soon. A classic example of doing this correctly is core::slice::IterMut, and the slice.iter_mut() method.

A short illustration (note how only one of the Foos creates a compile time error): https://play.rust-lang.org/?version=stable&mode=debug&editio...

A short explanation of what you’re telling the compiler with PhantomData (without accounting for the new method/ constraints on creation) is that Foo appears to have a &'a T field, for the purposes of the outside world doing type and borrow checking on Foo structs and their type parameters. That does two things:

(1) Due to implied lifetime bounds, Foo’s generics also automatically become struct Foo<'a, T: 'a>, so this ensures T outlives 'a. That will prevent you accidentally making Foo<'static, &'b str>.

(2) You don’t have an unused lifetime, which is an error. We always wanted Foo to have a lifetime. So this enables you to do that at all.

Edit: and (3) it can change the variance of the lifetimes and type parameters. That doesn’t happen here.

Hm? `mem::drop` is defined in terms of `Drop`[1].

Are you thinking of `mem::forget`?

[1]: https://doc.rust-lang.org/std/mem/fn.drop.html

There are multiple ways of referring to this stuff.

* mutable/immutable (this is the way the book refers to it and used to be the 'official' terms but I don't know if they've changed that since I left, partially this is the name because you spell it "&mut".)

* shared/exclusive (this is the name that some people wish we had called mutable/immutable, a very very long time ago thing called the "mutapocalypse.")

Both sets are adjectives for "borrow."

I agree with you that "shared borrow" can feel like a contradiction in terms.

In general, they are duals of each other: it depends if you want to start from a place of "can I change this" or "who all has access to this," making each term more clear depending on the perspective you take.

I know, right? It uses way too many styles of brackets (just use the round ones) and puts them on the wrong side of the operator.

The types will be different depending on which operation is used to clone so I wouldn’t really worry about this one too much.

You're right, but for those learning Rust, there's _so much_ to learn, that having occasional reminders of the more basic things is really handy. I've been hobby programming in Rust for years and professionally for about 6 months, and I still picked up one or two simple things from this list.

That doesn't make sense for Rust. Rust's references in function arguments aren't an equivalent of C++ reference arguments.

Rust doesn't reason in terms of by-reference vs by-value passing. It doesn't have pervasive expensive copy constructors that need to be avoided, NRVOs, and things like that.

Rust works in terms of owning and borrowing. Moves have a special case of `Copy` types like i32, but this works only for POD types, is at worst a shallow memcpy, and the types have to opt in to being copyable like that. The default is non-copyable, even for trivial structs and integer enums.

Drawing false parallels with C++'s pointer types is a major source of people fighting the borrow checker. References aren't for not-copying, they're for not-owning. `Box<T>` is a pointer that passes T by reference, but there's no `&` involved, because it is owning. OTOH Passing an argument via `&` is not just "by reference", but may require borrowing a value, which needs a location to be borrowed from, may extend scopes of loans, need specific lifetimes, etc. It's way more than just a perf tweak and is a PITA when it's done implicitly (which async fn does to some extent).

Have you heard about let-else? It’s a recent syntax addition. That example translates as

    let Some(min_id) = foo() else { return };
    // continue coding at same indent

I don't think the comments mean to say the list is useless. It's a nice overview and I learned a few things as well. However, having written non-trivial amount of code in Rust, it really struck me at how many places there are various factual errors (however small they are). And yes, Rust is a complex lang, but if you mix terms like this without noticing the differences, I'm afraid that will make it easier.

To add an example of my own:

    fn do_the_meow(meower: Meower)

seems like you want to take (consume, own) an object implementing Meower, which is correctly explained not possible like this. A suggested solution,

    fn do_the_meow(meower: &dyn Meower)

is very different - it is now correct with regards to a trait access, however, now you're just taking a reference. Correct replacement would be Box<dyn Meower>. And the final solutions,

    fn do_the_meow<M: Meower>(meower: M)
    fn do_the_meow(meower: &impl Meower)

the first one is correct and equivalent to the original intent - it takes (owns) the value. However, the second variant (which is, again, as correctly stated, the best solution), is different again - it takes a reference (`&`) to `impl Meower`.

Coming back to my point - it is important to separate the difference between the ampersand and the impl/dyn part. To suggest an improvement, one could first write all variants of this function taking a reference (`&Meower`, `&dyn Meower`, `&M` and `&impl Meower`), and later introduce the difference between where one can use sized/unsized types, and that Box<dyn Meower> is owned equivalent of &dyn Meower, and why one can't have owned `dyn Meower` just lying around.

"trait Meower" just declares the trait. "impl Meower" tells the compiler to accept any type that implements the trait. It's the same as adding a generic parameter "<M: Meower>" and using "M", as with the example above that one. (Except in the second example it's placed behind a shared reference; it still works either way with either syntax.)

The book "Programming Rust" (very good book btw) only mentions iter() and iter_mut() briefly and focuses on into_iter because the IntoIterator trait only implements into_iter.

You can replicate iter() with `(&x).into_iter()` and you can replicate iter_mut() with `(&mut x).into_iter()` and obviously `x.into_iter()` consumes the contents.

You mean use immutable data structures?