I am quite excited about the Ractor. I have never used Ruby, but from reading about it, it seams to be a very pragmatic implementation, where backwards compatibility is handled by saying “be aware not to use globals between two Ractors. On a lower level it is handled by a per thread interpreter with GIL. Much like Python’s sub interpreter ? Maybe it’s time for a Pactor in Python? :-)
I did a small test of the tarai.rb code mentioned in the article, but with 12 Ractor’s on a 6+6 core Apple MacPro Intel Xeon. The output from the program:
user system total real
seq 252.199854 1.154537 253.354391 (253.580377)
par 423.186306 1.488848 424.675154 ( 38.964196)
The Ractor version is almost 7 times faster, and utilises all 12 cores nicely :-) The linked images are just screen shots from Apple’s Activity Monitor, but shows one core in use vs. all 12 cores.
The “3x speedup for ruby 3” goal was announced quite some time ago; presumably they are comparing it to the ruby that was around at the time the goal was announced.
It’s proponents claimed it superiority for years… And now all the mainstream dynamic languages try to add at least some static types. But you can’t just put it there easily, it needs to be baked into the heart of the language.
Languages like C++, Java and C# have been getting welcome additions like var, auto and polymorphic lambdas. There is virtually no modern language that requires you to specify the type of your iterator and good riddance, too. Let’s say that there is a convergence.
Moving static typing to tooling and giving hints to help that tooling is part of the convergence just like statically typed languages losing boilerplate is. There is no pedestal you can climb to say “they were wrong we were right all along”.
It’s a Christmas miracle!
I am quite excited about the Ractor. I have never used Ruby, but from reading about it, it seams to be a very pragmatic implementation, where backwards compatibility is handled by saying “be aware not to use globals between two Ractors. On a lower level it is handled by a per thread interpreter with GIL. Much like Python’s sub interpreter ? Maybe it’s time for a Pactor in Python? :-)
I did a small test of the
tarai.rbcode mentioned in the article, but with 12 Ractor’s on a 6+6 core Apple MacPro Intel Xeon. The output from the program:user system total realseq 252.199854 1.154537 253.354391 (253.580377)par 423.186306 1.488848 424.675154 ( 38.964196)The Ractor version is almost 7 times faster, and utilises all 12 cores nicely :-) The linked images are just screen shots from Apple’s Activity Monitor, but shows one core in use vs. all 12 cores.
Non Ractor Using 12 Ractors
Seams like a very promising implementation, I hope the people in the Python community pays attention to this.
This is exciting, I think I’m going to try out a Ruby project now.
Am I the only one who thinks its a bit disingenuous to benchmark against 2.0 instead of 2.7 when claiming a 3x speed up?
Otherwise, this is great news for the ruby community.
The “3x speedup for ruby 3” goal was announced quite some time ago; presumably they are comparing it to the ruby that was around at the time the goal was announced.
Yeah, see https://blog.heroku.com/ruby-3-by-3 (2016) for example
Static typing… So cute.
At least try to explain why something is a poor design instead of dismissing it.
Seems quite close to Python’s type hints. Not mandatory to use at all, but if used correctly, it massively helps you find bugs.
Yes, they can’t fix the wrong design, only put some patches on it here ant there.
What wrong design do you have in mind?
Dynamic typing.
It’s proponents claimed it superiority for years… And now all the mainstream dynamic languages try to add at least some static types. But you can’t just put it there easily, it needs to be baked into the heart of the language.
Languages like C++, Java and C# have been getting welcome additions like var, auto and polymorphic lambdas. There is virtually no modern language that requires you to specify the type of your iterator and good riddance, too. Let’s say that there is a convergence.
Var, diamond etc. means that your code is still statically typed. You just don’t need to write the type by hand because it’s obvious for the compiler.
It can look similar to dynamic languages… But type inference is static typing to it’s core (it isn’t by chance this comes from ML family).
Moving static typing to tooling and giving hints to help that tooling is part of the convergence just like statically typed languages losing boilerplate is. There is no pedestal you can climb to say “they were wrong we were right all along”.
No. They were wrong. And that’s why they now need to add boilerplate.
You need to be statically typed to be safe and you need a good type system to be safe and remove boilerplate.