Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.2.0 is from another dimension

tomaszs2.medium.com

Post reply on HN
Print view View original

171–180 of 341 posts

Re: Ruby 3.2.0 is from another dimension

#171

Post by nickjj »

empthought wrote: post #121
michaelteter wrote: post #91

Earlier quoted context omitted.

Before Ruby introduced filter_map: res = (1..10).select { |x| x != 5 }.map { |x| x ** 2 } With filter_map: res = (1..10).filter_map { |x| x ** 2 if x != 5 } In both cases, I think the Ruby solution is more readable. Python list comprehensions invert the subject (data) and the verb (action). You see what will be done before you see what the subject is. I would argue that showing the subject first allows easier code re…

> I think the Ruby solution is more readable. I disagree and I’ve used both professionally for about the same amount of code.

I think this is purely a personal preference but I also think there is a bias towards list comprehensions being more difficult to mentally parse.

I do a lot of contract work and chatted with a ton of folks ranging from beginners to veterans. A lot of them (well more than half) avoid list compressions, especially when working with teams because it's such a mixed bag of either being able to instantly understand them or it requires more effort. Personally I don't use them in my code (for both reasons).

Both Ruby solutions are much more clear to me even though I have no functional programming background. I have no preference towards functional styles either, I would say it's the opposite. I struggled with Elixir long enough that I stopped using it.

Re: Ruby 3.2.0 is from another dimension

#172

Post by cutler »

ergonaught wrote: post #104
michaelteter wrote: post #14

Ruby is my favorite language, and often it is a joy to use because of its combined attributes of brevity, expressive power, and feature consistency. It's disappointing that there are so many more jobs for another popular language - one that lacks the elegance and consistency but which has a larger ecosystem. As far as I know, the only well known reason for a company to choose Ruby is if they want Rails (and obviously…

I chose python over ruby eons ago because, for whatever reason, ruby reminded me of perl (not a good thing). Something about the syntax turned me off. Rust has similar problems for me.

For me the continuity with Perl was the main attraction.

Re: Ruby 3.2.0 is from another dimension

#173

Post by tragomaskhalos »

arnvald wrote: post #46
samwillis wrote: post #25

Earlier quoted context omitted.

You are obviously referring to Python and so I would like to note a few things. (I have nothing against Ruby) > Ruby ... its combined attributes of brevity, expressive power, and feature consistency. > [Python] lacks the elegance and consistency First I would argue Python is very consistent in its design, it aims to only have one obvious way to do things and so it's easy to guess how apis will work. It also aims for…

I explored this topic a while ago on my blog [0] In essence, I don't think it has anything to do with elegance, syntax, or "easiness". It's more about timing + origin + corporate adoption: * Python was created in Europe, Ruby was created in Japan - when Ruby gained more recognition in English-speaking world (~2004), Python has already been present and used worldwide for a decade * Ruby was created as a personal, hobb…

For me personally, the killer was that python is typically pre-installed on linuxen while Ruby isn't, and if those environments are controlled or locked down in any way it can be a ballache to get ruby on there. Hence python is the path of least resistance.

Re: Ruby 3.2.0 is from another dimension

#174

Post by jacquesm »

Calavar wrote: post #116
aidos wrote: post #62

Earlier quoted context omitted.

Those functions take any object that supports the iteration protocol. There’s no need for adding say, len, to every object that needs a len function. I’d argue that is consistent. Sure, multi line lambdas might be nice, but equally you can define functions wherever you need them so it’s not really all that different.

> There’s no need for adding say, len, to every object that needs a len function. I’d argue that is consistent. Python's len works by calling the __len__ method, which must be added to every class that needs a len function. Since you're already defining a method with a standard name on every class that needs it, Ruby just has you call that method directly as opposed to the absurdity of intentionally obfuscating the m…

It's almost like they have become memes in themselves. "There is only one way to do it" -> except for those cases where there is a multitude, including the base choice of major release of interpreter, package manager, and so on. Python is very usable but it definitely isn't perfect and the only way you get to improve on stuff is to recognize its shortcomings.

Re: Ruby 3.2.0 is from another dimension

#175

Post by barrkel »

samwillis wrote: post #63
MartinMond wrote: post #31

Earlier quoted context omitted.

When I looked at Python vs Ruby many years ago, I found the opposite: Why does Python have (special) functions like len() and map(), instead of 'properly' supporting both OOP (len should just be a method on objects) and/or FP (support multi-line lambdas so I can actually use map/filter etc). I never understood how this can be considered consistent at all, and those IMHO language design warts made me look into Ruby at…

Map/filter are considered inferior in Python to list comprehensions. res = [x**2 for x in range(10) if x != 5]

By who?

I always have to stare at list comprehensions very closely to understand operation being done. The source of the data is in the middle, where it should logically come first. The filter is at the end, where logically it should come after the source. The mapping is at the start, where logically it should come at the end.

I find the monadic, additive style of Ruby much easier to understand:

    10.times.select { |x| x != 5 }.map { |x| x ** 2 }
IMO it's more composable. What if you want to exclude even numbers from the result? Just add another filter:

    10.times.select { |x| x != 5 }.map { |x| x ** 2 }.select { |x| x % 2 != 0 }
Incrementally building up a streaming computation this way is much more useful to me than a list comprehension.

For example, you can add a lazy to the stream to avoid performing all the operations eagerly, and now you have a way to process sequences without blowing out your memory.

Re: Ruby 3.2.0 is from another dimension

#176

Post by cutler »

byroot wrote: post #131
cutler wrote: post #112

Do these YJIT improvements come at the cost of significantly increased memory usage?

Yes, like all JITs by definition. The actual memory increase depends heavily on the app size so I could quote some figures but it would likely be irrelevant to you.

So not much to shout about given that Ruby's memory usage isn't great to begin with?

Re: Ruby 3.2.0 is from another dimension

#177

Post by yxhuvud »

j_mo wrote: post #90
yla92 wrote: post #56

Earlier quoted context omitted.

> It's slower than Ruby. Any reference/numbers to back this up ? Just genuinely curious about this.

In all the language comparisons I've found over the years, Python consistently comes out slightly slower, for example: https://github.com/kostya/benchmarks Bearing in mind these are probably not even using YJIT, which makes Ruby considerably faster in some scenarios.

Ruby used to be slower though, during the 1.8.7 times. But that was a long time ago now.

Re: Ruby 3.2.0 is from another dimension

#178

Post by peoplefromibiza »

adammarples wrote: post #143
peoplefromibiza wrote: post #73

Earlier quoted context omitted.

> In what situation is python the worst possible choice, while ruby which is very similar to it is the best possible choice? in no particular order, on top of my mind (there are many more): - mixed environments when you can't compartmentalize Python in a container. Python package management is one of the best examples of "poor implementation" - mixed environments, when both Python 2.x and 3.x are present. Migration t…

I think this could be summed up as a) python venvs can be very annoying, and are a weakness of python, and b) rails + active record is a strength for ruby. Fully agree with both, but disagree with the hyperbole (worst possible choice vs. best possible choice). FWIW I haven't even seen Python 2 code in about 6 years.

> worst possible choice vs. best possible choice

worst possible choice VS not worst

> FWIW I haven't even seen Python 2 code in about 6 years.

there are a lot of scripts lurking around in corporate environments all over the World

6 years is brand new to them

There are a lot of environments "certified" to work only on, let's say, Redhat 5 <= 5.2

Re: Ruby 3.2.0 is from another dimension

#179

Post by eternalban »

empthought wrote: post #121
michaelteter wrote: post #91

Earlier quoted context omitted.

Before Ruby introduced filter_map: res = (1..10).select { |x| x != 5 }.map { |x| x ** 2 } With filter_map: res = (1..10).filter_map { |x| x ** 2 if x != 5 } In both cases, I think the Ruby solution is more readable. Python list comprehensions invert the subject (data) and the verb (action). You see what will be done before you see what the subject is. I would argue that showing the subject first allows easier code re…

> I think the Ruby solution is more readable. I disagree and I’ve used both professionally for about the same amount of code.

I don’t use either, and also have an admittedly irrational dislike for Python. That said, the Python variant is more readable imo as well.

Re: Ruby 3.2.0 is from another dimension

#180

Post by cpursley »

wiseowise wrote: post #152
Mikeb85 wrote: post #29

Earlier quoted context omitted.

Python gained traction because of Google (Google used it initially then Guido worked for them for a decade+, vs. Matz at Heroku/salesforce) and then because it's the easiest way to use ML libs. That's it. It's slower than Ruby, has worse package management and less consistent syntax but if you want to use Tensorflow, PyTorch, etc..., it's the default.

> It's slower than Ruby That’s like saying that Dodge Neon is Slower than Mazda Miata. Both are bottom of the barrel compared to any compiled language.

A Miata will smoke a Neon in the corners and is just more pleasant to drive. Miatas are the number one hobby motorsport (racing) vehicles of choice for a reason.

Which is actually a great analogy for Ruby vs Python!

Post reply on HN