The filter_map explanation is wrong. .ok() converts a result to an Option, not a boolean. Likewise, filter_map expects an option. That's how it can both filter and map.
That's one beautiful thing about Ruby. There's not just one way to do it, which means that .select and .find_all may be aliases but both are valid and will show up, depending on the author's preference.
That seems a bit shallow. I’ve been Rubying for 10 years and have always preferred find_all over select. select turns up in other APIs having different meanings (thinking of IO specifically); find_all tells you exactly what it’s going to do. Just my opinion, of course.
I don't recognize your handle, but nice that you remember DataMapper!
I'm doing really well, although I did kind of fall off OSS work as I got busier with kids and family stuff. I still hack on lots of different things, but nothing that I've been able to open source. I've been busy learning Haskell these days, although I tend to write Ruby for work.
I always use select and I've been writing Ruby since 2006. I didn't even remember find_all exists. As a name select reflects what I want it to do, find_all much less (this is very subjective). Furthermore it's easier to type. Luckily we have both and everyone is happy.
Good post, although it served to remind me again how much I love Ruby for it's emphasis on being elegant and expressive. I may not reach for it first for anymore for standing up a new service, but I still use it for personal projects and scripts unless there's a compelling reason not to.
Though I don't quite like the part about package managers. The more of them
is language specific, the more entrenched in the language development is,
the more difficult is to develop multilingual code, and the more projects
depend on random stuff from the internets for no good reason, like in the
infamous left-pad farce.
Nice article, I bookmarked it. I am just now learning Rust because I want to use an open source blockchain library/framework written in Rust. Ruby used to be my favorite language until a career in machine learning literally forced me to swap scripting languages. I also really like Haskell (plug: I wrote a Haskell book) and I find that Rust borrowed many good ideas from Haskell.
The section titled "Implicit returns and expressions" purports to contrast the two when as far as I can tell they work identically.
In fact, the article specifically calls out that in Rust, even if expressions have a value, which is also true in Ruby, every expression has a value (though it is sometimes nil).
Lol. If you want to hamstring yourself by not utilizing powerful concepts, then go ahead, but don't thrust that onto others. The concept of moving a value is powerful and useful when designing APIs. You can use it to basically encode a finite state machine into your API, with the property that once a state is used for a transition, it can't be reused.
Rust is faster, more energy efficient and more RAM efficient than ruby. If that is not a real benefit to you personally then you should clarify that because there are far more exceptions than just real time systems.
Don't say Rust is useless.
Do say you don't need Rust.
Don't be so defensive, it is just a programming language.
> Don't say Rust is useless
Read it again. What I said was that the complexity added by the concept of ownership is not a worth the benefit of not having a garbage collector, except in a few cases.
I am not necessarily comparing it with Ruby. I am comparing it with languages equally fast, Go, OCaml, Haskell, that are garbage collected.
Instead of telling me what to say and not, why do you try to convince me that my argument is wrong. That's what this forum is about, no?
In the section about converting a vector of strings into integers the article says that the Result returned from parse() is converted to a bool via Result::ok(). However, Result::ok() actually converts the Result<T, E> into a Option<T> which is what filter_map() expects.
They should have just used `flat_map`, which does everything that `filter_map` does and more. In this case the call to `Result::ok` could have been omitted in favour of the identity function (which strangely isn't in the standard library). I wonder why rust even has `filter_map`.
Docs: https://doc.rust-lang.org/std/result/enum.Result.html#method...