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

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

github.com

Post reply on HN
Print view View original

81–90 of 134 posts

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

#81

Post by chrisseaton »

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…

TruffleRuby doesn't have a GIL though.

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

#82

Post by rmccue »

digianarchist wrote: post #25
shinepl10 wrote: post #6

Earlier quoted context omitted.

You forgot about PHP going to v8

JavaScript really does take over everything.

I know this is a joke, but we’re legitimately running v8 as a PHP extension in production on high-traffic sites. It’s actually quite good for server-side JS rendering when you’re working inside an existing PHP framework (WordPress, in our case).

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

#83

Post by pansa2 »

oblio wrote: post #74
jashmatthews wrote: post #73

Earlier quoted context omitted.

The CRuby JIT is stable but whether it improves performance or not is workload dependent. It's simple not primitive. MJIT is designed to take advantage of a C compilers optimization. "Compile to C" worked for Chicken Scheme for the past 20 years and continues to be a popular way for functional langauges to compile. It's also how Nim works. It's all about different trade-offs.

Chicken Scheme compiles ahead of time, doesn't it?

Nim does too.

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

#84

Post by chaosharmonic »

jodrellblank wrote: post #27
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!

PowerShell 7 released in March, dropping the “Core” name, gaining backwards compatibility and becoming the main version. https://devblogs.microsoft.com/powershell/announcing-PowerSh...

It still isn't default on Windows yet, though, because it doesn't have full parity with the legacy version.

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

#85

Post by chaosharmonic »

randomdata wrote: post #76
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!

At that rate, next you're going to tell us that Go is going to get generics.

Or JavaScript getting a new name.

(Or Java getting new maintainers...)

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

#86

Post by jashmatthews »

oblio wrote: post #74
jashmatthews wrote: post #73

Earlier quoted context omitted.

The CRuby JIT is stable but whether it improves performance or not is workload dependent. It's simple not primitive. MJIT is designed to take advantage of a C compilers optimization. "Compile to C" worked for Chicken Scheme for the past 20 years and continues to be a popular way for functional langauges to compile. It's also how Nim works. It's all about different trade-offs.

Chicken Scheme compiles ahead of time, doesn't it?

Yeah but it's not an important distinction.

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

#87

Post by xiaodai »

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.

What r they gonna switch to?

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

#88

Post by core-questions »

cortesoft wrote: post #61
Alex3917 wrote: post #39

Earlier quoted context omitted.

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

Someone forgot to tell my company...

That someone is now you, innit?

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

#89

Post by jashmatthews »

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…

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 multiple processes than one process per container.

With either NodeJS or CRuby you're still better to run less containers on bigger hosts. Each host has to duplicate the host OS and container infrastructure. Each container of a real production app also duplicates a bunch of stuff despite Docker's best attempts at sharing.

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

#90

Post by hdoan741 »

pqdbr wrote: post #52
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?

I'm also very excited for Sorbet. Not because of types specifically (I don't use them and don't plan to), but because I hoped it would give me the same linting experience that ESLint gives me on JS files (unused variables, undefined methods, calling methods on nil, and so on). The sorbet demo ( https://sorbet.run/ ) is all I could wish for (you can remove the type signatures and see that it would still warn you about…

@pqdbr: sorbet-rails maintainer here. We make the library to bridge the gap between sorbet & Rails. If you have any issue with setting up sorbet and/or sorbet-rails. Hit me up with issues on the repo and I'll try to help!
Post reply on HN