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?

forrestthewoods.com

Post reply on HN
Print view View original

101–110 of 115 posts

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

#101

Post by 0xffff2 »

whatshisface wrote: post #44
keeperofdakeys wrote: post #37

Earlier quoted context omitted.

In general Rust emphasises semantics over implementation side-effects. For example you use a pass-by-value because you're semantically moving ownership of the value to the function, not because the implementation may be faster/slower at the assembly level. Not nailing down the implementation is what allows the compiler to make so many optimisations. If you need concise pointer control, use the unsafe trapdoor built i…

> If you need fast number crunching use the specialised library for it, not by writing a magic for loop with just the right amount of statements in it. There is always that group of people who are trying to do something for which no specialized library exists.

As a member of that group, Hacker News is not where I come for answers to my questions. I think it's perfectly reasonable for comments here to assume that the readers of the comment aren't in that group. Either you know what you're doing enough that 99.9% of the internet is not helpful to you, or you're probably up shit creek without a paddle anyway until you figure out enough to move into the first group.

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

#102

Post by 0xffff2 »

izietto wrote: post #33
Crinus wrote: post #29

Earlier quoted context omitted.

> so the compiler can do a lot of pointer and inlining magic that C and other languages can't. Isn't this a negative for Rust for when you actually do care about such micro-optimizations? It feels as if you not only need to know the language itself but also how the particular version of the compiler you are using has decided to interpret the language and apply optimizations - essentially having to know how the magic…

> It feels as if you not only need to know the language itself but also how the particular version of the compiler you are using has decided to interpret the language and apply optimizations - essentially having to know how the magic trick is performed. That's also true with C/C++, isn't it? Optimizations should be different if you compile a C program with GCC or CLANG, or even with GCC x or y versions (but I'm not a…

You're absolutely right. It's not even just optimization. If you exercise your C++ compiler hard enough, you will find bugs. You have to know what the compiler is doing.

I have the misfortune of working somewhere where I generally have to use older versions of compilers for production. I've found two compiler bugs just in the last two years since I started my current project. I'm usually the last person to blame the compiler, but in this case I can be pretty confident because the bugs I found were fixed in later versions of the compiler.

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

#103

Post by saghm »

littlestymaar wrote: post #93
blub wrote: post #85

Earlier quoted context omitted.

It's because: a) the language designers decided to cram several paradigms into it, including a heavier than usual dose of functional. b) most people don't want to get pedantic about resource management c) the syntax is weird for people coming from the C language family

> a) the language designers decided to cram several paradigms into it, including a heavier than usual dose of functional. Rust is actually really close to JavaScript in that regard, with its mix of OOP-without-inheritance and the whole collection of functional method on Arrays and iterators ( map , reduce , etc.). And while People have a ton of complain about JavaScript, none of them is «the JavaScript language is to…

> What ? Do you mean “ not coming from the C language family”? Because its syntax is clearly in the C-family (semicolon, braces).

My guess is that they're talking about the syntax inspired from its ML roots, like `let/let mut`, `->` for return types, and `:` for type annotations. I personally prefer these to the C-style equivalents, but I've talked with enough people who haven't used an ML-like language that I'm not quite as surprised as I used to be about people expressing misgivings about them.

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

#104

Post by lytigas »

weberc2 wrote: post #99
lukebitts wrote: post #88

Earlier quoted context omitted.

Do you have an example? Copying is only hard to the extent that you need to #[derive(Copy)] for your type, and ints are already Copy. I also don't see how other traits factor here.

It's been a while, but I tried implementing a trait that took `&self` with several different types. One such type was an integer type, so I had to pass by reference. It's probably not a big deal, but there are many things like this that seem to prefer you move or reference rather than copy. I think it would be better for all traits to implement their methods on `self` and then the caller can choose whether the type t…

Rust basically has this functionality. Whether a type is borrowed or not dictates what I can do with it. For example, I cannot remove items from a `Vec` with a shared &reference. Thus, without knowing which reference type is used in a trait method, I cannot write generic code; I don't know whether my function must take &T or T.

There might be a way around this limitation, but it makes figuring out who is supposed to free a resource hard to do.

The rust solution is to have different traits for different levels of ownership. For example, if I want to iterate over a vector of strings, I can get a Iterator without destroying the vector. If I'm willing to destroy it, I can get an Iterator.

Or, you can actually implement a trait on a reference type[0] to convert a `self` argument to effectively `&self`. This is the recommended way to implement some conversions, using AsRef and/or Into[1].

[0] https://play.rust-lang.org/?version=stable&mode=debug&editio... [1] https://doc.rust-lang.org/std/convert/trait.AsRef.html

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

#105

Post by ncmncm »

atilaneves wrote: post #32

> Rust tuples are delightful to use and C++ tuples are a monstrosity They're not great, but they're a lot better than using out parameters!

Give Rust twenty years, and there will be plenty that's crap compared to the new hotness. C++ tuples will be no worse than they are, and possibly a little better.

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

#106

Post by almindor »

spease wrote: post #63
almindor wrote: post #57

I've had a smaller but similar dive recently while working on embedded machine (32 bit) with Rust. Clippy was pushing me to use move/copy instead of reference for passing a [u8; 8]. I thought this strange on a 32bit machine so I dived in and it turned out the "rule" is supposed to be "up to 2 register sized" variables are supposed to be copied, anything bigger is supposed to be referenced. The trick here is that due…

Did you file a ticket?

No, I asked on the IRC channel and forums as well as a friend who does embedded. The answer was basically "because clippy doesn't know the target arch it has to be a conservative-guess" which I agree with.

My friend also explained how it's a REALLY tricky question to answer properly especially given specific embedded architectures and setups where the answer is very hard.

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

#107

Post by ncmncm »

beeforpork wrote: post #70

The article is interesting, but it is frustrating that it mainly cares about speed, but 'speed' or 'fast' is not mentioned in the title. To answer that general title question, I would not even have considered that 'speed' might be an issue. I'd say: pass small things by value because it probably results in the most readable code, which should always be the first dimension of optimisation, I think. Also, the compiler…

Everyone cares about speed first, or they would be using a more convenient slow language.

The challenge of Rust is, how nice can we make a language without noticeably giving up any performance to C++? Pretty nice, it turns out.

C++ still has an edge on both performance and ability to code powerful libraries that are not a PITA to use. The performance margin definitely will close up. The library margin could, too, but it will require unpleasant choices.

Anyway both are faster than almost anything else, and will stay that way, for von Neumann machines. Those might get less important, soon.

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

#108

Post by [deleted] »

ncmncm wrote: post #107
beeforpork wrote: post #70

The article is interesting, but it is frustrating that it mainly cares about speed, but 'speed' or 'fast' is not mentioned in the title. To answer that general title question, I would not even have considered that 'speed' might be an issue. I'd say: pass small things by value because it probably results in the most readable code, which should always be the first dimension of optimisation, I think. Also, the compiler…

Everyone cares about speed first, or they would be using a more convenient slow language. The challenge of Rust is, how nice can we make a language without noticeably giving up any performance to C++? Pretty nice, it turns out. C++ still has an edge on both performance and ability to code powerful libraries that are not a PITA to use. The performance margin definitely will close up. The library margin could, too, but…

[deleted]

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

#109

Post by bilkow »

ncmncm wrote: post #107
beeforpork wrote: post #70

The article is interesting, but it is frustrating that it mainly cares about speed, but 'speed' or 'fast' is not mentioned in the title. To answer that general title question, I would not even have considered that 'speed' might be an issue. I'd say: pass small things by value because it probably results in the most readable code, which should always be the first dimension of optimisation, I think. Also, the compiler…

Everyone cares about speed first, or they would be using a more convenient slow language. The challenge of Rust is, how nice can we make a language without noticeably giving up any performance to C++? Pretty nice, it turns out. C++ still has an edge on both performance and ability to code powerful libraries that are not a PITA to use. The performance margin definitely will close up. The library margin could, too, but…

> Everyone cares about speed first, or they would be using a more convenient slow language.

I use Rust and I actually care about readability first.

Sincerely I find Rust more readable than most popular languages (Python, Javascript, C++, Java, even Swift...), unless I'm looking into some code that abuses generics and lifetimes (which is actually rare for me).

I think that's because it enforces some pretty clear patterns with its lack of struct inheritance, sum types with pattern matching, the way things are imported ("use" statements), lack of parenthesis around conditionals, and being expression oriented.

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

#110

Post by JoeAltmaier »

sjwright wrote: post #68
JoeAltmaier wrote: post #66

Copying data is among the fastest operations possible on a modern computer bus. Not a thing to worry much about.

Sure, until your typical workload involves billions of them.

Nope. If its a fraction of the processing you do (including loops, calculations and tests) then its negligible. Because you do billions of those things too, and they will dominate the time-cost.

The case in point, subroutine calls, the call itself is far costlier than the argument copying. So in this case, data moving is almost completely irrelevant.

Post reply on HN