4 ms·

> I may express here a crucial point, LIFETIMES ARE HARD TO DEAL WITH, so try to not use them to often. While this can be true, you are always dealing with the

> I may express here a crucial point, LIFETIMES ARE HARD TO DEAL WITH, so try to not use them to often. While this can be true, you are always dealing with them if you have a reference to something. Sometimes the compiler will elide them for you but other times you need to explicitly write them. The code snippets in this blog need lifetime annotations for example.

no_protocol 9y ago
> the compiler will elide them for you Surely the compiler isn't going to remove or ignore things that you typed. You probably meant to say the compiler will allow you to elide them.
- squiguy7 9y ago
  Sorry, yes. This page has some documentation on what I meant: https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html
  - no_protocol 9y ago
    Thank you for the informative link. I have spent some time reading about rust in the past but rarely actually used it. When reading about rust I am constantly bombarded with what I would describe as lazy terminology. In this case, the same term, `lifetime`, is being used to describe several distinct aspects of a system. Between the link you shared, the "Rust Book" that is available online, the book "Programming Rust", the compiler's error messages, and all the various blog posts, there is a definite lack of clear language. Many of these sources are even inconsistent within themselves. It seems like the clearest, most agreed usage is that "lifetime" in general is very close to a concept many other languages have, usually called "scope". The problem starts when eventually all these sources start talking about these things that look like `'a`. Suddenly they're calling `'a` the `lifetime`. That's a poor reuse of the same term. It appears the compiler's error messages are calling this a `lifetime parameter`. The "Rust Book" at one point calls them `lifetime annotations`. Many sources just continue calling them `lifetimes` over and over again. It would be nice if someone could come up with very precise language to describe each aspect of the system so that anyone writing about it can communicate clearly. This problem is not limited to lifetimes at all. As I mentioned above, almost every time I read about rust I'm finding this reuse of terms, misuse of terms, and lack of precision. It's quite frustrating and a major turn off.
    - always_good 9y ago
      Dunno, that's about as confusing as pointing out something has a string "type" and then using "type" again to refer to generic type parameter T. I'm sure someone out there unfamiliar with types thinks it's inconsistent, but it's not really something you think about once you familiarize.
      - no_protocol 9y ago
        > and then using "type" again to refer to generic type parameter T I was curious enough to grab a nearby textbook on Java. The author very clearly calls these things "type parameters" or "type variables". Imagine trying to write the whole chapter just calling them "types"..... "Your generic type will have two other types T and E and we will fill in Grape as type T and Fred as type E...." It'd be a disaster! Instead he's used clear language, every single time he refers to one of those things, he uses the specific term. Much better experience.
    - iopq 9y ago
      Lifetimes are related to scopes, but are not scopes: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...
mamcx 9y ago
I have found harder to use Strings. I start build a little interpreted language and boom! the strings is the roadblock. I still not figure what the hell is the deal with it. Why rust no "just" give a "string for mortals"?
- squiguy7 9y ago
  It depends on your use case. You may find `String` [0] easier to use since it is growable, etc. As you continue to use Rust you will find that each type has their reason and string slices (what are used in this blog post) have their limits. [0]: https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html
- bvinc 9y ago
  It's fundamental to rust's view of ownership and borrowing of data. It's not just strings, but it's everything. Strings represent a single exclusive owner of mutable data. &str represents one of possibly many read-only shared references to the internal data of a string. Once you understand this concept you see it over and over. It's how every type in the language works (unless that type implements the Copy trait). I actually think this is something really fundamental and amazing the more I think about it. Most languages, like Java, tell you to make defensive copies of your data because you never know who will be modifying it later. Also most languages will enforce that all strings are always immutable, to prevent people from needing to make defensive copies. Rust just naturally handles this with it's ownership and borrowing rules. And then the very same concept is what makes concurrency safe.
  - mamcx 9y ago
    Yeah I get this, but still is very hard cliff. "String" is so fundamental and when you see how operate with ints, floats and sudenly strings is a hard climb. In the mind of many, strings are at the same "level" than other primitives. I wish it have a "easy mode" and a "advanced" one for when is necessary.
mnivoliez 9y ago
I may have not express myself with the right words. Lifetime are everywhere and most of the time you eilide them. But using it in an expressive way is complexe and difficult to handle (at least for me). If I remember correctly, even the rust team advise to use them carefully as it complexify alot the code.

no_protocol 9y ago

> the compiler will elide them for you Surely the compiler isn't going to remove or ignore things that you typed. You probably meant to say the compiler will allow you to elide them.

squiguy7 9y ago
Sorry, yes. This page has some documentation on what I meant: https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html
- no_protocol 9y ago
  Thank you for the informative link. I have spent some time reading about rust in the past but rarely actually used it. When reading about rust I am constantly bombarded with what I would describe as lazy terminology. In this case, the same term, `lifetime`, is being used to describe several distinct aspects of a system. Between the link you shared, the "Rust Book" that is available online, the book "Programming Rust", the compiler's error messages, and all the various blog posts, there is a definite lack of clear language. Many of these sources are even inconsistent within themselves. It seems like the clearest, most agreed usage is that "lifetime" in general is very close to a concept many other languages have, usually called "scope". The problem starts when eventually all these sources start talking about these things that look like `'a`. Suddenly they're calling `'a` the `lifetime`. That's a poor reuse of the same term. It appears the compiler's error messages are calling this a `lifetime parameter`. The "Rust Book" at one point calls them `lifetime annotations`. Many sources just continue calling them `lifetimes` over and over again. It would be nice if someone could come up with very precise language to describe each aspect of the system so that anyone writing about it can communicate clearly. This problem is not limited to lifetimes at all. As I mentioned above, almost every time I read about rust I'm finding this reuse of terms, misuse of terms, and lack of precision. It's quite frustrating and a major turn off.
  - always_good 9y ago
    Dunno, that's about as confusing as pointing out something has a string "type" and then using "type" again to refer to generic type parameter T. I'm sure someone out there unfamiliar with types thinks it's inconsistent, but it's not really something you think about once you familiarize.
    - no_protocol 9y ago
      > and then using "type" again to refer to generic type parameter T I was curious enough to grab a nearby textbook on Java. The author very clearly calls these things "type parameters" or "type variables". Imagine trying to write the whole chapter just calling them "types"..... "Your generic type will have two other types T and E and we will fill in Grape as type T and Fred as type E...." It'd be a disaster! Instead he's used clear language, every single time he refers to one of those things, he uses the specific term. Much better experience.
  - iopq 9y ago
    Lifetimes are related to scopes, but are not scopes: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...

mamcx 9y ago

I have found harder to use Strings. I start build a little interpreted language and boom! the strings is the roadblock. I still not figure what the hell is the deal with it. Why rust no "just" give a "string for mortals"?

squiguy7 9y ago
It depends on your use case. You may find `String` [0] easier to use since it is growable, etc. As you continue to use Rust you will find that each type has their reason and string slices (what are used in this blog post) have their limits. [0]: https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html
bvinc 9y ago
It's fundamental to rust's view of ownership and borrowing of data. It's not just strings, but it's everything. Strings represent a single exclusive owner of mutable data. &str represents one of possibly many read-only shared references to the internal data of a string. Once you understand this concept you see it over and over. It's how every type in the language works (unless that type implements the Copy trait). I actually think this is something really fundamental and amazing the more I think about it. Most languages, like Java, tell you to make defensive copies of your data because you never know who will be modifying it later. Also most languages will enforce that all strings are always immutable, to prevent people from needing to make defensive copies. Rust just naturally handles this with it's ownership and borrowing rules. And then the very same concept is what makes concurrency safe.
- mamcx 9y ago
  Yeah I get this, but still is very hard cliff. "String" is so fundamental and when you see how operate with ints, floats and sudenly strings is a hard climb. In the mind of many, strings are at the same "level" than other primitives. I wish it have a "easy mode" and a "advanced" one for when is necessary.

mnivoliez 9y ago

I may have not express myself with the right words. Lifetime are everywhere and most of the time you eilide them. But using it in an expressive way is complexe and difficult to handle (at least for me). If I remember correctly, even the rust team advise to use them carefully as it complexify alot the code.