Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Rust Lifetime Misconceptions (2020)

github.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Common Rust Lifetime Misconceptions (2020)

#81

Post by packetlost »

inejge wrote: post #47
packetlost wrote: post #6

Earlier quoted context omitted.

This is how my team writes production Rust code. Knowing which one to use and when is important, but there's nothing wrong with using the tools available to you. Non-lexical lifetimes are, in my experience, pretty uncommon in most non-library code. You don't really need them until you really need them.

Non-lexical lifetimes are, in my experience, pretty uncommon in most non-library code. To avoid confusing the newcomers: lifetimes are always non-lexical (see [1] for the pedantic details.) I suppose you meant that explicit lifetime annotations are pretty uncommon, which is not wrong. [1] https://blog.rust-lang.org/2022/08/05/nll-by-default.html

Oh yeah, wrong terminology. My bad!

Re: Common Rust Lifetime Misconceptions (2020)

#82

Post by farmeroy »

couchand wrote: post #75
gruelsandwich wrote: post #57

Earlier quoted context omitted.

This is what I love about Rust, and other languages with these kinds of constructs. You have to acknowledge that something might e.g. fail. You can choose to do "nothing" (e.g. unwrap), but it must be done explicitly, which makes the ignored cases simple to identify later

.unwrap() is the new // TODO:

for better or worse...

Re: Common Rust Lifetime Misconceptions (2020)

#83

Post by jlffwoymasdf »

farmeroy wrote: post #26
satvikpendem wrote: post #11

I just clone everywhere and write Rust like a high level language. Then, once I need to optimize more, if I ever do (as Rust is many times faster than other languages even with liberal cloning), then I simply go through and remove the clone where needed.

Me too. I also do this with .unwrap() - when I'm pretty sure of the happy path - while I'm prototyping. It's pretty easy afterwards to run back through and replace .unwrap() calls with better error handling. But as I improve, I'm getting more in the habit of using matching directly. Understanding lifetimes is probably really helpful for understanding library errors though and I need to go deeper there for sure

I found prototyping with `anyhow` really easy then I can convert to `thiserror` if I'm not interested in the boxing.

Re: Common Rust Lifetime Misconceptions (2020)

#84

Post by riku_iki »

anticodon wrote: post #64
brabel wrote: post #60

Earlier quoted context omitted.

> as Rust is many times faster than other languages even with liberal cloning Have you really compared? I have. Rust was faster for "small input", but quickly got beaten by Java and other languages I tried because the cost of doing things this way grows exponentially. I suggest you run benchmarks before you make your mind up and start throwing opinions around.

I have never benchmarked Java vs other languages, but from experience java applications always have horrible startup time. So, there might be some contexts in which long running Java application can beat Rust or other language, but if you need something that starts instantly (like CLI utilities) Java is a no-go. Another wart is that there are some written and non-written standards on CLI arguments (e.g. long option n…

> So, there might be some contexts in which long running Java application can beat Rust

yes, context is essentially all server side SaaS business segment..

Re: Common Rust Lifetime Misconceptions (2020)

#85

Post by lolinder »

anticodon wrote: post #64
brabel wrote: post #60

Earlier quoted context omitted.

> as Rust is many times faster than other languages even with liberal cloning Have you really compared? I have. Rust was faster for "small input", but quickly got beaten by Java and other languages I tried because the cost of doing things this way grows exponentially. I suggest you run benchmarks before you make your mind up and start throwing opinions around.

I have never benchmarked Java vs other languages, but from experience java applications always have horrible startup time. So, there might be some contexts in which long running Java application can beat Rust or other language, but if you need something that starts instantly (like CLI utilities) Java is a no-go. Another wart is that there are some written and non-written standards on CLI arguments (e.g. long option n…

> So, there might be some contexts in which long running Java application can beat Rust or other language, but if you need something that starts instantly (like CLI utilities) Java is a no-go.

Maybe I'm in a bubble, but to me this sounds like Java would have faster performance in nearly all professional development situations. Very few people are writing CLI tools compared to those writing server code.

Re: Common Rust Lifetime Misconceptions (2020)

#86

Post by estebank »

Waterluvian wrote: post #79
estebank wrote: post #78

Earlier quoted context omitted.

If you have thoughts on how to improve the output for better understanding, do file a ticket against rustc. We are space constrained, so we try to avoid long explanations as much as possible, but we sometimes do or add links to the right spot in the docs.

Oh, I don’t have any criticism for the messages. It’s amazing that they can be so correct. And I’ve yet to find one I cannot quickly and accurately google. I’m criticizing my inability to convert them into knowledge vs just blindly doing what it’s telling me to do. I would personally discourage trying to accomplish too much in the error messages. As long as they are a sufficient breadcrumb for what’s wrong, where, an…

That is part of the strategy: remove jargon when possible, consciously feed jargon when unavoidable to introduce concepts and give something useful to search for.

Re: Common Rust Lifetime Misconceptions (2020)

#87

Post by diarrhea »

burntsushi wrote: post #73
zaphirplane wrote: post #37

Earlier quoted context omitted.

I know there was a thread involving a rust team member saying that clone / to_owned is ok to start with The memory copying just nags and distracts me from moving on

Yes, it absolutely is. And it's even okay beyond just starting with. Search the regex crate repository for clones. There are a lot of them. Hell, Regex::new accepts a &str for a pattern, and one of the first things it does is convert it to a String.

Interesting. Most regexes being short, I reckon that copy is very cheap. Still I wonder, wouldn’t Cow be an acceptable middle ground, “best of both worlds” style (only copy when needed)?

Re: Common Rust Lifetime Misconceptions (2020)

#88

Post by girvo »

lmm wrote: post #58
girvo wrote: post #51

Earlier quoted context omitted.

SML is great, but I always suggest OCaml. Still my favourite language that I never get to write these days!

For practical programming I'd probably agree, but if the point is to learn a non-Algol way of thinking then I think SML is a better way to go; OCaml makes it easier to write imperative-style code, for better and for worse.

Yeah that's a fair point!

Re: Common Rust Lifetime Misconceptions (2020)

#89

Post by burntsushi »

diarrhea wrote: post #87
burntsushi wrote: post #73

Earlier quoted context omitted.

Yes, it absolutely is. And it's even okay beyond just starting with. Search the regex crate repository for clones. There are a lot of them. Hell, Regex::new accepts a &str for a pattern, and one of the first things it does is convert it to a String.

Interesting. Most regexes being short, I reckon that copy is very cheap. Still I wonder, wouldn’t Cow be an acceptable middle ground, “best of both worlds” style (only copy when needed)?

No, because the clone is always a marginal cost, no matter how big the pattern is.

`Cow` would be a needless and gratuitously bad type to accept for Regex::new. There's no point. It would very likely suffer the same class problems as using Into, because we'd need to use Into>, and thus it is susceptible to annoying inference failures.

It's always important to contextualize costs. In this case, regardless of the size of the pattern string, cloning it is always marginal relative to the other costs incurred. (One possible exception to this is if the pattern is just a simple literal with no regex meta characters. There in theory could be a fast path to side-step regex parsing and other things, but in practice there's not much need for that.)

Post reply on HN