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

121–130 of 134 posts

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

#121

Post by eregon »

schneems wrote: post #103
jashmatthews wrote: post #89

Earlier quoted context omitted.

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 ;)

It's exactly the same thing though, isn't it? I use both terms interchangeably. And it seems the term GIL is better known than GVL.

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

#122

Post by eregon »

loic-sharma wrote: post #66
eregon wrote: post #36

Earlier quoted context omitted.

Which comments?

https://blog.heroku.com/ruby-3-by-3/

That's rather vague. But yes, no matter which JIT you always need some extra memory to run the JIT, and it creates a more optimized version while also needing the unoptimized version of the code, so it needs more memory.

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

#123

Post by hdoan741 »

bradleybuda wrote: post #106
hdoan741 wrote: post #91

Earlier quoted context omitted.

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!)

Yeah, I totally agree with this. In some way, it's the difference in philosophical approach of the two system that it'll be hard to reconcile. Eg: Rails favors convenience (method that just works under various condition), whereas Sorbet favors explicitness (no method overloading, typed struct class instead of hash)

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

#124

Post by jodrellblank »

chaosharmonic wrote: post #84
jodrellblank wrote: post #27

Earlier quoted context omitted.

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.

It still isn't default on Windows because they separated it from Windows so they could ship new versions of PowerShell faster than new versions of Windows are shipped[1]. The renumbering to the major version 7 was intended to communicate compatibility (via loading 5.1 internally where necessary).

I don't know that it's certain it ever will be default on Windows, IIRC the last things I read were that it might become an optional package in Windows.

[1] Six-monthly, now moving to annually to align with new versions of .Net Core.

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

#125

Post by throwdbaaway »

wjossey wrote: post #108
schneems wrote: post #101

Earlier quoted context omitted.

> 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.

The high memory usage of ruby still causes problem if the app is single-threaded. I scaled databases for ruby apps for a living for almost 8 years, and sadly single-threaded legacy ruby app is still a thing.

Anyway, in the single-threaded scenario, the app may appear to be CPU bound under the steady state. However, when some hiccup happens in a database or in another microservice, all the ruby processes could soon be blocked waiting for network responses. In this case, ideally there should be plenty of idling ruby processes to absorb the load, but it will be rather costly to do so due to the high memory usage.

There are potential fixes of course, but with trade-offs:

- Aggressive timeout: May cause requests to fail under the steady state

- Circuit breaker: Difficult to tune the parameters, may not get triggered, or may prolong the degraded state longer than necessary. Also not a good fit when the process is single-threaded, as it can only get one data point at a time.

- Burning money: Can only do this until we hit the CPU : memory ratio limit imposed by the cloud vendors.

- Multi-threading: Too late to do this with years of monkey-patching that expects the app to run single-threaded.

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

#126

Post by pizza234 »

jashmatthews wrote: post #73
pizza234 wrote: post #21

Earlier quoted context omitted.

Well, yes and no (althought the question is a bit open). It's more or less beta quality, and very primitive. It's discouraged to be used with Rails, so I'd be inclined to state that "we didn't get it yet". I'm also personally skeptical that the unusual approach (invoking a whole C compiler in a separate thread) will stand in the long term - but that's my own take.

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.

Are there any benchmarks available? It seems I can find very little (OptCarrot, some microbenchmarks, and some general assessments about usage with Rails), and a broad(er) overview is crucial to assess the overall performance (I suppose that you can have workloads where the performance degrades).

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

#127

Post by jashmatthews »

throwdbaaway wrote: post #125
wjossey wrote: post #108

Earlier quoted context omitted.

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.

The high memory usage of ruby still causes problem if the app is single-threaded. I scaled databases for ruby apps for a living for almost 8 years, and sadly single-threaded legacy ruby app is still a thing. Anyway, in the single-threaded scenario, the app may appear to be CPU bound under the steady state. However, when some hiccup happens in a database or in another microservice, all the ruby processes could soon be…

Dealing with latency variability is a Hard Problem™ and really not much to do with Ruby or process vs thread parallelism.

https://dl.acm.org/doi/pdf/10.1145/2408776.2408794

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

#128

Post by throwdbaaway »

jashmatthews wrote: post #127
throwdbaaway wrote: post #125

Earlier quoted context omitted.

The high memory usage of ruby still causes problem if the app is single-threaded. I scaled databases for ruby apps for a living for almost 8 years, and sadly single-threaded legacy ruby app is still a thing. Anyway, in the single-threaded scenario, the app may appear to be CPU bound under the steady state. However, when some hiccup happens in a database or in another microservice, all the ruby processes could soon be…

Dealing with latency variability is a Hard Problem™ and really not much to do with Ruby or process vs thread parallelism. https://dl.acm.org/doi/pdf/10.1145/2408776.2408794

Well, having more spare ruby processes / threads would make the app more resistant to latency variability, and could have made some incidents into nonevents.

Also, while I don't disagree that it is indeed a hard problem, I do have very good experience with an async java stack, where I didn't have to worry about things like this. As long as a sane queue limit is defined on let's say the jetty http client, if something bad happens at the other end, the back pressure would kick in by failing immediately the requests that couldn't make it into the queue. Other parts of the app would then continue to be functional.

So, I would contend that it has a lot to do with ruby high memory usage, made much worse when single-threaded, and it looks like ruby 3.0 still won't have a complete async story yet?

EDIT: I checked the link again, and it looks Jeff Dean was talking about latency at p999 or above? By "hiccup", I actually mean something that would increase avg latency by perhaps 5~10x times, e.g. avg latency of 100ms under steady state + timeout of 1 second + the remote being down. Sorry for the confusion. Here, I am lucky if people start caring about p95.

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

#129

Post by jashmatthews »

throwdbaaway wrote: post #128
jashmatthews wrote: post #127

Earlier quoted context omitted.

Dealing with latency variability is a Hard Problem™ and really not much to do with Ruby or process vs thread parallelism. https://dl.acm.org/doi/pdf/10.1145/2408776.2408794

Well, having more spare ruby processes / threads would make the app more resistant to latency variability, and could have made some incidents into nonevents. Also, while I don't disagree that it is indeed a hard problem, I do have very good experience with an async java stack, where I didn't have to worry about things like this. As long as a sane queue limit is defined on let's say the jetty http client, if something…

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 more than a decade.

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

#130

Post by throwdbaaway »

jashmatthews wrote: post #129
throwdbaaway wrote: post #128

Earlier quoted context omitted.

Well, having more spare ruby processes / threads would make the app more resistant to latency variability, and could have made some incidents into nonevents. Also, while I don't disagree that it is indeed a hard problem, I do have very good experience with an async java stack, where I didn't have to worry about things like this. As long as a sane queue limit is defined on let's say the jetty http client, if something…

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 production-ready state a few months ago, if we are being generous.

But good point about service mesh. Moving the circuit breaker responsibility to the service mesh would definitely help in my case, as the sidecar would have all the data points from the 10+ single-threaded ruby processes running in the same pod, and thus could make a much quicker decision.

Post reply on HN