Exercism is a great resource.
Hey Rustceans, quick question: do you all see web frameworks like Iron kicking off in the near future? I remember seeing a benchmark in some github repo that showed that Rust web frameworks were the fast as hell, and I was curious as to what you all think.
@bigDaddyS1oth If any of them is gonna take off, it's probably gonna be https://rocket.rs/ (pun not intended). I haven't used it myself yet, but it seems to be the one people are most excited about.
:rocket:
Is something like linq2sql possible with rust?
🚀 looks really cool
found https://diesel.rs/
Will learning rust make me earn millions of dollar?
Of course!
If you'll have incredible rich uncle in some foreign country, who will die by accident. :wink:
Who spoke Niggeria?
why does iter::any() require a predicate?
it's kinda dumb to be forced to do stuff like:
.any(|_| true)
@snarf95_twitter why would you want to do that?
That just tells you whether or not the iterator is empty or not
Actually it tells you nothing
Because if the iterator is empty then
.any(...) returns true
.any(|_| true) will always return true
What are you trying to do?
@sdleffler According to docs, for empty
.any(...) returns false
obviously i'm checking whether the iter contains any elements
maybe it's better to use
.count()?
no
any allows for shortcutting
short-circuiting*
.next().is_some(), maybe?
yeah but not as pretty as any()
if whatever.any()
For me it feels like an abuse of any()
@tanriol really? That feels wrong. I'd expect it to return true (vacuous truths and all that)
So you're asking why
.any(...) needs predicate in case you're using it in uncommon way? :)
huh
what if you want to seperate query logic?
It does return
false if empty
@snarf95_twitter
any answers the question "is there an element for which ... keeps". If there are no elements, the answer is obvious :-)
@snarf95_twitter you can use
.len() if you have an ExactSizeIterator
but what if the query is already defined and you just want to test if it contains any elements?
Otherwise, you can also use peekable iterators
like a fn returning a query and you don't want to rewrite the query logic
If you use
.peekable() you'll get an iterator from which you can peek in and see whether it has a next element
I'm coming from a C# background and Any() is a no-brainer there
@jplatte huh well that same benchmark I saw (I gotta figure out where the hell I saw that) Iron was actually faster than Rocket. Is Rocket sort of like the "Rails" solution of Rust?
@bigDaddyS1oth I don't think raw performance is going to win anyone over.
@jplatte well yea, Rails has won over a lot of people for awhile and it's been pretty slow for awhile.
But in terms of comparable frameworks, I think Rails might be comparable but I've never used it or even looked at it. I have looked at Flask though, which seems similar at least in that it uses annotations to do routing (at least in simple hello world kind of examples)
@snarf95_twitter Answering your original question: Rust does not allow C++-style arbitrary method overloading. In particular, you cannot have several variants with different number of arguments. As the main use for
Iterator::any requires a predicate, it has to take one argument.
@jplatte I've used some Rails and it's nice for when you don't feel like creating the skeleton of your website or the scaffolding for your database
interesting wouldn't it be better to do filter(|x| whatever).any() instead?
@snarf95_twitter And the ideomatic solution for Rust would probably be to implement an
is_empty method on the Peekable wrapper.
@snarf95_twitter it's not allowed for iterators to just tell you if they have an element ready for you
And the reason for that is that iterators are lazy
In order for them to check whether or not there's a next element, it's possible the iterator might have to actually compute the next element in the process
.any() will actually cause the iterator to compute all remaining elements
@jplatte but hey I'll check out Rocket once I get some Rust down.
Or rather, all remaining elements up to one at which the predicate returns true (i.e. it short-circuits iirc)
wouldn't any(predicate) do the same
It also modifies the underlying iterator object
Sorry, I mean
.any(predicate). Since Rust doesn't have overloading like that I often omit arguments when talking about the functions themselves.
@snarf95_twitter If your iterator type
impl's ExactSizeIterator, it will have an is_empty. Although it's not stable, so you'd have to use nightly and #![feature(exact_size_is_empty)].
@snarf95_twitter anyways I suspect that
.any(pred) is going to really surprise you with what it does
Because you'll find that yes, it'll tell you if your iterator has an element
But the instant that it finds one, it will consume that element if you haven't created a fresh copy of your iterator to test for elements.
Alternatively,
ExactSizeIterator has the len function, so you could do it.len() == 0, which is probably going to be the exact same machine code in virtually all cases.
.any(|_| true) will chop off an element of your iterator if it finds one
hmm
it's difficult coming from a C#/LINQ background
I think that for your purposes,
Peekable is what you want
.next().is_some() will do the same as .any(|_| true)
Peekable caches the element that you peek
but it might not be a problem to chop off an element...
"might not"?
oof, I'd err on the side of caution if I were you
Think of the bugs that could cause o_O
Do you ever want to use the iterator if it's not empty?
@snarf95_twitter just add
.peekable() to the code that generates your iterator
And then to check it if has an element, run
.peek().is_some()
if you're already generating a new iter
That'll avoid chopping off an element, it's standard-library, and it works for non-
ExactSizeIterators
No, it's not generating a new iterator
It's just a wrapper over an iterator
if you're already generating a new iter it doesn't matter that one element is chopped off
.peekable() consumes an iterator and produces a wrapper Peekable<OldIterator>
Generating a whole new iterator just to tell whether it has an element or not? That's a pretty large cost, isn't it?
Peekable will let you do it pretty much for free
let a = [1, 2, 3];
assert!(a.iter().any(|&x| x > 0));
assert!(!a.iter().any(|&x| x > 5));
Well, what are you iterating over?
If you're iterating over a slice, sure, it's cheap, but a more idiomatic thing to do would just be
.is_empty()
For a
Vec, also .is_empty()
For most Rust containers, I think they also have
.is_empty()
Or something similar
hmmm
but wouldn't it produce the same bytecode?
If you're working only with an iterator - and all you have to work with is the
Iterator trait bound - then Peekable, I think, is your best option
with optimization and stuff
@snarf95_twitter are you seriously advocating
slice.iter().any(|_| true) over slice.is_empty()? :P
well what's the difference when it gets compiled?
If you compile without optimization, then the iterator's still gonna get produced.
i.e. debug builds
If you compile with, then yeah, the iterator and all should be optimized away
gonna check, sec
But I really recommend that you use
.is_empty() or whatever is available rather than sticking to what you're used to. It's an idiom from a different language after all.
FYI, I just checked all collections from
std::collections - each one has is_empty()
well yeah I gotta figure out how to "ignore" my C#-senses
Tough to break a habit, won't argue with that. :)
slice.iter().any(|_| true) and slice.is_empty() compiles into same bytecode
pub fn reply(phrase: &str) -> &str {
if phrase.chars().last() == Some('?') {
"Sure."
} else if phrase.chars().any(|c| c.is_uppercase())
&& !phrase.chars().any(|c| c.is_lowercase()) {
"Whoa, chill out!"
} else if !phrase.chars().any(|_| true) {
"Fine. Be that way!"
} else {
"Whatever."
}
}
@snarf95_twitter It pretty much is, actually.. Although you have one interesting bug in there :D
second else if can be replaced by
.all(|c|c.us_uppercase()) maybe
@Albibek No, actually. Not all characters are letters, so some will be neither upper- nor lowercase
curious about the bug
I'm assuming @snarf95_twitter wants to have the second output if all letters are uppercase, not all characters.
@snarf95_twitter You're returning a string slice with a narrower lifetime than what would make sense
I wonder if clippy catches this...
it should be
&static str?
yeah
It could be
&'static str
but why is it needed? isn't there lifetime elision?
Yes there is, and AFAIK it will do the wrong thing here ^^
hmm
(if there was no elision this code wouldn't compile at all)
There is, but lifetime elision will cause it to live no longer than the input string.
Let me try it actually, before I spew nonesense or something :D
Well now @tanriol has said what I wanted to say ^^
That may be what you mean (what if you want later to reply with a substring of the input string?), but most likely is not.
On the other hand, if you want the possibility to reply with some new text, you may want to consider returning
String.
this is just an exercise (using exercism) I haven't really got any requirements for output other than it passes the test-suite
Then either of
&str, &'static str works
But in the real world you would use
&'static str when all your paths return literals / constants.