Live data from Hacker News

Ruby 3.0.0 RC1

ruby-lang.org

31–40 of 133 posts

Re: Ruby 3.0.0 RC1

#31
post #26

Earlier quoted context omitted.

> I wish all the "big data" tooling was written in Ruby. On a practical note, Ruby's heavy use of reflection, inheritance and method_missing style dispatch currently makes performance for big data tasks less than ideal. Python is less expressive but its "one true way" makes things like vectorization and type specialization easier for data tasks. Sometimes you really just need a better Fortran.

I believe you’re confusing Ruby with Rails. While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic. As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.

I concur.

The dynamic inheritance part of Ruby is still core even in a non-Rails ecosystem. That does make optimizing performance more difficult.

But on a much simpler level, a lot of Pythonic data code is just functions + values, without them being complected in an object. That makes a lot of stuff like wrapping numerical libraries in C very easy in Python. I think you'd still have a bit of a culture shock writing procedural, return-by-value code in Ruby. That's pretty normal in Python and I think one of the (many) reasons it got picked up by STEM disciplines in academia. Looks over shoulder at awful code in Numerical Recipes in Fortran book.

Different strokes for different folks and all that, I just think there are probably constraints (and cultural values) that Python has that make it more suited to data problems than Ruby.

Re: Ruby 3.0.0 RC1

#32

RC1 is a little bit late for a Christmas Day release (which is a long-running Ruby tradition). I wonder if they’ll make it, and if so, if 3.0.0 will be less stable than usual.

Anecdata: I’ve been running both previews daily (when I could, some gems need updating), and they seemed quite stable to me already, moreso than some other previews or even RCs.

Re: Ruby 3.0.0 RC1

#33

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…

> my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there.

I could see reasons for preferring Java over Ruby but concurrency isn't one of them considering that Concurrent-Ruby running on JRuby gives you access to all of Java's concurrency tooling.[1]

1. https://github.com/ruby-concurrency/concurrent-ruby

Re: Ruby 3.0.0 RC1

#34

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…

Ruby might have some qualities but overall it's less polished than python

Just as a small example, Edit: .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list

Also the optionality of parentheses sounds like a good idea but it actually makes things more confusing and less parseable

Re: Ruby 3.0.0 RC1

#35
I tried Ruby over 10 years ago and while I really enjoyed the language itself (vastly more than, say, Python for instance) I was completely put off by the insanely poor performance of the interpreter. I remember trying to get it to run on a rather slow FreeBSD box back then and just loading a simple script with a few dependencies would take literally seconds! Perl and Python were easily an order of magnitude faster.

Have things improved on that side?

Re: Ruby 3.0.0 RC1

#36
post #20

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…

I worked with both Python and Ruby daily for several years, both quite a few years ago and now just write the occasional scripts in those languages (small scripts, maintenance of older projects, patches for various projects when needed, etc.) I much prefer Python for this. As an occasional Python/Ruby programmer I find it's just so much easier to work with. Ruby has a lot of features, which is part of its appeal, but…

> But I can definitely understand why people settled on Python

I think people settled on python because for a spell it was really hard to install ruby (1.6-1.8), it got worse around 2.0, (by the time python also ran into these issues, it had way more momentum) and:

- schools (high schools, colleges) were teaching python, because "it forced students into code indentation discipline"

- linux distros shipped with python because core features were being written in python

Re: Ruby 3.0.0 RC1

#37
post #4

Could someone familiar with the Fiber/Async thing explain how does this differ from Python's (or Node's)? How come Python (and Node) needs explicit awaits but Ruby seems to "just work"?

Fibers are more like Python green threads, or generators when you abuse them to do coroutines, where you explicitly yield from one to the other. The thing is, if your Fiber calls a blocking IO operation you can’t explicitly yield to another Fiber unless IO unblocks. The scheduler solution attempts to yield to another Fiber when IO blocks.

Ractors resemble Node workers: you get true parallelism, but the two worlds are entirely isolated, sharing nothing. You communicate by passing messages between both, where message content is either copied or moved (ownership change) if it’s not immutable.

(What I described is not 100% accurate, more of a flawed bird’s eye analogy for Ruby foreigners)

Re: Ruby 3.0.0 RC1

#38
There now is:

- Fibers

- Also fibers, but scheduled

- Threads (Not what you'd normally calla thread, because GVL)

- Ractors (what you'd normally call a thread)

I wouldn't say this is a bad thing per se, but I imagine it will be quite confusing for people trying to learn the language.

Re: Ruby 3.0.0 RC1

#39
post #13

I really dislike this: {b: 0, c: 1} => {b:} p b #=> 0 It is so weird that a variable named `b` is initialized after an hash-key-like symbol is referenced (`b:`). It's something you've never seen in Ruby before and that I hope I'll never encounter along my career as Ruby on Rails developer.

It's becoming quite common in JavaScript, but usually with a const/let keyword in front so it's easier for the brain to understand that you are reading a destructuring assignment.

I believe you are misunderstanding how this new feature works in Ruby. You've brought up destructuring assignment in javascript which flows right-side values by key to left-side variables. In Ruby, this new syntax is "rightward" assignment, values flowing from left to right:

    3 => x # assigns 3 to x
    [4, 5] => [x, y] # assigns 4 to x, 5 to y

Re: Ruby 3.0.0 RC1

#40
post #26

Earlier quoted context omitted.

I believe you’re confusing Ruby with Rails. While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic. As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.

I concur. The dynamic inheritance part of Ruby is still core even in a non-Rails ecosystem. That does make optimizing performance more difficult. But on a much simpler level, a lot of Pythonic data code is just functions + values, without them being complected in an object. That makes a lot of stuff like wrapping numerical libraries in C very easy in Python. I think you'd still have a bit of a culture shock writing p…

I'm inclined to agree.

One of Python's strengths in this space is that it's a procedural language with just enough in the way of object-oriented facilities. That makes it possible to write reasonably object-oriented libraries with easy-to-learn interfaces, while still sticking to procedural idioms for the actual data hacking.

Which, in turn, means makes it a comfortable environment and interfacing mechanism for both engineers and analysts.

That said, sometimes I look at tools like https://moosetechnology.org and desperately wish I could be using something like that at work.

Post reply on HN