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

#131

Post by jashmatthews » Thu, Sep 03, 2020, 12:36 AM UTC

throwdbaaway wrote: post #130

jashmatthews wrote: post #129

Earlier quoted context omitted.

That's not an inherent property of a particular language or concurrency model, though. That's having logic to track request queue depth for a particular service or endpoint and fail fast/load shed. You can do the same in Ruby! Some would probably say this is what a service mesh is for. Maybe you're thinking of the new Actor based model for compute parallelism? Async IO in production Ruby has been a thing for easily m…

Of course it is not an inherent property of a particular language or concurrency model, but it is a property of a particular language ecosystem . As a turing complete language, everything is doable in ruby, but at what cost? Now we are back to trade-offs I listed above. As for async IO in production, looking at the client library, https://github.com/socketry/async-http is barely 3 years old, and probably reached the…

https://github.com/socketry/async-http is just a new client library. PostRank, Zynga, CloudFoundry were all running async IO in production on Ruby ~10 years ago. CRuby support for non-blocking IO dates back to the mid 2000s. https://github.com/eventmachine/eventmachine actually dates back even further

If you're using Unicorn then you've already got Raindrops which gives you a really simple way to do shared metrics across forked processes like in-flight requests to another service or how many of your Unicorns are busy.

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

#132

Post by throwdbaaway » Thu, Sep 03, 2020, 7:58 AM UTC

jashmatthews wrote: post #131

throwdbaaway wrote: post #130

Earlier quoted context omitted.

Of course it is not an inherent property of a particular language or concurrency model, but it is a property of a particular language ecosystem . As a turing complete language, everything is doable in ruby, but at what cost? Now we are back to trade-offs I listed above. As for async IO in production, looking at the client library, https://github.com/socketry/async-http is barely 3 years old, and probably reached the…

https://github.com/socketry/async-http is just a new client library. PostRank, Zynga, CloudFoundry were all running async IO in production on Ruby ~10 years ago. CRuby support for non-blocking IO dates back to the mid 2000s. https://github.com/eventmachine/eventmachine actually dates back even further If you're using Unicorn then you've already got Raindrops which gives you a really simple way to do shared metrics ac…

EventMachine has been losing steam for awhile now, which is why I brought up Async as the new hotness. I don't think it is fair to classify async-http as "just a new client library". As of now, in the ruby ecosystem, the Async framework is the only player in town. From my perspective, it still looks pretty much unproven, but perhaps we just live inside different bubbles.

It kinda feel like we are talking past each other here. I would just like to clarify that I inherited all these different ruby apps, and I don't have the magical ability to go back in time and say "Hey, perhaps we should use an async framework from the beginning" or "Dude, enough with the monkey-patching". And even if I do, those could be bad advice, as the ruby apps are making money in production.

Anyway, thanks for the suggestion to share metrics across processes. That will definitely help with the circuit breaker decision making in my case.

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

#133

Post by tom-lord » Thu, Sep 03, 2020, 3:27 PM UTC

riffraff wrote: post #43

anonova wrote: post #9

Earlier quoted context omitted.

From benchmarks [1], 2.8.0 (with jit) is ~2x faster than 2.0.0p648 [2]. [1]: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b... [2]: https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...

notice the "3x3" goal is on a specific benchmark (optcarrot), not on all workloads.

There's no such thing as a performance measurement "on all workloads".

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

#134

Post by n0rbwah » Fri, Sep 04, 2020, 7:32 AM UTC

stjohnswarts wrote: post #119

n0rbwah wrote: post #111

Earlier quoted context omitted.

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?

No, they made a big deal of giving a ten-years period to developers to port their code before depreciating python 2.

But honestly, there are more breaking changes between two versions of ruby than between python 2 and 3. And during the time python 2 was still supported (until the last day of 2019), most features that made it into python 3 and could be backported were backported into python 2.

It will be a pain for those who aren't used to python 2 encoding errors and other nice stuff that they got rid of in 3 to make it a nicer and more robust language. And the will miss the new and shiny features that will make it in new python 3 version after python 2 EOL.

But apart from that, it's almost the same language, they just made the transition from 2 to 3 to be able to introduce some breaking changes in places that unfortunate design choices had made their way into the language and couldn't be rolled back because people running python 2 in production depended on those. So they upped the major version, introduced some breaking changes (but not that much really) and gave developers 10 years of support for the older language so they could port their codebase to the new version.

And porting a python 2 app to a python 3 app isn't such a hard task. But! If you've got a big app that's working now, even if the changes aren't that drastic, you can't be sure that the port won't introduce some hard to find bugs that will be a pain to debug. Hence why plenty of companies are still running python 2 versions of their apps and will do so for the forseeable future.

But, throwing a python 3 dev at a python 2 codebase is totally doable, it's just that the guy or gal will miss the shiny stuff that didn't get backported into 2 and will break their teeth on some behavioral changes between the two languages.