Hacker News Reader

Comment by skrtskrt | Hacker News Reader

I have now worked at several significantly-sized companies that ripped Ruby out of everything as they scaled, usually replaced with Go, though none as large as Shopify.

I wonder what that financial calculus looks like between these options for a large organization:

1. trying to basically reinvent the workings of an entire programming language and migrate your Ruby apps to these new tools/runtimes/typecheckers/whatever

2. incrementally rewriting critical paths to something more performant (Go/Rust) & just throwing more servers at the Ruby stuff you haven't managed to replace yet.

View on HN

> significantly-sized companies that ripped Ruby out of everything as they scaled

I am assuming Ruby, used here meant Ruby Rails. Or specifically, ripped Rails out of everything as they scaled?

The calculus, in many situation would indeed be in flavour of another framework or language in ~2013. The cost of CPU Core has dropped significantly since then, we are not far from having 128 x86 CPU core in a single socket. Even if could only do 10 request per second per core at a target latency, this is 1280 Request per second on a single server. ( In the context of a non API serving App, or Server rendering App )

Edit: Miscalculation here, it should be 128 Core, 256 vCPU, so 2560 RPS.... but the main point still stand.

But at the Scale of Shopify, ~$33B Market Cap ( ouch.....I remember they passed $100B market cap in 2020 and $200B market cap in 2021... ) They could finally afford to pour some resources into Ruby. The only Top 10 programming languages without large cooperate resource backing. I am pretty sure the performance potential of YJIT and Ruby tooling has a ROI of less than 2 years at their Scale.

https://shopify.engineering/porting-yjit-ruby-compiler-to-ru... ??

is the jit. did you understand the art?

So? What is your point?

Probably not a financial decision.

Tobias (Founder/CEO) was an early Rails core contributor. So Ruby on Rails is in Shopify DNA.

My personal experience is that the bulk of the time these rewrites don't end up delivering the performance increases that people expect because they don't really understand what's making the prior system slow and don't develop good enough requirements

This is not saying you shouldn't, it doesn't really matter to me. But I think a lot of the time this is driven by engineers who feel like they need to do this rather than a financial decision to save money

My experience is along the following lines (same for Django as well actually):

1. Company started as Rails monolith

2. Some components of the Rails monolith stretch Ruby capabilities beyond where "throw more servers at it" is still reasonable or effective

3. Factor out some backend functionality into dedicated services which can be scaled separately, Rails still serves as the API gateway calling these services. Anything without scaling issues stays in the monolith for now.

4. Eventually Rails is just an API gateway, no one in the org knows Ruby/Rails and its dependency management madness any more, and it gets replaced with a more-performant, purpose-built API gateway, usually something off-the-shelf.

The fully loaded cost of even three or four software engineers in the USA outstrips 99% of companies cloud computing budgets.

A lot of the time, I ask myself, "why don't we seem to have a tool with robust source-to-source transformation?" You could call it "cross-language refactoring". I wouldn't be surprised if someone with the code-base the size of Google has some internal tool. Maybe this is just wishful thinking. The closest thing I've seen is in academic research, e.g. [1].

[1]: Koppel, Solar-Lezama - Incremental parametric syntax for multi-language transformation (2017) - https://dl.acm.org/doi/10.1145/3135932.3135940

The cost of this challenge is likely bigger than the market. How many large code bases need to be translated from X to Y? Probably not very many. There are only so many legacy COBOL systems.

Big issues off the top of my head.

Legacy support. Legacy code is already difficult to understand. If it was originally written in another language that would only make it harder to grok.

Transpiled output is often ugly. Developers in general seem to dislike modifying generated code for a number of reasons. I imagine transpiled code would end up implicitly frozen, and new code would only be added to new files.

Language idioms are hard to translate. Some structures are unique to languages and their equivalents may be considered bad in other languages.

You would either need equivalent libraries in new languages or also translate dependencies. You could probably find equivalent libraries, but their scope may vary.

Large scale code organization varies between languages. Things like Dependency Injection may not translate at all. Some languages may use config and some use code for the same thing.

I mean Google did essentially do this: https://opensource.googleblog.com/2017/01/grumpy-go-running-...

Except without actually solving the problem of making the translation nice and readable. But this kind of thing at least gives you options for changing language.

Idioms and features often don't match up between any two languages. For example, what do you do with monkeypatched code when porting from Ruby to Go?

There are some tools specific to some transformations at least:

https://c2rust.com/

> trying to basically reinvent the workings of an entire programming language and migrate your Ruby apps to these new tools/runtimes/typecheckers/whatever

Facebook is probably the best example of this with PHP and Hack [1]

1. https://en.m.wikipedia.org/wiki/Hack_(programming_language)

Reply on news.ycombinator.com