Ruby: We have decided to go forward to 3.0 this year • Hacker News Board

Re: Ruby: We have decided to go forward to 3.0 this year

#101

Post by schneems » Tue, Sep 01, 2020, 4:19 AM UTC

hinkley wrote: post #70

owens99 wrote: post #33

Earlier quoted context omitted.

Look for tenderlove’s comments on TruffleRuby. The performance is at the expense of memory.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores. I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will ma…

> GIL

FWIW the GIL has been the GVL since YARV was merged in and it became based on a virtual machine rather than purely interpreted. I believe this was 2.0.

> because the number of copies you run will be proportional to the number of cores you have, not the number of machines

While this is true, Ruby is also very CoW optimized so while forks grow linerally in size (with count), usually the first fork is drastically smaller than the process it was forked from.

I work at Heroku and recommend perf settings to customers. 5 years ago people were mostly hitting memory limits. Now it's pretty common to see apps that are maxing out the CPU well before coming close to ram limits.

Especially when compared to javascript, Ruby is extremely memory efficient.

I agree with your larger statement but wanted to chime in and expand on those two points.

Re: Ruby: We have decided to go forward to 3.0 this year

#102

Post by schneems » Tue, Sep 01, 2020, 4:21 AM UTC

3np wrote: post #98

hinkley wrote: post #70

Earlier quoted context omitted.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores. I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will ma…

NodeJS is single-threaded while Ruby has native threads and "fibers" - what makes you say you wouldn't be able to utilize additional cores in Ruby?

Fibers are still restricted by the GVL. Threads are also restricted by the GVL. The only "true" concurrency in MRI is to fork a process.

Re: Ruby: We have decided to go forward to 3.0 this year

#103

Post by schneems » Tue, Sep 01, 2020, 4:21 AM UTC

jashmatthews wrote: post #89

hinkley wrote: post #70

Earlier quoted context omitted.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores. I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will ma…

There are some important differences here between NodeJS and Ruby. NodeJS child processes are completely independent and created with spawn. https://github.com/nodejs/node-v0.x-archive/issues/2334 CRuby forks using fork() and Copy-on-Write shares memory from parent to child. JRuby doesn't have a GIL so you only need a single process. Same with TruffleRuby. With CRuby, you're much better to run a bigger container with…

> JRuby doesn't have a GIL

Neither does CRuby! It's been the GVL since YARV was merged ;)

Re: Ruby: We have decided to go forward to 3.0 this year

#104

Post by winrid » Tue, Sep 01, 2020, 4:26 AM UTC

3np wrote: post #98

hinkley wrote: post #70

Earlier quoted context omitted.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores. I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will ma…

NodeJS is single-threaded while Ruby has native threads and "fibers" - what makes you say you wouldn't be able to utilize additional cores in Ruby?

You can. You can with Node too.

With Node you can just use workers. I have tools I wrote in Node that can max out my 16 core MacBook.

Re: Ruby: We have decided to go forward to 3.0 this year

#105

Post by 3np » Tue, Sep 01, 2020, 4:30 AM UTC

winrid wrote: post #104

3np wrote: post #98

Earlier quoted context omitted.

NodeJS is single-threaded while Ruby has native threads and "fibers" - what makes you say you wouldn't be able to utilize additional cores in Ruby?

You can. You can with Node too. With Node you can just use workers. I have tools I wrote in Node that can max out my 16 core MacBook.

Some major differences here are how they interface with I/O and the mechanisms around memory sharing.

Nodejs workers are more like webworkers and mostly suitable for proper CPU-intensive parallelization whereas in Ruby it's not uncommon to run e.g. multithreaded web server in the same process and namespace.

Re: Ruby: We have decided to go forward to 3.0 this year

#106

Post by bradleybuda » Tue, Sep 01, 2020, 4:31 AM UTC

hdoan741 wrote: post #91

bradleybuda wrote: post #55

Earlier quoted context omitted.

Our team has been using Sorbet at getcensus.com for almost a year now, and I'm generally very happy with it though it's not perfect. Like most non-trivial Rails apps, our test suite takes a while to run, so I like having Sorbet to catch "dumb" issues without having to run the full suite. Running `srb tc` to check types is incredibly fast and seems to be scaling well as our codebase grows. It catches the obvious stuff…

sob on sorbet-rails j/k. sorbet-rails maintainer here. I agree with the assessment that sorbet doesn't go out of the way to support some Rails feature, eg method overloading or scoping block accurately. Sorbet tool is opinionated about some of the design choices that makes it hard to support Rails' extensive use of meta-programming. That said, Sorbet is still useful in checking the custom code we write on top of Rail…

I did not mean to put down sorbet-rails - it has been really useful to us and we appreciate all the work you and your team have put in to it!

But I do have the sense that building Rails apps using sorbet won't feel "first class" until we have some sorbet maintainers that use Rails or the Rails team starts adopting sorbet (or both!)

Re: Ruby: We have decided to go forward to 3.0 this year

#107

Post by desmap » Tue, Sep 01, 2020, 4:39 AM UTC

sickcodebruh wrote: post #48

I’m excited about performance improvements but thrilled at the idea of adding types. Has anyone here worked with Sorbet or a prerelease 3.0 in Rails and able to share some notes?

from Soutarowho who did the type system for Ruby 3:

We defined a new language called RBS for type signatures for Ruby 3. The signatures are written in .rbs files which is different from Ruby code. You can consider the .rbs files are similar to .d.ts files in TypeScript or .h files in C/C++/ObjC. The benefit of having different files is it doesn't require changing Ruby code to start type checking. You can opt-in type checking safely without changing any part of your workflow.[1]

So UX-wise I don't know. While it's nice to have them separated, you are just faster if you have types in the code in front of your face when the IDE warns. Otherwise you will context-switch on any warning/error. This could get significant since you code just based on the LSP's output sometimes for hours. The IDE could help here with showing the definition when warning but still, if you want to change the definition or want to see more than just a snippet you will constantly jump between files.

Also .d.ts files were introduced to type old code and as an fallback and as a secondary option, At some point, Matz and Soutaro need to integrate types into the language itself to get the same level of productivity other typed languages offer, eg. Rust/Go/TS.

The next thing is IDE support, anyone knows more?

[1] https://developer.squareup.com/blog/the-state-of-ruby-3-typi...

Re: Ruby: We have decided to go forward to 3.0 this year

#108

Post by wjossey » Tue, Sep 01, 2020, 4:41 AM UTC

schneems wrote: post #101

hinkley wrote: post #70

Earlier quoted context omitted.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores. I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will ma…

> GIL FWIW the GIL has been the GVL since YARV was merged in and it became based on a virtual machine rather than purely interpreted. I believe this was 2.0. > because the number of copies you run will be proportional to the number of cores you have, not the number of machines While this is true, Ruby is also very CoW optimized so while forks grow linerally in size (with count), usually the first fork is drastically…

Just want to reaffirm this post. I scaled ruby for a living for almost 8 years to millions of request per minute and this post is 100% accurate.

Re: Ruby: We have decided to go forward to 3.0 this year

#109

Post by unixhero » Tue, Sep 01, 2020, 6:19 AM UTC

open-source-ux wrote: post #38

mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

The Crystal programming language might also reach 1.0 this year too. Towards Crystal 1.0 : https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html

I am very bullish on Crystal Lang.

Here is a walkthrough:

https://youtu.be/DxFP-Wjqtsc

Re: Ruby: We have decided to go forward to 3.0 this year

#110

Post by tonyedgecombe » Tue, Sep 01, 2020, 7:23 AM UTC

rightbyte wrote: post #77

tonyedgecombe wrote: post #72

Earlier quoted context omitted.

I've often wondered if part of the problem was supporting Python 2 for so long and hence prolonging the pain.

Without that I think many would lose trust in Python and just switch language. I mean it has only been 11 years since Python 3.1/2.7 and that's probably a common lifespan for maintenance mode code projects? 3.5 is still supported and that one is 5 years old. Why the hurry.

Why the hurry.

Because some people will always leave it to the last moment or beyond. Meanwhile the Python team has had the overhead of supporting more code than necessary.