Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster(railsatscale.com) |
Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster(railsatscale.com) |
> 1.27 million requests per second
> 3TB/minute of traffic
Each store can be assigned to one pod, each pod can have as many hosts as it takes to optimize the use of a database instance, and then you can add more pods as the need arises.
Edit: to be clear, that's not to say Rails can't scale. It can. It's just that it doesn't need to- you can scale anything with enough partitioning.
I'm sorry, but this is one of the silliest nit picks ive ever seen on this site. Of course 1 million rps and 3TB/s isn't coming from a single host. 3 TB/s is far beyond the throughput of any network I've ever seen, considered or thought of, short of maybe a data center (and I don't work in that domain). 1.3 million requests per second is far beyond the capacity of pretty much any hardware available right now.
Also what is the cost in man hours spent on optimizations and profiling.
Zero. Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006, and they would never have gotten off the ground and been another failed techbro startup that instead of getting shit done, bikeshedded over languages.
PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.
Partly, you need mobile now, so any Rails stuff is likely to be back-end and hidden. Plus big investors like to go for the exciting stuff.
But if you're looking at companies aren't household names (taking smaller amounts of investment), there are lots out there.
Syft (recruitment) were founded in 2016 and have revenues of over $100m per year - although that's partly due to acquisition by a larger competitor, so when I just looked, separating their valuation from the group wasn't immediately obvious.
I've freelanced and contracted across a few niche industries (construction, print, airport signage management!) where I was building something against competitor software that I discovered was at least partially built with Rails. Those big players in each niche would have revenue in the tens of millions and from what I could see, very small technical teams.
But anyone outside those industries would never have heard of these companies.
No exactly a fair question because Shopify is much older and is valued at 70B. For a company to have done it in half the time would have been impressive regardless of tech whereas on average it takes 7 years to become a unicorn.
I do know that Aircall is relatively young, on a good trajectory and runs Rails.
Even if a piece of software could only handle 1 request per second you could handle 1.27M requests if you just run 1.27M servers.
> Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT.
I'm hoping/assuming the increased memory usage is trivial compared to the cpu-efficiency gains, but it would be nice to see some memory-overhead numbers as part of this analysis.
If your memory usage doesn't plateau you have a memory leak which would be caused by a bug in your code or a dependency.
But 500 to 1gb of memory required for a production rails app isn't unusual. Heroku knows this, which explains their bonkers pricing for 2gb of memory. They know where to stick the knife.
Most businesses fail. Those that don't fail, usually don't have interesting scaling issues. (You can go a really long way on a boring monolith stack.)
So in most cases, whatever gets things out into the world and able to see if the business can be validated makes sense, and then you optimize later. A nonscalable stack that you can iterate on 50% faster is more likely to produce a viable company than a more scalable stack that's slower to work with.
If you're a hired employee, it's easy to forget that the place you're working for is already a big exception just by the virtue of it grew large enough to hire you.
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 language). Or take Rust. Productivity much higher than most C/C++ and in my case higher than with Ruby/Rails, and also much more performant.
They don't need to do any of this. The product is fast enough. They make money. It's purely to fatten the bottom line.
What's the current state of Shopify running TruffleRuby, given the tragic loss of Chris Seaton?
Especially with native images, I wonder how that would turn out.
Rails proper, yes. Small rails app are generally drop-in compatible, but sizeable applications are likely to run in a few compatibility issues as most gems aren't tested against TruffleRuby.
> I wonder how much TruffleRuby would improve the performance and memory footprint.
The generally speaking Truffle is much faster at "peak" performance, but take very long to get there which makes it challenging to deploy.
It also uses way more memory, but it's partially offset by the fact that it doesn't have a GVL, so you get parallel execution with threads.
It's good to see Ruby doing the same. There is something neat about the same code running faster, solely by being on an upgraded platform.
https://www.reddit.com/r/PHP/comments/16hu7dq/php_is_getting...
For 3.2 there also was an improvement of the interpreter:
> We now speed up railsbench by about 38% over the interpreter, but this is on top of the Ruby 3.2 interpreter, which is already faster than the interpreter from Ruby 3.1. According to the numbers gathered by Takashi, the cumulative improvement makes YJIT 57% faster than the Ruby 3.1.3 interpreter.
> All that work allowed us to speedup our storefront total web request time by 10% on average, which is including all the time the web server is blocked on IO, for example, waiting for data from the DB, which YJIT obviously can't make any faster.
My rule of thumbs:
Python has similar performance characteristics as Ruby.
With Java/C#/Go you’d expect about an order of magnitude of improvement.
With naive Rust/C++ you would likely be at the same average speed as Java for web applications but with less memory usage. Well until you make an effort to produce faster code.
Ruby atm is working towards implementing true parallell execution with Ractors for example, and now with YJIT, the performance might increase some more.
OOC, why isn't this part a ruby default? Isn't it always better to be more memory efficient. (I'm trying to understand what the trade offs are, if any)
EDIT: well, exactly 6 minutes later, I'm done. I followed these instructions: https://elements.heroku.com/buildpacks/gaffneyc/heroku-build...
The app seems to work like usual, I'll just have to wait and see what happens to memory use.
I will reply here in 12 hours with a screen shot showing the results (before/after memory use), whatever they may be.
Also, for reference, here's the metrics for the past 24 hours (LOTS of memory problems): https://imgur.com/a/M8IHd5z
The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing.
The "weakest link" belief is pure conjecture
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, but also on CRuby’s memory layout, hiring the lead on TruffleRuby, and funding academic programming language research on Ruby.
No company has an infinite budget to “optimize everything”. It is clear where internal performance testing pointed Shopify (at Ruby) and with double digit gains being extracted year after year, their profiling didn’t lie. And other Ruby on Rails shops are seeing similar double digit performance wins, not on fake benchmarks, but on actual page load times and traffic that can be handled by a server.
Mercedes 2022 https://www.the-race.com/formula-1/mercedes-2022-f1-car-make...
Williams 2019 https://www.autosport.com/f1/news/williams-modifying-front-s...
Ferrari 2018 https://www.autosport.com/f1/news/how-ferraris-formula-1-mir...
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.
If rails were half as fast, you'd need twice as many rails hosts (but no more databases).
Sort of. Twice as many rails hosts means more DB connections which generally means more load/memory on the DB or more load/memory on the external connection pooler.
It's only a bit of incremental load, but it's easy to overlook how many other systems need to run to make Rails scale.
Primarily it's not the language that makes people more or less productive, though it does have some influence. It's mostly the frameworks in those languages. And traditionally the most modern / full-featured web frameworks haven't been in systems languages. The major counterexample at the moment (while still obviously not a systems language) is that modern JS VMs are actually really fast, so while I don't love JS, it does hit that sweet spot at the moment of performance and mature frameworks.
Also, I've never worked in Rust, but am mostly a systems programmer, and while I understand that Rust is supposed to be easier than C or C++, I'm skeptical that it's as easy to work with as higher level languages, or that you could throw most web developers into Rust without some serious additional learning.
That's another problem I have in this narrative. Productivity isn't measured by throwing an inexperienced developer at something and then looking how fast they get stuff done. That's learnability.
I'm an experienced Rails developer (some 15 years in) and my productivity has plataued for years now. I've been doing Java and Rust work for years too now. Web and application dev. It took years, but my productivity in both Java and Rust, on anything that lives longer than 6months, has vastly surpassed that of my Rails.
Productivity of a senior, or experienced dev, of a (large) team, of a team with high turnover, of a project over decades, all that is productivity too. And in all those categories, Rails isn't great.
That's all correct.
But the point I'm making is that if an MVP isn't accruing technical debt, it's over-engineered. Most of them will be thrown away, or rescoped, and so taking on technical debt is an advantageous strategy: you only have to pay the technical debt on the few survivors.
Shopify at its offset was a CRUD app (fun fact: it started as a snowboarding shop), and in 2006, Rails was a great choice for that.
Your notions are fine for an established company building a piece of infrastructure they're certain they'll need. But that's not what Shopify was, and it's not the spot most startups picking a framework are at.
Your thing about developer quality is kind of meh. Building the first versions of a shopping platform isn't rocket surgery. You don't need Anthony Bourdain to make a sandwich. Particularly if you're not sure anybody wants a sandwich.
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.
It looks like memory usage did indeed go down, and critical errors fell by about 84%.
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 < a minute to compile and seconds to run. I run my tests hundreds of times per day. With a typical Rails project, I'm waiting for tests upwards of an hour per day (yes, I know guard, fancy runners with pattern matching etc).
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.
Then I did Ruby+Rails fulltime for 9 years. Just recently moved on.
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.
It was one of my major concerns about Ruby, prior to starting out. But like... it just wasn't a problem.
It turns out that we just don't pass the wrong kind of thing to the other thing very often, or at least I and my teams did not. It certainly helps if you follow some sane programming practices. Using well-named keyword arguments and identifiers, for example.
# bad. wtf is input?
def grant_admin_privileges(input)
end
# you would have to be a psychopath to pass this
# anything but a User object
def grant_admin_privileges(user:)
end
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.
I strongly dispute that you need extra tests for "edge cases" because of dynamic typing. Something is deeply wrong if we are coding defensive methods that handle lots of different types of inputs and do lots of duck typing checks or etc. to defend themselves against type-related edge cases.
(yes, I know guard, fancy runners with pattern matching etc).
The last reason, for me, is editor/IDE integration
But stepping through a stack in a rails project is a nightmare
What I'm arguing, however, isn't to take on debt¹, I'm saying that productivity and performance aren't always opposites.
Sure, Rails trades in performance for productivity. But, I've learned, this is mostly just Rails. There are many languages and frameworks that are just as productive (for a certain definition, see previous comment) as Rails, but also performant. And I'm arguing that performance affects productivity: a performant, scalable software is easier to work on, because it gives faster feedback (tests, ci, manual testing), wastes less time waiting for stuff (hundreds of single seconds add up over days and weeks weeks), and decreases friction (I'll postpone running the full test suite if I know it'll hog my machine for the next half hour. I'll gladly run it, if it takes a few minutes or less).
Edit: and, if what you say about tech debt is true (I think it is), wouldn't Shopify be at a position now to pay it back? Many startups that used Rails paid it back by migrating elsewhere. So maybe Rails in its entirety is Tech Debt?
¹A cautionary sidenote, that I've learned the hard way, is that taking on tech debt is an art in itself. Not all debt is alike. Many kinds will cripple my project. Where at the unlikely moment that I do need to scale, that's impossible. Or when I do need to pivot for the umpteenth time, we cannot, without that Giant Refactoring.
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.
- 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 is largely biased by the typical assumption that Ruby == Rails.
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...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Given that the predominate / vast majority use case for Ruby is for web development and Rails being the dominate Ruby web framework ... it's a fair assumption & characterization for people to make that the Ruby == Rails use case.
> 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 receive little funding and effort relative to its importance.
As for why trying to make Ruby faster at all in the first place. It's not because it was too slow, it's mostly just that at our scale, the engineering time spent on optimizing the runtime pretty much pays for itself.
But that's nothing specific to Ruby, in most very large software companies you will find similar efforts. e.g. I remember Twitter had a team working on the JVM, etc.
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.
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.
The bizarre part here is that anyone who paint themselves into a corner with ruby, then decide that they need to implement an entire new fancy VM instead of just find targeted bottlenecks and rewriting them in C++. They writing complicated native programs to make a VM that is only 15% faster when they could rewrite specific sections that are slow and speed those up by 200x or more.
That is not correct. Ruby do unmap pages when it has too many free pages, and it obviously call `free` on memory it allocated once it doesn't use it.
What happens sometime though is that because of fragmentation you have many free slots but no free whole pages. That is one of the reason why GC compaction was implemented, but it's not enabled by default.
But in most case I've seen, the memory bloat of Ruby applications was caused by glibc malloc, and the solution was either to set MALLOC_ARENA_MAX or to switch to jemalloc.
On the last fairly large rails app I tried to use jemalloc on there was no change in memory usage. I believe that advice is a bit outdated. Also note using jemalloc doesn't cause memory to be freed to the system. It reduces fragmentation, at the cost of cpu cycles. There's no free lunch.
Yes, because extra empty pages are released at the end of major GC, which is occasional, and most web application will cyclicaly use enough memory that they will stabilize / plateau at one point.
> I believe that advice is a bit outdated.
It absolutely isn't, your anecdote doesn't mean much compared to the countless reports you can find out there.
> Also note using jemalloc doesn't cause memory to be freed to the system.
Yes it does, it has a decay mecanism, most allocators do. https://jemalloc.net/jemalloc.3.html
> It reduces fragmentation
Yes, and that allows it to have more free pages that it can release.
> at the cost of cpu cycles
Compared to glibc, not so much.
That’s why good modern allocators like mimalloc and tcmalloc return memory when they notice it’s going unused, so that other services running on the machine can access resources. And this is in c++ land where things are even more perf sensitive.
But if you really do need to cheap out you can generally configure your app server to kill idle worker processes, or bounce them on a schedule to return memory to the system, and hope.
Killing “idle” processes is also extremely expensive because you have to restart the process, reload all state, and doing graceful handoff is tricky.
It’s good to have graceful handoff for zero downtime upgrades, but I still say having your allocator return RAM is the cheapest and easiest option and something good modern allocators do for you automatically.
Extremely bold claim for a framework the size of ruby on rails. I would trot out my own evidence but the receipts are lost with time.
Also—why isn't the allocation behavior tweakable at runtime? Seems pretty trivial with no downsides. It's not difficult to think of a scenario where a non-monotonically-increasing-heap-size is desirable.
Memory management is handled by the language.
In any case, it has been a pleasure hearing insights from the inside. Thank you.
All the production quality app servers handle killing and and starting new worker processes gracefully and efficiently by forking a running process. Certainly there is some overhead, but that's why you don't underprovision memory, so you don't need to resort to that.
That's absolutely not something Rails does, but it is something that some managed languages and some (most?) allocators do.
Those warrant unit tests. Those will regress. Those would never exist in a strongly typed language (though Java still has null...ugh)
It's true that 99.9% of production log errors are NoMethodError exceptions.
annnnnd 99.9% of those NoMethodErrors are just code not handling nils/nulls correctly
annnnnd 99.9% of those unhandled runtime nils/nulls are from external data (user inputs, database data, etc)
So strong typing doesn't help you there at runtime, it just blows up differently.
It really does, though. Not with the Java-type of strong typing (still allows null) but with the Rust type of strong typing. Simply because it moves all this to the edge. At the point where you read the CSV/database/HTTP-response/user-input.
Everything inside of this edge (a strong boundary) doesn't need to to deal with "can this be nil" because it can't. Your `the_outlier(items: Vec<Measurement>)` will simply not compile if the type-checker sees that `items` can be nil, `items` can contain a nil, or, internal to that function an items[].measured_at might be nil, or maybe items[].measured_at is a Date instead of a DateTime.
You don't need a bazillion tests to deal with this situation around `the_outlier()`. That doesn't mean that the part that reads a Vec<Measurement> from a CSV (or json, or database or whatever) is covered by this typechecker. But it means this layer, the edge, the boundary, is where you put the protection. Validation, whatnot.
I had an app once where we used user objects, and later switched to ids to save db calls. Now you have some functions that can accept both, and some that accept one of them, and without type hints (that was long time ago) you can easily make a mistake.
Ruby has had keyword arguments since Ruby 2.0 from 2008 and earlier code could certainly use option hashes.
So I don't see a reason for any confusion there.
# probably malpractice in a system where many methods
# take IDs and some take Users
def do_something_with_user(user)
end
# how hard is this? trivially easy and unambiguous.
def do_something_with_user(user_id:)
end
# this is obviously wrong
do_something_with_user(user_id: User.first)
GP’s sarcastic “rails doesn’t scale” implies that it would also be a great choice for people starting afresh in 2023. The reply asks for a comparison with other languages popular in 2023, especially ones that are known for being more performant (lower memory and CPU consumption, lower latency).
And that’s when you’re dragging the conversation back to 2006. It’s not 2006 anymore.
If you're Github or Shopify and can throw (waste?) engineering years at solving a framework specific ecosystem nightmare problems, and have the klout and runway to hire core Ruby and Rails maintainers, then you're probably in a highly unique situation and could use any framework you want.
The rest of us don't see Rails as a great choice for Github. Doubt and questioning.
[1] https://videos.itrevolution.com/watch/550704376/ [2] https://youtu.be/GfhPeOiXDLA?t=725
That's a weird way of framing it.
They stuck with a fork of Rails 2.3 for a long time because the upgrade was deemed too costly, not because their fork was faster.
In the end their performance patches were either outdated or contributed upstream, and they are now on Rails main branch.
And while it was a fork, it was still largely "Rails".
But one thing we can’t measure - how many candidates chose to join Shopify and GitHub because they were keen to work on Ruby? Java had a reputation for being boring, while Ruby was fun and exciting. Their success was possibly tied to this, but we’ll never know for sure.
In 2023 the calculus of what language to choose is different. But these companies are just glad they succeeded while others didn’t.
Ruby is still a great way to start it up. Consider that in 2006-2008, it's deployment story was horrible. Since then, the ruby ecosystem bootstrapped lockfiles, 12 factor app manifesto, and a lot of the conventions we all take for granted nowadays. And while there are certainly enough arguments to bikeshed on, its still a rock solid ecosystem.
> PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.
You already stated the obvious: PHP and Ruby apps generated far more revenues simply by existing longer.
Google has a lot of revenue. Pinterest, Hashicorp, Uber, Twitch, Dropbox, etc. all have a good amount of golang and collectively have a lot of revenue. It might need a few more years to tip the scale, but it's closer than suggested here.
Going for .NET/C# would have likely limited anyone to using mostly Windows Server for their infrastructure. Not that it's a bad OS, but .NET Core was released only in 2016 and although Mono came out in 2004, sadly it never got the love it deserved and was rather unreliable (otherwise we would have seen way more cross platform development before .NET Core). Oh, also, turns out that LINQ (which is pretty cool) was only released in 2007, though that still puts them a bit ahead of Java I guess, although I can't comment on when it landed in Mono.
Going with Java would have meant using something like Java 6, whereas the first truly decent version (in my eyes) was Java 8, which came out in 2014. Of course, the older language version and runtime wouldn't be a huge issue, however projects like Spring Boot only came out in 2014 and before then most people would either use Spring, Java EE (now Jakarta EE) or a similar framework from back then. I've worked with both and it wasn't pleasant - essentially the XML configuration hell with layers of indirection that people lament.
I mean, either would have probably been doable, but it's not like other stacks are without fault (even the ones I cannot really comment on).
Java 6 would still blow the water out of Ruby's slow interpreter.
Being pleasant isn't relevant for performance.
Haskell, OCaml and D are niche languages, probably aren't mature enough now to use for a production system that needs to scale (in terms of org growth and building complex systems).
Java web frameworks were also terrible in 2006 (this is the Java era that gave Java it's reputation) and the only thing worse for productivity I can think of is C++ hahaha ...
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).
The trap is when you start growing and it is hard to change. Because the features that took 1-2 months in RoR might take 3-4 months (or more!) to port to another language, and do you really want to stop your working business when it isn’t a problem?
Because Rails performs totally fine at small-mid startup scale. It’s only when you start getting a couple years old with lots of users that it starts to bite you. But at that point you already have gotten further than 90% of startups ever even make it. And at that point, honestly there are solutions for that too, like gradually pulling the poor-performing bits out into faster languages.
Writing this as someone who works for a startup that uses RoR, and I’ve seen it blow up over several years. I curse RoR daily because it pisses me off, but I don’t think this company would’ve gotten this far if it didn’t have the RoR speed at the beginning.
So are you better off starting your company on Go/Rust/Java? Maybe. But if getting to market fast will help you win, it’s hard to beat RoR.
This is such an absurd take. Do you really think startups lose runway because of the runtime performance of their code, and not failing to achieve PMF, overhiring, or spending too much on stupid techbro bullshit?
Zswap is always performance increasing. Swap to disk can be performance degrading (good implementations generally are not unless your working set is larger than your memory and you’re in thrashing) and certainly expensive $$ wise in that it wears out your SSD faster.
You seem to be thinking I’m arguing in absolute terms where all I’m saying is that swapping is a more expensive technique to try to reclaim that unused RAM vs the memory allocator doing it. It can be a useful low-effort technique, but it’s very coarse and more of a stop gap to recover inefficiencies in the system at a global level. Global inefficiency mitigation is generally not as optimally effective as more localized approaches.
Consider also that before the OS starts swapping, the OS is going to start purging disk caches since those are free for it to reload (executable code backed by file, page caches etc). These are second order system effects that are hard to reason about abstractly when you have a greedy view of “my application is the only one that matters”. This means that before you even hit swap, your large dark matter of dirty memory sitting in your allocator is making your disk accessed slower. And the kernel’s swap doesn’t distinguish working set memory from allocator so you’re hoping inherent temporal and spatial locality patterns interplay well so that you’re not trying to hand out an allocation for a swapped out block too frequently.
What comes next might not even be better, but that won't matter, because what came before won't be cool anymore.
You die a hero or live long enough to become the villain.
For app server nowadays u have many choices. But 15 years rails was really the only better choice for a few men's startup shops. C# was on windows shop, that's a no for many
> We forked rails and _practically wrote our own._ We fought against the framework. We deviated from the framework, and we even wondered if rails was right for us at all.
and
> Rails 3 was found to be five times slower than Rails 2
I regularly talk with engineers that worked on that project at GitHub, some are now my coworkers. I know more about this effort than what was said publicly.
> Rails 3 was found to be five times slower than Rails 2
This is a bogus claim. It might have been 5 times slower on some pathological cases, it absolutely wasn't 5 times slower overall.
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 would probably be decent: https://blogs.oracle.com/javamagazine/post/java-garbage-coll...
It would actually be fun if someone pulled out the old versions from back then and did some benchmarks, though maybe asking someone to build a full stack application in such a dated tech would be a tough ask, unless they're passionate about it!
> Being pleasant isn't relevant for performance.
If the discussion is just about performance, then that's true.
If we look at things realistically, then there's more to it - like using a tech stack that allows you to iterate reasonably quickly, as opposed to making your developers want to quit their jobs every time they have to debug some obscure Servlet related bug or to work with brittle configuration in XML (been there dozens of times), to the point where not as much could even get built in a given amount of time with a particular stack due to its challenges.
I do hate when people say that additional nodes are way cheaper than developer salaries, but they're also correct most of the time. Of course, there's also the humanitarian take to just not forget about the developer experience, otherwise we'd have written all of our web software in C++ even back then. It'd work really fast, but we'd have way less software in general.
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.
Haskell, OCaml, D with great IDE support in 2006 ? Do they have that even today ?
I mean you're suggesting people use C++ for writing web apps (and c++98/03 no less !) - that's got to be facetious.
The real contender back then was PHP and Java, RoR really addressed a lot of issues from both. They both adopted the improvements brought by it since, but it took years.
> 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.
You are interpreting both links you gave in terrible ways.
It sounds like you’re seeing the pain GitHub suffered through rose colored glasses. The talks about GitHub Rails upgrades say it took years and caused burnout.
The conclusion of Eileen's talk is that by not following with upgrade and essentially forking Rails 2.3 they painted themselves in a corner. They took short term gains, and produced longs term losses. It's a self induced problem.
In the end they upgraded and are now tracking the main branch, so the problem wasn't Rails.
Scala became a thing indeed, where it is now besides Spark?
ThoughWorks is a consultancy that recomends whatever brings new projects.
Ruby didn't even exist back then and was released a year later. Rails was released in 2004. Shopify was founded in in 2006, 12 years after Amazon.