5 ms·

Because I love Python, and Rust is applicable is many places where C++ is, here's a Rust version : // assuming `numbers` is an iterator numbers.any(|i|

Because I love Python, and Rust is applicable is many places where C++ is, here's a Rust version : // assuming `numbers` is an iterator numbers.any(|i| i % 2 == 1) Rust's iterators generally compile down very well, and I think this exactly as expressive as Python. And I also wished C#'s Enumerable were as performant as Rust's iterators.

Doctor_Fegg 5y ago
That’s basically borrowed off Ruby. (Which isn’t a bad thing.)
- kragen 5y ago
  It's not that simple. Ruby's Enumerable is a concrete class; Rust's std::iter::Iterator is a trait, which has some aspects in common with Ruby classes and other aspects in common with Python protocols such as the Python iterator protocol. std::iter::Iterator is (primarily, though not in this case) an external iterator like Python iterators, STL iterators, and ranges in C++20 or D, not an internal iterator like (the original version of) Ruby Enumerable. Rust's type-checking strategy is more like ML than like Ruby, Python, C++, or D, while its compilation strategy is more like C++'s or D's compilation strategy than those of Ruby, Python, or ML.
- Zababa 5y ago
  The closure syntax is noted in the "influences" page of the language reference: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html > Ruby: closure syntax
mbrubeck 5y ago
And if you write the equivalent to the `find_if` version in Rust, then the standard linter Clippy will automatically suggest the "good" version: warning: called `is_some()` after searching an `Iterator` with `find` --> src/lib.rs:2:9 | 2 | numbers.find(|i| i % 2 == 1).is_some() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use `any()` instead: `any(|i| i % 2 == 1)` |
kragen 5y ago
IMHO it still suffers from less orthogonality; it's precisely equivalent to the C++ std::ranges::any_of version, though pleasantly less verbose. I think I'm going to have to get serious about Rust. I had a dismaying epiphany writing https://news.ycombinator.com/item?id=28660097 https://news.ycombinator.com/item?id=28660097 the other day: like Perl, Python just isn't saving me very much effort except for quick hacks, maybe a factor of 2–4 over C (if we discount CVEs, heh). It's not the order-of-magnitude development speed improvement I was hoping for, and now that I've been using it for 20 years I know it never will be. Python starts to buckle under the strain of large projects, they totally fucked up Unicode handling to an epic degree never seen in any other programming language, and it typically costs you orders of magnitude in performance. And—this is the worst of all—at best a library written in Python is only usable from Python and maaybe the JVM languages, and you can probably call it from a shell script. (I don't know, maybe the CIL languages too.) By contrast, if I write a library in Rust or C or C++ or D I can use it in Rust, C, C++, D, Python, Perl, Ruby, LuaJIT, Julia, PHP, node.js, Scheme, Common Lisp, OCaml, Golang, the JVM languages, the CIL, and maybe even Arduino. So the effort is greater (though, as you point out in this case, not necessarily much greater, though you didn't mention compile time, which sucks pretty bad for both Rust and C++) but the benefit is much greater. (Also, the Python 2→3 gap was pretty badly flubbed, especially at the social level; no other language community tries to shame people out of maintaining backward compatibility that I know of.) So I think from now on I'll try to start writing prototypes in Python or OCaml but, if the prototype seems worthwhile, writing the Real Thing in Rust. Which is gonna be pretty rough since I don't know Rust. :)
- gpshead 5y ago
  We'll link to this in ten years when you're still writing some Real Things in Python assuming this site even stays up that long and we have nothing better to do. ;)
  - kragen 5y ago
    Ha! I forget if I already knew you in 02001, but if I did, you might have said the same thing to me about Perl then. The last time I wrote a Perl module was probably 02005.
Zababa 5y ago
And if numbers isn't an interator, it isn't really worse: numbers.iter().any(|i| i % 2 == 1) I like how explicit it is without being too noisy.

Doctor_Fegg 5y ago

That’s basically borrowed off Ruby. (Which isn’t a bad thing.)

kragen 5y ago
It's not that simple. Ruby's Enumerable is a concrete class; Rust's std::iter::Iterator is a trait, which has some aspects in common with Ruby classes and other aspects in common with Python protocols such as the Python iterator protocol. std::iter::Iterator is (primarily, though not in this case) an external iterator like Python iterators, STL iterators, and ranges in C++20 or D, not an internal iterator like (the original version of) Ruby Enumerable. Rust's type-checking strategy is more like ML than like Ruby, Python, C++, or D, while its compilation strategy is more like C++'s or D's compilation strategy than those of Ruby, Python, or ML.
Zababa 5y ago
The closure syntax is noted in the "influences" page of the language reference: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html > Ruby: closure syntax

mbrubeck 5y ago

And if you write the equivalent to the `find_if` version in Rust, then the standard linter Clippy will automatically suggest the "good" version: warning: called `is_some()` after searching an `Iterator` with `find` --> src/lib.rs:2:9 | 2 | numbers.find(|i| i % 2 == 1).is_some() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use `any()` instead: `any(|i| i % 2 == 1)` |

kragen 5y ago

IMHO it still suffers from less orthogonality; it's precisely equivalent to the C++ std::ranges::any_of version, though pleasantly less verbose. I think I'm going to have to get serious about Rust. I had a dismaying epiphany writing https://news.ycombinator.com/item?id=28660097 https://news.ycombinator.com/item?id=28660097 the other day: like Perl, Python just isn't saving me very much effort except for quick hacks, maybe a factor of 2–4 over C (if we discount CVEs, heh). It's not the order-of-magnitude development speed improvement I was hoping for, and now that I've been using it for 20 years I know it never will be. Python starts to buckle under the strain of large projects, they totally fucked up Unicode handling to an epic degree never seen in any other programming language, and it typically costs you orders of magnitude in performance. And—this is the worst of all—at best a library written in Python is only usable from Python and maaybe the JVM languages, and you can probably call it from a shell script. (I don't know, maybe the CIL languages too.) By contrast, if I write a library in Rust or C or C++ or D I can use it in Rust, C, C++, D, Python, Perl, Ruby, LuaJIT, Julia, PHP, node.js, Scheme, Common Lisp, OCaml, Golang, the JVM languages, the CIL, and maybe even Arduino. So the effort is greater (though, as you point out in this case, not necessarily much greater, though you didn't mention compile time, which sucks pretty bad for both Rust and C++) but the benefit is much greater. (Also, the Python 2→3 gap was pretty badly flubbed, especially at the social level; no other language community tries to shame people out of maintaining backward compatibility that I know of.) So I think from now on I'll try to start writing prototypes in Python or OCaml but, if the prototype seems worthwhile, writing the Real Thing in Rust. Which is gonna be pretty rough since I don't know Rust. :)

gpshead 5y ago
We'll link to this in ten years when you're still writing some Real Things in Python assuming this site even stays up that long and we have nothing better to do. ;)
- kragen 5y ago
  Ha! I forget if I already knew you in 02001, but if I did, you might have said the same thing to me about Perl then. The last time I wrote a Perl module was probably 02005.

Zababa 5y ago

And if numbers isn't an interator, it isn't really worse: numbers.iter().any(|i| i % 2 == 1) I like how explicit it is without being too noisy.