I hadn't been following the proposals for and development of Ruby 3 very closely, so Ractors were a nice surprise when I finally did check in.
Ruby 3.0.0 RC1
11–20 of 133 posts
Re: Ruby 3.0.0 RC1
#12I'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 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.
Re: Ruby 3.0.0 RC1
#13I really dislike this:
{b: 0, c: 1} => {b:}
p b #=> 0
Re: Ruby 3.0.0 RC1
#14Could 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"?
Python Zen: Explicit is better than implicit
There's a python library gevent which experimented with a more implicit design. Or more, this is about green threads vs async/await
It can also be a bit confusing when you don't allow separating await from the call: how do you implement Promise.all?
For official rationale see https://www.python.org/dev/peps/pep-0492/#why-async-and-awai...
Re: Ruby 3.0.0 RC1
#15Love the move to gemify standard library. This is a perfect mix of batteries included but also makes it easy to upgrade bits of the standard library over time between releases. Great way to prevent stagnation.
prevent stagnation
Or irritate a long term user base? PHP has been very successful long term, largely I would argue because of maintaining almost complete backwards compatibility.
Re: Ruby 3.0.0 RC1
#16I've been writing Python for close to a decade off and on. I'm just now dipping my toes into Ruby and have found it quite fun- excited to dig deeper into this and Rails :D
Does some of it feel kind of redundant? I suppose that people have different reasons for learning languages but as someone who knows Python, Ruby is one of the languages on my not-to-learn list since it would neither allow me to work on anything that I can't work on now or introduce some new and interesting language paradigm.
Re: Ruby 3.0.0 RC1
#17I 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.
Re: Ruby 3.0.0 RC1
#18I 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.
Exactly that, I use it all the time in JS. I can't see why Ruby can't adopt something like:
params = { a: 1, b: 2 }
{ a: a } = params
p a #=> 1Re: Ruby 3.0.0 RC1
#19I'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…
It is a pity the type hinting is done in a separate file though, as it leads to a lot of duplication. In this case, I pretty much prefer Python’s approach.
Re: Ruby 3.0.0 RC1
#20I'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 that also means a lot of remember and ... a lot to forget. If you're not steeped in it, then that makes things quite a bit harder.
I programmed some Ruby a few weeks ago; it had been quite a while since I last did any Ruby, and ended up having to look up the syntax for blocks. This is really basic stuff, but I had written str.gsub!('pat', {|m| ... }), and the correct syntax is of course str.sub!('pat') { |m| ... }. Kinda silly I guess and a bit of a "oh, du'h" moment; I spent two years with Ruby as my day job, but that was also five years ago, and I think these kind of mistakes aren't that unusual if you're not programming Ruby too often.
And then there are caveats like using "return" where you should have used "next", and quite a few other things.
Don't get me wrong, I like Ruby, and there's also a bunch of things I don't like about Python. But I can definitely understand why people settled on Python. I think Matz once said "Ruby is 80% Perl and 20% Python"; I feel that with a slightly lower Perl-to-Python-ratio Ruby would have been better.
---
There may also have been implementation considerations by the way. I believe that historically at least, Ruby has been a lot slower than Python, although I think the differences today aren't very large. And a lot of these tools are written as native extensions, which Python seems to support a bit better.