|
|
|
|
|
|
by stevebmark
930 days ago
|
|
|
I'm not surprised you don't consider the team you work on as overhead. But it is just that. This is a Rails only problem. This is not a problem that applies to other engineering ecosystems, because upgrades are easy to trivial in other ecosystems. It is a problem that shouldn't exist. It makes sense that the only way Shopify has found to do efficient Rails upgrades and keep using Rails is to dedicate a team to it and subsidize Rails core development. But this isn't a model other companies should follow. I don't see the JVM team as the same thing as a team dedicated to working off a project's core. The JVM team looks closer to the YJIT project. Making a JIT also calls into question Shopify's scalability: Rails was slow enough that they allowed a JIT to be built internally? That's quite the trade-off to make. |
|
|
That's the same team (Rails + Ruby)...
> Making a JIT also calls into question Shopify's scalability: Rails was slow enough that they allowed a JIT to be built internally?
You are conflating scaling ability with language speed, there is of course some relation between the two, but it's mostly orthogonal.
At the scale of Shopify (several thousands developers) having a few people focus on improving Rails and Ruby is a drop in the bucket and payoff immensely.
Rails and Ruby are both Open Source projects not backed by for-profit organization. It's perfectly normal for an user of such project to contribute patches... That's how Open Source is supposed to work...
There is plenty of organizations contributing patches to the Linux Kernel (Google, IBM, etc). Using your logic that means Linux is slow enough that Google allowed a new scheduler to be built internally?
That's quite the silly line of reasoning...