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.

Docs: https://doc.rust-lang.org/std/result/enum.Result.html#method...

Thanks for the hint. Will fix that and give you some credits.

Edit fixed.

The example for even numbers should be:

even_numbers = [1, 2, 3, 4, 5].find_all { |element| element.even? }

or

even_numbers = [1, 2, 3, 4, 5].find_all(&:even?)

instead of:

even_numbers = [1, 2, 3, 4, 5].map { |element| element if element.even? }

If I'm writing ruby I'd prefer Array#select for this task.

That’s an alias for `find_all`.

I'm aware of that. I prefer the *ect methods only because they've always seemed to be more popular amongst Rubyists.

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.

Honestly, that sounds like a nightmare to me!

I love Ruby, but I agree. It creates unnecessary ambiguity.

Reads nicer sometimes, sure.

Exactly [1,2,3,4,5].select{|x| x%2 == 0}

If I were interviewing a a Ruby dev, anything other than Array#select indicates lack of experience.

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.

For me, it's always been select/reject/detect. Even though I know about find_all, it always seemed like the odd one out.

Unrelated!

I haven’t talked to you in years. I wrote some DM plugins back in the day.

Hope you’re doing well!

Are you working on any interesting open source projects?

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.

Glad all is well!

You're forgetting the existence of `find` which easily justifies `find_all`

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.

You know that methods in ruby can have many aliases, right? Can you clarify your statement?

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.

It's nice to see languages converging on a standard set of features. String interpolation, random number generation, package management, etc.

Or apparently the even more common functional list operations: “map”, “for_each”, “filter”, “every”, etc.

Well, unless your language is "go" in which case it converges on no good package management and no functional filter/map/reduce functions

Literally the worst thing about that language. Such a common operation, and every time it comes up I end up iterating over ranges like a caveman.

and yet has beyond healthy adoption rate, go figure :)

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.

Great post. If you are plan to write a native Ruby extension, check out Rust Helix https://usehelix.com/

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).

Or every language complicated enough is reinventing lisp partially.

For the uninitiated:

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

I think GP is referring to a slew of current trending languages which are partly functional and have lisp-style macros.

This quote assumes that the creators of Rust didn't know about Lisp.

Enjoyed this, thanks for writing!

> With iter(), you get a "read-only view" into the vector. After the iteration, it will be unchanged.

> With into_iter(), you take ownership over the vector. After the iteration, the vector will be gone. In Rust terminology, it will have moved.

I stopped reading right there. No Rubist or actually nobody, except real time system developers, should care about ownership.

It makes programming so much more complicated without any real benefit, again apart from real time systems.

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?

Minor correction:

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`.