Hi I'm looking for advice / comments on what is the preferred idiomatic approach to writing Rust code. I'm doing the exercises on exercism.io , and as a Python/C/JavaScript programmer, I'm really enjoying learning Rust. I've also programmed in Scheme, FORTH, CoffeeScript, Fortran, and a few other …

[image] tinwood: Also, unwrap_or() is new to me, but I don't see how it is working? unwrap_or(y) will return x if it is called on a Some(x) [or Ok(x) for the Result version] or y if it is called on a None [or Err(_)]

[image] tinwood: but that might be solely because the functional one constructs a second list, whereas the other just iterates over digits; In the itertools crate there is a chunks() ( itertools::Itertools - Rust ) that works on iterables, but unlike windows() it also returns partially filled…

In my opinion, the answer is almost always mixed is idiomatic. I would not go in one extreme or the other. For instance, in this problem I would probably do something like this: pub fn lsp(digits: &str, size: u32) -> Result<u32, Error> { if size == 0 { return Ok(1); } if digi…

Interesting. I kind of wondered if 'mixed' was the idiomatic approach as both approaches are supported by the language; it could've been two competing groups, or a single group who recognised that both have a role to play. Thanks for taking the time to write out the code; it's given me another per…

chunks doesn't do overlapping subsequences. In itertools you have only tuple_windows, which is not useful when you need varying window size.

One optimization you can make is to iterate over bytes instead of chars. The Bytes iterator implements ExactSizeIterator so the collect call will be slightly faster. Also, iterating over bytes is always slightly faster than iterating by over characters but not by that much. You might consider compi…

Actually, benchmarking is hard... With judicious use of test::black_box to prevent the compiler from optimizing away too much code, the functional version is at least 50% faster: #![feature(test)] extern crate test; use test::Bencher; #[derive(Debug)] pub enum Error { Digit, Window, } p…

interesting, i measured that it's 2x as slow on windows of length 3 and 50% faster on windows of length 10 for that snippet.

Did you remember to optimize (rustc -O)? The functional variant is pretty consistently faster on my machine: rustc -O --test the_test.rs ./the_test --bench

@cbreeden , @stebalien - wow, much better bench-marking than I did! I know that the imperative version can be improved: It calculates the first windows-size - 1 products which will all be 0, so aren't needed. It calculates the whole product again; a combination of a remembering the product and div…

Which is more idiomatic? Functional, imperative or a mix?

help

cbreeden June 10, 2017, 11:50pm 20

Long story short: Idomatic rust is the rust that runs fastest

Topic		Replies	Views
Enumerate very slow?	51	4503	December 14, 2019
Soft question: functional programming in rust feels 'clunky'	26	2810	February 5, 2019
Help with increasing performance in multi_cartesian_product like functions help	22	1820	February 20, 2020
Any possible improvements to this functional program? code review	63	4229	March 26, 2020
Rust vs. C++: Fine-grained Performance	50	8044	January 26, 2016

Which is more idiomatic? Functional, imperative or a mix?

Related topics