Live data from Hacker News

Rust for Rubyists

matthias-endler.de

31–40 of 45 posts

Re: Rust for Rubyists

#31

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.

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

Re: Rust for Rubyists

#32
post #18

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.

Re: Rust for Rubyists

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

Re: Rust for Rubyists

#34
post #22

> 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 wit…

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.

Re: Rust for Rubyists

#35
post #29
post #11

Earlier quoted context omitted.

That’s an alias for `find_all`.

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!

Re: Rust for Rubyists

#36
post #29

Earlier quoted context omitted.

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.

Re: Rust for Rubyists

#37
post #21

Earlier quoted context omitted.

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?

Re: Rust for Rubyists

#38
post #21

Earlier quoted context omitted.

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.

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

Re: Rust for Rubyists

#39
post #22

> 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 wit…

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.

[deleted]

Re: Rust for Rubyists

#40
post #22

> 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 wit…

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?

Post reply on HN