3 ms·

People promoting Rust tend to assume that it's the concepts in Rust that don't exist or aren't explicit in other programming languages that are the hard part. I

People promoting Rust tend to assume that it's the concepts in Rust that don't exist or aren't explicit in other programming languages that are the hard part. In my opinion, that's not true. It's the syntax used to make those concepts explicit. To use the example from the article: lifetimes are not a hard concept to grasp. Knowing when the Rust compiler will require you to make a lifetime explicitly part of your type, vs. when you can elide it? Hard.

steveklabnik 7y ago
> To use the example from the article: lifetimes are not a hard concept to grasp. Knowing when the Rust compiler will require you to make a lifetime explicitly part of your type, vs. when you can elide it? Hard. 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 and you add it in.
- Corrado 7y ago
  Lifetimes trip me up in Javascript all the time. I think that I have all my callbacks and/or promises lined up and dealt and my app runs fine. Until it doesn't and I discover that there is some corner case in my 5 nested deep callback hell where I didn't catch some DB timeout. I'm looking forward to that never happening again in Rust.
pornel 7y ago
Using types as an analogy: Python and JavaScript programmers know the concept of types, but don't have to be rigorous about it. They can even make a mess of it, and use runtime reflection as a crutch. OTOH with a statically typed language you have no choice but be very precise and explicitly think about types. 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?".
- NoGravitas 7y ago
  "there's syntax to learn" is an understatement. There's a lot of syntax to learn, and you can't get away with using a subset of it.
  - pornel 7y ago
    There are 4 places where you use lifetimes. It's really not hard syntax-wise. I teach Rust workshops and I find that novice users struggle with this, because they think of references as pointers, so they use them in places where they don't make sense (e.g. in owned structs or returned from constructors), and then desperately try every possible lifetime syntax to force through an impossible borrow. In practice, once you "get" ownership, it's rare to use any lifetime syntax at all! In a codebase I have open right now (which is in production in 194 datecenters) only 3% of uses of references have a lifetime annotation, and it's just `<'a>` and `&'a`, nothing more complex.

steveklabnik 7y ago

> To use the example from the article: lifetimes are not a hard concept to grasp. Knowing when the Rust compiler will require you to make a lifetime explicitly part of your type, vs. when you can elide it? Hard. 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 and you add it in.

Corrado 7y ago
Lifetimes trip me up in Javascript all the time. I think that I have all my callbacks and/or promises lined up and dealt and my app runs fine. Until it doesn't and I discover that there is some corner case in my 5 nested deep callback hell where I didn't catch some DB timeout. I'm looking forward to that never happening again in Rust.

pornel 7y ago

Using types as an analogy: Python and JavaScript programmers know the concept of types, but don't have to be rigorous about it. They can even make a mess of it, and use runtime reflection as a crutch. OTOH with a statically typed language you have no choice but be very precise and explicitly think about types. 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?".

NoGravitas 7y ago
"there's syntax to learn" is an understatement. There's a lot of syntax to learn, and you can't get away with using a subset of it.
- pornel 7y ago
  There are 4 places where you use lifetimes. It's really not hard syntax-wise. I teach Rust workshops and I find that novice users struggle with this, because they think of references as pointers, so they use them in places where they don't make sense (e.g. in owned structs or returned from constructors), and then desperately try every possible lifetime syntax to force through an impossible borrow. In practice, once you "get" ownership, it's rare to use any lifetime syntax at all! In a codebase I have open right now (which is in production in 194 datecenters) only 3% of uses of references have a lifetime annotation, and it's just `<'a>` and `&'a`, nothing more complex.