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

111–120 of 134 posts

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

#111

Post by n0rbwah »

awill wrote: post #53
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.

Anyone who works in an enterprise with old code has been working on migrating Py2 for ages.

In 50 years, I bet they'll still be looking for python 2 developers to work on old python code...

Or not... it's not like you can't throw a python 3 dev at an old python 2 codebase and tell them to work on it. Even if that probably wouldn't make them very happy about it, they wouldn't be lost.

But I'd bet an arm that there will still be python 2 codebases running in production in the next decades with companies very unwilling to do the work of migrating it.

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

#112

Post by jashmatthews »

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…

CRuby could still be much better at CoW. In theory, a forked process only needs a similar memory allocation to a pthread. In practice the runtime writes in a bunch of these inherited pages and fucks it up. malloc-ed memory is usually bigger than the "Ruby heap" so that kind of limits the impact you can have by trying to not write/re-write.

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

#114

Post by oblio »

jashmatthews wrote: post #86
oblio wrote: post #74

Earlier quoted context omitted.

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

Yeah but it's not an important distinction.

Isn't it? Compiling C takes time, with Ruby you would be doing it for each execution. Is there some catching involved?

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

#115

Post by jashmatthews »

oblio wrote: post #114
jashmatthews wrote: post #86

Earlier quoted context omitted.

Yeah but it's not an important distinction.

Isn't it? Compiling C takes time, with Ruby you would be doing it for each execution. Is there some catching involved?

Almost everything is in a pre-compiled header. Its actually similar overhead to an LLVM based JIT.

You wouldn’t want to do it for a browser JIT but for a server side app it’s OK.

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

#116

Post by oblio »

jashmatthews wrote: post #115
oblio wrote: post #114

Earlier quoted context omitted.

Isn't it? Compiling C takes time, with Ruby you would be doing it for each execution. Is there some catching involved?

Almost everything is in a pre-compiled header. Its actually similar overhead to an LLVM based JIT. You wouldn’t want to do it for a browser JIT but for a server side app it’s OK.

Does Ruby ship with a compiler? How will this work on Windows?

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

#117

Post by stjohnswarts »

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!

Thanks for the update on Perl, good to know it's still kicking although I always hated its syntax :)

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

#119

Post by stjohnswarts »

n0rbwah wrote: post #111
awill wrote: post #53

Earlier quoted context omitted.

Anyone who works in an enterprise with old code has been working on migrating Py2 for ages.

In 50 years, I bet they'll still be looking for python 2 developers to work on old python code... Or not... it's not like you can't throw a python 3 dev at an old python 2 codebase and tell them to work on it. Even if that probably wouldn't make them very happy about it, they wouldn't be lost. But I'd bet an arm that there will still be python 2 codebases running in production in the next decades with companies very…

Is it really that hard to work on python2 code if you've only done python3, provide you have proper documentation and the web to look up quirks?

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

#120

Post by newen »

xiaodai wrote: post #87
rightbyte wrote: post #77

Earlier quoted context omitted.

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?

Python is not technically superior to other languages enough that you can rhetorically ask that question. It’s main advantage is the ecosystem and network effects. If a bunch of people, especially the people who work on numpy, scipy, etc., decide to work on developing libraries for other languages like R and Julia, the data science ecosystem would switch over in a few years. Similarly for other fields people might switch to languages like Elixir, Haskell, OCaml, Go, Swift, Scala, Ruby, Kotlin, etc.
Post reply on HN