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

Should small Rust structs be passed by-copy or by-borrow? (2019)

forrestthewoods.com

Post reply on HN
Print view View original

91–100 of 238 posts

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#91

Post by karamanolev »

Dobbs wrote: post #82
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

edit: I misread the previous post. Ignore this. How are you using the word simpler? Because to me that implies a combination of more obvious and number of lines of code. Something that a benchmark shouldn't be involved in. For example asking someone to delete 10 lines of code and instead use go's ` net.SplitHostPort` would be an example of "simpler".

That's what they're saying: if someone says anything more complicated is faster, they challenge them to benchmark it. Usually, it turns out whoever argues the "is faster" point doesn't bother to benchmark it and the simpler code-wise thing wins out. So yes - the benchmark goes to performance, simplicity is in lines-of-code, cyclomatic, "in the eye of the beholder" or whatever other metric you choose, but usually it's obvious.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#92

Post by QuadDamaged »

carlmr wrote: post #67
lukaszwojtow wrote: post #65

I always prefer by-borrow. That's because in the future this struct may become non-copy and that means some unnecessary refactoring. My thinking is a bit like "don't take ownership if not needed" - the "not needed" part is the most important thing. Don't require things that are not needed.

Exactly, and if performance at some point matters: benchmark! And I would bet 9 times out of 10 it won't be the bottleneck or even make a measurable difference.

Exactly why IMHO the rust stdlib is so easy to understand. Ownership only when required as a design principle tends to make the design of the overall system more consistent / easier to approach.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#94

Post by Diggsey »

bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

One neat thing here is that the compiler is aware of which types are `Copy` and not internally mutable (not contianing an `UnsafeCell`). For these types, passing `&T` and `T` are equivalent, so the compiler could just choose the faster option.

Even if it's not smart enough to do that today, it could implement this optimization in the future. This could work even without inlining, since the Rust calling convention is unstable, and an optimization based on type size could be incorporated into it.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#95

Post by zozbot234 »

Diggsey wrote: post #94
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

One neat thing here is that the compiler is aware of which types are `Copy` and not internally mutable (not contianing an `UnsafeCell`). For these types, passing `&T` and `T` are equivalent, so the compiler could just choose the faster option. Even if it's not smart enough to do that today, it could implement this optimization in the future. This could work even without inlining, since the Rust calling convention is…

It would be more advisable to add this as a clippy hint, because `&T` and `T` are not always equivalent wrt. FFI.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#96

Post by scotty79 »

ReflectedImage wrote: post #89
scotty79 wrote: post #83

Earlier quoted context omitted.

The thing is not everything can be expressed as a DAG. And finding it towards the end of writing your program after hours of fighting with borrow checker is extremely unpleasant. And I don't think I ever landed in the situation where I could fix the discrepancy by sprinkling in few Rc, RefCells and such. So I prefer to write with RefCells from the start and when I got the thing working and I am ambitious enough then…

There are many many many ways you can express something and it's very likely that one of those ways is a DAG. The issue here is that you are writing C++ code rather than Rust code.

How do you express as a DAG a tree where nodes need to keep references to their children and parents?

Two separate synced trees? Is it worth it?

> The issue here is that you are writing C++ code rather than Rust code.

How dare you! I'm writing TypeScript code! ;-)

Rust is not Forth. I can write whatever I want and there's nothing wrong with that.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#97

Post by the_mitsuhiko »

forrestthewoods wrote: post #58

Oh neat, that’s my blog. My old posts don’t resurface on HN that often. Lots of criticism of my methodology in the comments here. That’s fine. That post was more of a self nerd snipe that went way deeper than I expected. I hoped that my post would lead to a more definitive answer from some actual experts in the field. Unfortunately that never happened, afaik. Bummer.

My only criticism is the “ugly mess” part. You can implement the traits on references too.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#98

Post by szundi »

bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

My favorite way of thinking. Should be applied to question the need for the existence of the given feature or function too, and best to delete the whole stuff.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#99

Post by scotty79 »

zozbot234 wrote: post #77
scotty79 wrote: post #66

Earlier quoted context omitted.

As a Rust beginner that likes to learn the hard way I think I have some insights why Rust seems cumbersome and/or hard for programmers trying it. Rust uses syntax that feels familiar but means completely different things than in pretty much any other language. For example '=' doesn't mean assign handle or copy. It by default means move. 'let' doesn't mean create a name for something. It means create physical space fo…

> For example '=' doesn't mean assign handle or copy. It by default means move. Some complain about this, but the fact is there's no such thing as a zero-overhead "copy" for non-trivial types. C++ started out with = meaning clone the object which was an even bigger footgun, and support for move had to be added after the fact.

Yeah. Making = mean copy is a really bad idea. I very much like the solution in Rust where attempt to move out something that can't be moved out results in automatic copy if the type implements trait Copy.

It's very elegant solution for simple, small data types. But it further occludes how meaningfully Rust is different from everything else because thanks to that = sometimes does mean copy.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#100

Post by [deleted] »

layer8 wrote: post #84
ardel95 wrote: post #81

Earlier quoted context omitted.

How is that semantically different from Rust? in - regular function arguments inout - mut function arguments out - function return Is there any additional information that a compiler can infer from Ada’s parameter syntax?

The difference between passing by reference vs. by value is observable when comparing pointers to the original vs. to the argument. This difference may be unobservable in Ada though (not sure), so Ada would have more freedom choosing between the two.

[deleted]
Post reply on HN