Live data from Hacker News

Rust for Rubyists

matthias-endler.de

11–20 of 45 posts

Re: Rust for Rubyists

#11
post #7
post #4

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

Re: Rust for Rubyists

#13
post #3
post #2

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

Re: Rust for Rubyists

#14
post #7

Earlier quoted context omitted.

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

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.

Re: Rust for Rubyists

#15
post #7

Earlier quoted context omitted.

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

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.

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

Re: Rust for Rubyists

#16
post #13
post #3

Earlier quoted context omitted.

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

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

Re: Rust for Rubyists

#17
post #5

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.

Re: Rust for Rubyists

#19
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 into a Option which is what filter_map() expects.

Re: Rust for Rubyists

#20
post #5

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.
Post reply on HN