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

Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

railsatscale.com

Post reply on HN
Print view View original

101–110 of 158 posts

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#101

Post by berkes »

fiedzia wrote: post #82
berkes wrote: post #50

Earlier quoted context omitted.

This hints at a false dichotomy. One that especially Ruby and Rails keep afloat. Productivity and Scalability(in performance sense) aren't opposites. Take Bash. Performs bad and is a guarantee for terrible productivity in a large category of software. But perfect for a niche. Take Java. Performs better than many, and allows for good productivity (if you avoid the enterprise architectures, but that goes for any langua…

> Productivity and Scalability(in performance sense) aren't opposites. They often clash with each other. Rust for example is a lot less pleasant to debug than interpreted languages and that is a loss of productivity.

Not in my case. Rust, for me, is much better for productivity than my other major languages Ruby and JavaScript. The main reason is type enforcement, which is why -for me- typescript is much more productive than JavaScript. A large category of bugs simply won't exist (are caught at compiletime). With Ruby, I'd have to write hundreds of edge-case unit-tests just to cover stuff that, with Rust is enforced compile-time for me.

The other reason is runtime speed. A typical Ruby test-suite takes me minutes to run. A typical Rails test suite tens of minutes. A typical Rust test-suite takes The last reason, for me, is editor/IDE integration: Rust (and TS) type system make discovery, autocomplete and even co-pilot so much more useful that my productivity tanks the moment I'm "forced" to use my IDE with only solargraph to help.

And debugging: sure! I've had reasonable success with gdb and ruby debuggers in the past. Rust's gdb isn't much better. But stepping through a stack in a rails project is a nightmare: the stack is often so ridiculous deep (but it does show how elegant and neat it's all composed!) that it's all noise and no signal. Leaving a binding.pry or even `throw "why don't we get here?!"` also works, but to call that "productive" debugging is a stretch, IMO.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#102

Post by Justsignedup »

byroot wrote: post #81
cowsandmilk wrote: post #52

Earlier quoted context omitted.

> The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. Most companies don’t have unlimited budgets. Performance-oriented organizations profile and then spend money where profiling tells them to. Shopify isn’t hiring people to contribute to MySQL or Redis internals. They hired a full team to work on Ruby internals, not just creating YJIT,…

Disclaimer: I'm a member of the Ruby & Rails infrastructure team at Shopify and Ruby committer. > Shopify isn’t hiring people to contribute to MySQL or Redis internals You are not wrong, but the main reason is that contrary to Ruby, MySQL and Redis are used by a lot of huge companies and are themselves owned by companies with full time people on it. In comparison Ruby is still mostly a volunteer ran project that rece…

thank you for that insight! If I had to guess, early on shopify had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether, but they chose that the benefits of ruby outweigh the benefits of java's performance. So now given that shopify is large enough spending $1MM to win $5MM on infrastructure yearly is easily worth it.

In any case, I am very grateful to Shopify because I think if they decided to switch over to java back in the day, ruby may actually be a mostly dead language by now.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#103

Post by pjmlp »

p8 wrote: post #96
pjmlp wrote: post #89

Earlier quoted context omitted.

Some Java people did, there is a reason why Ruby is hardly used outside Rails, while Java rules most of the backend workloads, a mobile OS, and plenty of embedded workloads.

There's also a reason Kotlin has become the language of choice for the Android development industry, Scala became a thing, and ThoughtWorks recommended against using JavaServerFaces.

Because Android team had some Kotlin shills that pushed for it with management blessing, and they are in bed with JetBrains for the Android IDE, that is why, and even them had to accept updating Java support, otherwise Android/Kotlin would lose the ecosystem of Java written libraries, hence Java 11 LTS last year, and Java 17 LTS this year going, back to Android 12 with APEX archives.

Scala became a thing indeed, where it is now besides Spark?

ThoughWorks is a consultancy that recomends whatever brings new projects.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#104

Post by pjmlp »

moonchrome wrote: post #95
pjmlp wrote: post #65

Earlier quoted context omitted.

A joke is this comment. All of them were faster and used less resources than a very slow interpreted language, by having JIT and AOT compilers, state of the art GC and great IDE offerings, even the niche ones had better tooling (Leksah and Merlin, versus nothing).

No they weren't - ASP.NET webforms and old EF was such a pile of shit it didn't matter how fast C# was (and back then it really wasn't, granted order of magnitude better than ruby/python, but way behind JVM). The applications built with it were dog slow and buggy - they couldn't even scale in enterprise setting. Haskell, OCaml, D with great IDE support in 2006 ? Do they have that even today ? I mean you're suggesting…

Stackoverflow and plenty of Microsoft shops are enterprise enough.

> Haskell, OCaml, D with great IDE support in 2006 ? Do they have that even today ?

I mentioned Lekshat and Merlin for a reason, way better than Ruby with TextMate and Sublime.

Yes plenty of people were using C++ for Web applications in 2000 - 2006, via Apache, ngix and IIS plugins. Microsoft had ATLServer, Borland/Embarcadero still ship their webserver to this day.

I can assert that plenty of Nokia Networks WebUIs, were powered by C++/CORBA and Perl back in 2006. Transition to Java started in 2005.

As did several CRM systems, like the original Altitude Software application server.

RoR is for people that don't care about performance to start with.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#105

Post by karmakaze »

lloeki wrote: post #59
alberth wrote: post #44

Earlier quoted context omitted.

No one disputes that Ruby is slow. But you picking “mirrors” in your analogy makes it sounds like a premature optimization. The reason why perf isn’t typically an issue with Rails is the design pattern is to leverage heavy caching. The use of caching is to address the slowness of Ruby.

The two major areas where caching is used in Rails are: - database queries - template rendering First one because round trip to db + running the query + allocating ORM result objects that otherwise get thrown away. Second one because allocating a ton of strings that get join'd and thrown away. > No one disputes that Ruby is slow. I am, because the blanket statement doesn't make sense without context. Also that view i…

Well objectively, one could say both Ruby and RoR are slow. The first via The Computer Language Benchmarks Game[0], and the latter via TechEmpower Web Frameworks Benchmarks[1].

In practice though the database is doing most of the work, most of the time so is typically slower than both.

[0] https://en.wikipedia.org/wiki/The_Computer_Language_Benchmar...

[1] https://www.techempower.com/benchmarks

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#106

Post by TheRealDunkirk »

pjmlp wrote: post #90
KronisLV wrote: post #70

Earlier quoted context omitted.

> Stackoverflow is doing just fine with Windows Server. Good for them! I guess it mostly depends on what you want to build your platform around, what the constraints are and what developer skillsets are popular in your market. > Java 6 would still blow the water out of Ruby's slow interpreter. Probably! I do recall major GC improvements starting from JDK 8 onwards, though when compared to Ruby even the older versions…

Yet, Ruby hasn't necessarly taken over the enterprise, beyond those stuck with Rails apps.

It's amazing to me that so many people make "stuck with Rails" arguments in the enterprise. It's extraordinarily clear to me, having worked in 3 Fortune 250's, that the single, most-attractive-to-management feature of alternative stacks like Java and Javascript is... dun dun dun!... MASSIVE project bloat! Justifying huge teams and years of development time, leading to huge budgets and personal power within the company.

As a single, full-stack guy, I've out-coded entire teams of Java programmers TWICE using Rails. And none of the projects inside even-a-Fortune-size company come anywhere near concerns about "scaling" like we're discussing here.

So my takeaway after decades of doing full-stack development (also with PHP and .NET) is that Rails absolutely murders every other stack for time-to-market or MVP or whatever time-based metric you want to us, and has no effective liability in performance. The only places were are even discussing this kind of scalability is on some of the highest-trafficked web sites in the world, and even then I'd bet real money that the team size and time to develop features are still killing it over other stacks that would "scale" better.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#107

Post by byroot »

Justsignedup wrote: post #102
byroot wrote: post #81

Earlier quoted context omitted.

Disclaimer: I'm a member of the Ruby & Rails infrastructure team at Shopify and Ruby committer. > Shopify isn’t hiring people to contribute to MySQL or Redis internals You are not wrong, but the main reason is that contrary to Ruby, MySQL and Redis are used by a lot of huge companies and are themselves owned by companies with full time people on it. In comparison Ruby is still mostly a volunteer ran project that rece…

thank you for that insight! If I had to guess, early on shopify had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether, but they chose that the benefits of ruby outweigh the benefits of java's performance. So now given that shopify is large enough spending $1MM to win $5MM on infrastructure yearly is easily worth it. In any case, I am very grateful to Shopify because I think if they decide…

> had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether

As someone who joined Shopify 10 years ago, my perception is that it wasn't an option.

At the time competition was fierce and the priority was to get new features to grow.

If you are a free service Twitter, with a strong network effect, it makes sense to retool to reduce your costs, as it's a primary factor in profitability.

If you are a B2B paying service like Shopify with little to no network effect to keep your leading position, halting features for years while you re-tool, re-train etc is a death sentence.

My (hot) take is that if Shopify had decided to switch over to Java back in the day, Shopify may actually be a mostly dead company by now.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#108

Post by brianwawok »

mabbo wrote: post #98
brianwawok wrote: post #94

Earlier quoted context omitted.

No he’s his examples he’s talking 50 stores over 10 machines vs 50 stores over 5 machines. Both would require the same DB count, but the second would save on server costs for stores.

I think the above means (if I do get the point) that databases scale in terms of both requests per second and number of active connections. Having 1000 connections doing 1 request per second isn't the same as having 1 connection doing 1000 requests per second. But, and I could be wrong, the larger factor is the number of requests per second.

This entirely depends on the database you are using, and if you are using a connection proxy in front of your database.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#109

Post by Justsignedup »

byroot wrote: post #107
Justsignedup wrote: post #102

Earlier quoted context omitted.

thank you for that insight! If I had to guess, early on shopify had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether, but they chose that the benefits of ruby outweigh the benefits of java's performance. So now given that shopify is large enough spending $1MM to win $5MM on infrastructure yearly is easily worth it. In any case, I am very grateful to Shopify because I think if they decide…

> had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether As someone who joined Shopify 10 years ago, my perception is that it wasn't an option. At the time competition was fierce and the priority was to get new features to grow. If you are a free service Twitter, with a strong network effect, it makes sense to retool to reduce your costs, as it's a primary factor in profitability. If you a…

Thank you for that insight. I think that is really great to surface. If your product relies on the ability to spin up new features, then inefficiencies in operating costs can be eaten up by the fact that the company functions. If you don't spin up features that quickly but operational costs is king, then you make different decisions.

In any case, it has been a pleasure hearing insights from the inside. Thank you.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#110

Post by p8 »

pjmlp wrote: post #103
p8 wrote: post #96

Earlier quoted context omitted.

There's also a reason Kotlin has become the language of choice for the Android development industry, Scala became a thing, and ThoughtWorks recommended against using JavaServerFaces.

Because Android team had some Kotlin shills that pushed for it with management blessing, and they are in bed with JetBrains for the Android IDE, that is why, and even them had to accept updating Java support, otherwise Android/Kotlin would lose the ecosystem of Java written libraries, hence Java 11 LTS last year, and Java 17 LTS this year going, back to Android 12 with APEX archives. Scala became a thing indeed, wher…

So where are the Shopify's of that era build on Struts and JSF?
Post reply on HN