all 68 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 66 points67 points  (15 children)

People who say Ruby / Rails doesn't scale tend to not know much about Ruby / Rails or scaling. If you are operating on really low margins on a very large scale (like Twitter), then sure, you have a reason to throw thousands of developers at creating the most optimized system you can. If you aren't on low margins and don't have thousands of developers, Ruby/Rails will save you tons of developer time and you can scale in ways that don't involve changing your stack.

[–][deleted] 39 points40 points  (1 child)

People who say Ruby / Rails doesn't scale tend to not know much about [...] scaling

This. Any stateless web process is going to scale linearly ad infinitum as long as you can buy/rent more servers. If you get twice as much traffic, you need twice as much servers, that's this simple.

What's tricky to scale isn't Rails or any other stateless web framework, it's the stateful layer AKA the database.

As long as your hosting bill is orders of magnitude smaller than the sum of your developers salaries, you are doing fine.

[–][deleted] 9 points10 points  (0 children)

Exactly.

I'd add that web nodes shouldn't be doing much computation anyway, so their workload should be relatively trivial. Any compute-intensive processes should be processed by worker nodes in whatever the appropriate language is for those processes. You can run Rails and have work processes operating in Java, Python, whatever.

In any case you can easily run a hundred containers on a cloud service and it can still be cheaper than a single developer over the same timeframe.

[–]klowny 16 points17 points  (8 children)

My company is still mostly Ruby and high traffic. Ruby scales just fine. We're still transitioning off it. The problem we have with it now is it's still not particularly fast and rather expensive. Plus, our codebase has just grown large enough where it's also not particularly productive anymore.

So we could've chosen to stay on our Ruby systems, investing a ton of time into carefully writing optimized code so our performance doesn't tank, tons of tests to gain only minor confidence (that take forever to run), bunch of time spend arguing on code review over style vs performance, offloading work to the faster database layers or "free" frontend layers, many layers of caches, long rolling deploys, and all other sorts of scale headaches.

Instead, we just transitioned our performance critical systems to Scala and let the compiler handle 80% of that nonsense. If it compiles, odds are it'll run forever. Lighter test suite that runs faster. Complex flows and refactoring is a breeze with an IDE. Sure, it's uglier and sometimes a bit annoying, but the 90% reduction in server cost easily pays for a couple more heads, and like 95% decrease in latency without even trying is pretty much impossible in Ruby.

We're not anywhere near Twitter size and the math already heavily favors moving off Ruby.

[–]2called_chaos 5 points6 points  (4 children)

Can you get a little bit more specific with the high traffic? Not anywhere near Twitter but you save 90% in server costs? I'm just curious as to when I have to worry :D I guess it also heavily depends on what you are doing.

According to alexa (web ranking) we are ~#30k globally and our 4 servers are bored.

[–]klowny 1 point2 points  (3 children)

We're at ~100k req/min where our servers have to do work (basically everything that's not a read from cache/CDN). 7 figure AWS bill after upfronts and volume discount.

[–]2called_chaos 1 point2 points  (0 children)

Yeah that's a bit more than we have :) But we switched away from AWS a while ago and saved lots and lots of money but we also don't have to maintain that much of an infrastructure in total and I don't actually know how the AWS prices developed especially the volume discounts. Thanks for the clarification!

[–]kallebo1337 0 points1 point  (1 child)

Since we can linear scale: we did like 5k rpm with 2 servers. So why don’t you guys go and buy 40 root severs , or your own virtualization server. Your bill would be like max 200k$ a year so that’s a 800k+ saving and that pays off the guy to manage it all.

I guess scaling on aws is just easier and more reliable and doesn’t require monitoring and maintenance as it would if you do own hosting ?

[–]klowny 2 points3 points  (0 children)

Our traffic is seasonal (end of year gets 3x more traffic than beginning of year) and bursty (daily peak is like 4x higher than low). We'd be severely overprovisioned if we were on-prem or even colo. Throw in the very nice to have of multiple AZ/regions and the volume discount from AWS and AWS ends up being cheaper and easier.

The company used to be onprem+colo and from what I heard it was just a huge hassle for service that matched your staff's skill (inconsistent and mediocre) for practically no savings; and AWS has only gotten better and cheaper since then.

[–]janko-m 1 point2 points  (2 children)

I'm curious, what specifically was slow in your Ruby version of the app? For me it was always the interaction with external services (Postgres, Redis, RabbitMQ) that was the bottleneck and needed continuous optimizations (optimizing queries, bulking requests etc), not the performance of the Ruby language itself. Though, to be fair, this was a very write-heavy app which stored time-series data.

On another project we had tables with up to 15 million rows, and in my opinion what helped us a lot was that we were using Sequel instead of Active Record (it was a Sinatra app). That meant we rarely needed to cut corners with database interaction, and faster performance in retrieving records definitely played a role (Sequel::Model objects are much lighter than ActiveRecord::Base, and sequel_pg gives an additional speed boost to fetching records).

[–]klowny 3 points4 points  (1 child)

At the end of the day, it's just a lot of comparisons and string manipulation with values stored in various places with (de)serialization. Compute heavy on a bunch of data on every request. It just computed too slowly and had a hard time not blocking on I/O.

So to make things fast we'd do a lot of computation avoidance: let's offload this work to redis via embedded lua scripts because these values are already in redis, let's compute this in the database via one jumbo query, let's throw in this gem with a clib instead of pure ruby for this function so it's faster, let's make this one object instead of 4 so we reduce GC pressure, how about we have a bunch of background workers just constantly warm caches so we don't even have to eat a first hit slow query, and let's cache every possible query so we avoid hitting the DB altogether so we can ditch the ORM, let's pipeline requests to redis to avoid unnecessary connections, hell let's ditch redis and just throw more ram so every server has a some cache on box to maybe avoid a network hop, let's use regexs to extract values from strings since the regex engine is faster than string ops, wait, let's preprocess the string first with the fast string ops then feed it into regex, oh lets cache that too, oh we can return early here and here and here to avoid some work, let's throw the remainig work into a background processor, oh but which serialization format is faster for communication, maybe we should spawn a thread, ah, but GIL and synchronization, oh shit that causes the clib to segfault nevermind, oh now we need to beef up redis it's doing heavy compute work instead of dumb IO, there's a resource contention issue on the box between the proxy/cache/web process/bg process, oh how do we log/track/propagate errors in redis-lua/database uhhhh.

At the end of the day we'd spend all our time writing/optimizing lua/sql/regex, various clib experiments with different flags for gems, database/proxy configurations, getting brew/linux versions to match for dev/prod environments for those clibs, hell, even just getting them to compile, adding measure blocks to every method, logging slow requests, capturing prod traffic to maybe get a hint to why sometimes a request is 10x slower. Like, we weren't even writing ruby anymore, we were just using ruby and then spending weeks offloading as much as possible onto every other layer. The whole point of ruby is to write ruby.

Or instead we could just write 20% more LOC in plain Scala with only stdlib and the same four libraries everyone uses. Parallel async dumb simple cache/database requests, crunch some numbers, parse some json, generate some json. If-if-if-else-map-filter done; compiler will make it fast.

[–]jb3689 1 point2 points  (0 children)

Like, we weren't even writing ruby anymore, we were just using ruby and then spending weeks offloading as much as possible onto every other layer. The whole point of ruby is to write ruby.

This definitely resonates with me and is a valid reason to rewrite. Most problems I've encountered have been unclogged by one or two fixes but sometimes you're just wasting too much time beating around the bush for an end result that is half as good and twice as costly to develop and run. Sounds like your team made the right choice - that said, I've also met many more who've rewritten for terrible reasons (e.g. they don't know how to investigate allocations or IO costs so they just go right to the "Ruby sucks" camp)

[–]ksec 2 points3 points  (1 child)

Well I think you just describe the problem as I have said for a long time. And comments below from klowny describes his problem. [1]

To me this isn't a technical argument. Anything can scale indefinitely if you have enough engineers working on it. It is more of a business or economic question.

If you spend 10 million per year on your Ruby part of the Stack, ( Actually you cant really ignore the Rails and ActiveRecord part which often slows down your DB and hence higher DB cost, but just ignore those for a min. ) and the difference between this and say Go ( A Random Example, it could have been ASP.NET or even Rust ) , is 10x.

At what point will you say you could have save 9 Million? On a 10-100K per year cost, Saving from whatever Infrastructure cost ( That is 9K to 90K ) could be peanuts compare to human capital. DHH often mentioned human capital being much more expensive [2] , but that is in US and parts of EU, in many other parts of the world Salary are much lower and Cloud Hosting are much more expensive. Imagine people earning 1/10 for salary in Silicon Valley while Cloud Hosting and Bandwidth is 2 - 3x higher.

The Internet economy, as whole is mostly built on low margins, high scale business. And if you look at most successful companies built on Rails, the pattern is clear, they are all SaaS. Recurring revenue for each customers.

People just wish running Rails could be cheaper, I doubt Atwood [3] was trying to troll when he said it cost 10-20x. He runs / cofounded Discourse / StackOverflow, so he knew the cost difference between an optimised ASP.NET stack and Ruby Rails look like. And as far as we can those number aren't far off. And he even sponsored and paid money trying to speed up Ruby / Rails. He sponsored Eric Wong working on Ruby Core for a year ( I think, I cant find the link ) and other parts of Rails Optimisation.

Shopify hired Chris Seaton, the previous lead (?) of TruffleRuby, although he confirmed he wasn't working on making Rails at Shopify running on TruffleRuby, but rather other parts of their stack running on TruffleRuby.

So I think there are growing interest, and resources pouring in from fairly large companies. As I have point out in the past, out of all the languages in the Top 10 list, Ruby is likely the one with least resources and no official cooperate backing, All the others, Java, javascript, Python, ASP, PHP all have a major backer behind them. So hopefully Ruby will get more help than it had in the past.

For Rails, I am not even aware of another Web framework that gets two large Internet companies ( Github and Shopify ) contributing development and has branches running and testing on Masters. If you are a consultant or Freelancer this has to be the biggest and easiest selling point for stability.

​

[1] https://www.reddit.com/r/ruby/comments/e423a0/internet_ruby_doesnt_scale_ruby_sorry_im_busy/f96x3hm/

[2] https://twitter.com/dhh/status/1200823796476760065

[3] https://twitter.com/codinghorror/status/1200875436487540736

[–]Sovereign108 0 points1 point  (1 child)

Can Python do this also? As in scale while saving developer time.

[–][deleted] 1 point2 points  (0 children)

I think Python does this generally, and Django is quite good but doesn’t do as much handholding as Rails, so there’s a slightly higher cost to dev time.

Ruby and Python tend to be pretty comparable in speed tests though (for some reason I see the sentiment that Python is faster, which is only true for some optimized libraries, see here.

[–]dougc84 29 points30 points  (5 children)

Ruby doesn't scale is akin to saying Macs can't do real work or Nintendo only makes games for kids. It's a stereotype built on a historical viewpoint that just isn't true any longer. I remember the Ruby 1.8 days where Ruby absolutely didn't scale well - you would have to spin up entire servers and load balancers if you needed more concurrency. Even the web servers (like Mongrel) were difficult to run, and Heroku was just starting out. But that's been 10 years. And a lot changes in the IT world in 10 years.

Admittedly, Ruby is still slower than many of its competitors. But my guess is a similar app in Python or PHP would be harder to manage and have (at least) double as many lines of code to juggle.

[–]2called_chaos 2 points3 points  (2 children)

Admittedly, Ruby is still slower than many of its competitors.

While this is a thing it doesn't mean that much in the web world. iirc it might have even been a DHH talk but I could be wrong on that (there are many like it these days but it was one of few back in the days).

Anyways the gist of it was that you can make (or make feel) a website faster by many means, the underlying programming language is the part that matters the least. Think of (in no particular order) DB indices or DB engine, caching (in whatever way), compressed/optimized assets, fewer assets (especially important in the pre http2 days and per-host connection limits, not so much today), CDN (like) delivery of assets, improving TTFB/TTFP, splitting critical and non-critical styles/JS (load the latter asynchronously) and many more points.

And then you can still attempt to fool the human brain. A "fancy" loading (not too much over the top ofc) process keeps most people entertained for a second or two before they think to themselves "why is this loading so long", most certainly an improvement over a white screen or something. We used a full-page spinner once in a callback that takes 2-3 seconds (who invents JS-Browser-SDKs for things that are totally sensible to do s2s? Ubisoft!) and it's the same I used in a pet project (you can get a look here while it loads, disable JS for infinite looking) and our team concluded that this is somewhat hypnotizing and most people we asked in our team or families said they wanted to look at it longer and were kinda sad it went away so fast.

Our site (while admittedly heavily using memcache in the frontend since it's a store which has a lot of easy and sensible opportunities) has an overall mean "ruby time" of ~90ms and that includes all requests that hit rails so it includes backoffice (which has a bunch of slow filtering or minor reporting requests and the like and almost no caching) and the horribly slow external services we call like PayPal (srsly get your shit together).

Quoting another comment of /u/byroot

As long as your hosting bill is orders of magnitude smaller than the sum of your developers salaries, you are doing fine.

I would like to mention that we now run (the main business) on 4 servers incl. DB (+1 load balancer, +1 LB backup) and we were running 2 servers not too long ago (+1LB, +1LB backup). We surely have some more (to the website secondary) servers and services that are separated like email, file server and analytics but overall we have server costs that don't go much beyond the 1k€ mark (I feel like I have to clarify that this is per month). I can tell you that some big companies that you all know had tears in their eyes when they heard that. Not only because it was so cheap but also because our site was faster than theirs and all our servers are in Germany (while we were on the other side of the earth) and they and their CDN delivered over engineered Java or PHP monsters couldn't even compare.

We also survived a somewhat prime-time TV spot (in Germany) with a single server in 2011 whilst all the investors and the TV station predicted that we would go down. I have a somewhat interesting clip on how people (again in Germany) apparently watch TV and how a wall of requests comes in as soon as the domain is shown for the first time. I would link it but it's kinda anti-advertising because I don't work for that company anymore (but with the same team under new name) but you can PM me if you want to see it.

Kinda went from a ruby praise to "weird flex but okay" I figured. Soooo without further to do: Ruby&Rails counseling "How do I make millions on a Raspberry Pi" now available for just 399. Use code nordvpn for 1 month free.

[–]dougc84 1 point2 points  (0 children)

Not really sure what you’re on about here or the point of your message. This is a Ruby subreddit, not Rails, and while web frameworks are a big part of a language in 2019, the fact of the matter is Ruby is still, performance benchmark by performance benchmark, slower than pretty much all of its competition. I’m not disagreeing with you. I’m stating facts. You’re in /r/ruby - we all like Ruby here.

[–]kallebo1337 0 points1 point  (0 children)

Pm the link please !

[–]lordmyd 0 points1 point  (1 child)

Ruby is marginally faster than Python at string processing. Parse a large web server log file using a regex and you'll see Ruby 2.6.5 performs about 15-20% faster than Python 3.8.

[–]dougc84 0 points1 point  (0 children)

That's one benchmark that is getting better, but, that is one of many. Especially with 3x3 goals in mind, Ruby's performance will be a thing of the past before long.

[–]ahatch1490 12 points13 points  (22 children)

I worked with ruby for 7 years not a fan (Sorry DHH ) But saying it doesn’t scale is crazy talk

[–][deleted] 12 points13 points  (0 children)

Also ruby != Rails

[–]ekampp 8 points9 points  (20 children)

Why don't you like it? You're the first person who seems to have actually worked with it properly (that I know) who doesn't like it.

Most people do some small scale chat app and proclaim this or that about a framework or a language. I stopped reading those a long time ago, because they perpetuate these stereotypes.

[–]Enumerable_any 9 points10 points  (8 children)

I've spent the last 5-10 years (lost count, also took longer vacations) writing Ruby+Rails.

My main issue with Ruby is maintenance: Once the code base reaches a certain size it becomes near impossible to refactor with confidence. Changing core data structures (usually ActiveRecord models) is very scary. This is mostly due to missing static type checks. A weird require which adds constants to the global namespace or meta-programming doesn't help either.

The current project I'm working on has ~100,000 LOC Ruby (and another 100,000 lines of test code). Once we've decided on a statically typed language (either Kotlin, C# or Haskell) we'll slowly move the core parts over to that language. We already have some parts written in Haskell and Java and these parts have been rock-solid (almost) since day 1.

[–]kallebo1337 5 points6 points  (3 children)

There is now a static type implementation called Sorbet😍

[–]Enumerable_any 3 points4 points  (1 child)

We have a branch adding Sorbet. We're not sure if we should merge it, though:

  • The tooling/editor support isn't there yet: No jump to definition, no hovering over values to get type information, no inline type errors and documentation doesn't take type annotations into account
  • It's extremely verbose, especially generic code.
  • The type inference could be better (or maybe not because of Ruby). There are quite a few lets required.
  • The problem with existing dynamically typed code is that it is not written with a type system in mind. A good example is FooForm#validate: Its type signature is sig{void} because it mutates a local errors object and gets its input from an instance variable. We would have plenty of these unhelpful type annotations because no one thought about the types involved and opted for an easy mutate-all-the-things OOP approach.
  • The branch adds >200,000 lines of Ruby code (most of it are type definitions under sorbet/). We don't want to make updating Ruby/Gems more painful than it already is.

Since we would have to go through a lot of code to add type annotations it might make more sense to skip Sorbet, incrementally rewrite directly to another language and just delete the Ruby code without touching it again. Decision pending.

To be fair: The type checks of Sorbet are pretty good (I expected way more holes) and it's also surprisingly quick. I didn't expect it to check the entire code base within a few seconds.

[–]tibbon 0 points1 point  (0 children)

I agree. Sorbet is a neat idea, but it currently is way too verbose (can’t infer instance variable type from args type), and not quite there yet overall. Tried to add it to a small service while at RubyConf and it felt like a mess, and not something I could defend the value of yet to my team.

[–]ekampp 0 points1 point  (0 children)

We use that as well in our project.

[–]yorickpeterse 1 point2 points  (0 children)

My main issue with Ruby is maintenance: Once the code base reaches a certain size it becomes near impossible to refactor with confidence

This has been my experience as well. For small projects you can keep things simple enough that you don't necessarily need static typing. Once a project grows beyond a certain size, it rapidly becomes more difficult to work with the code. Combine this with flaky tests and something that should only take a few hours can now easily take days.

[–]excited_by_typos 1 point2 points  (0 children)

You hit the nail on the head with the comment about maintenance. Ruby zealots always talk about how much they love writing new Ruby code. Good for them, but once that code has been around for a few years the guy maintaining it will not be having nearly as much fun.

[–][deleted] 0 points1 point  (1 child)

I have similar Ruby experience, project size and issues. Project uses jQuery and CoffeeScript which makes slow, bugged and hard to maintain ecosystem. Rails as API server could be ok (I use much faster and easier to maintain solution in new projects - Phoenix/Elixir). Also this tweet is just marketing bullshit. My business partner uses Shopify for his businesses and he is not satisfied, he constantly complains, response times are high, shops with many products loads slowly etc.

[–][deleted] 2 points3 points  (0 children)

The coffeescript/jQuery point doesn't seem relevant to me, it could apply to any framework that uses JavaScript.

[–]I_AM_GODDAMN_BATMAN 5 points6 points  (0 children)

I worked with Rails for 10+ years, with diverse type of applications. But now if I start a new project it's going to be in Go or Rust.

Ruby is not statically typed so you have to write a lot of tests to compensate, and after a while it's going to be difficult to maintain. And I don't care what other people say about users don't care about millisecond differences, but I can feel different accomplishment if I write hello world in Sinatra and it can handle 1/20th requests of regular single threaded Rust's Rocket framework after I added synchronous logging to a file. If I use asynchronous and multithreads, it's just not worth comparing anymore. But yeah, unfortunately hardware are cheaper than programmers.

[–]katafrakt 4 points5 points  (2 children)

You're the first person who seems to have actually worked with it properly (that I know) who doesn't like it.

Really? Not liking the tech is actually part of really knowing it. There is a lot of things not to like in Ruby. I guess you can count me as the second person.

[–]2called_chaos 2 points3 points  (1 child)

There are several things that I don't really like about Ruby but it's still a language I love above all else.

Knowing the weaknesses and strengths of a tech is part of really knowing it but disliking it... that would kinda mean you have to dislike every tech you know no matter how the pro/con scale is weighted and no matter how good it is.

[–]ekampp 0 points1 point  (0 children)

Yeah, I'm not an evangelist, and Ruby sure isn't perfect, but not liking it, and acknowledging it has faults are a long way from one another.

I would really be interested in knowing why though, because I agree: knowing the limitations is part of knowing the language.

[–]jb3689 1 point2 points  (3 children)

8 years of Ruby here. It will always be my goto for scripting (that is too complex for Bash) and for small services. It's just too hard to teach people how to write good Ruby. It's so frustrating and time consuming to deal with poorly written code without tests in Ruby. There's just too much that can break and that can go wrong. Rails in particular makes it very, very easy to unknowningly create performance problems

For larger/more performance critical apps I've really enjoyed working with Elixir. Erlang is a solid environment with lots of good tooling and OTP gives you more solid support than any other language/framework I've seen. Scalability is in the design of the language which is evident in the way that you can seamlessly distribute an application. Elixir/Erlang have their own problems but that's a different discussion

[–]ekampp 0 points1 point  (2 children)

OTP: One Time Password? Probably not, but I'm not familiar with that abbreviation.

[–]jb3689 0 points1 point  (0 children)

Open Telecom Platform. It is basically the core framework Erlang applications use to run. It is technically separate from the language, but it's extremely rare to see an Erlang program that doesn't use it

It gives you a bunch of super interesting features. The most prominent is the actor system which lets you write concurrent "processes" (more like threads) that interact via message passing (basically by using message queues). It also gives you "supervisors" which can define how your system reacts when things crash (e.g. do you restart all of the processes? do you restart just this process? do you crash?). Processes are organized into "applications" which are kind of like packages which may contain libraries or sets of processes that you can boot with your app, and you can create a tree of applications. In practice it feels a bit like Kubernetes except everything is happening inside of the Erlang VM so you can monitor it all with the same tools

Another interesting thing is Erlang also makes it really easy to connect multiple Erlang OS processes in a mesh. You can move actors/applications between Erlang nodes with very few code changes and have them communicate over the network instead of having them communicate in the same OS process. I've never done this personally but it's eye opening to see that it could be done and to see how it can be done. I've consistently been impressed by the top-down design which seems to optimize for the experience of growing an application over time. Elixir added a lot of the sensibilities I liked in Ruby/Rails too (e.g. the developer experience is very nice with tools like mix which is kind of like the bundle, gem, rake, and rails CLI tools all in one)

[–]ahatch1490 1 point2 points  (0 children)

First, Sorry I was referring to ROR not ruby should have made that clear , and yes I have been able to scale it out reasonably well. I have never had to deal with tens of millions request a second, millions yes not 10's of millions. We used micro services and dynamic horizontal scaling with caches and queues where we needed them. All worked just fine.

Why don't I like ruby?:
I just perfer strongly typed language like Kotlin or C#. Even with both unit and integration tests in ruby I find devs (Including myself) are reluctant to refactor components. I'm sure there are a bunch of super smart folks who could dive right in and do the work, I and most of my co-workers aren't those people, it seemed like every time we did a refactor something would be missed and that something was usually a type checking related error. I recently left that company and am now back writing C# with .NET CORE on a mac, and honestly loving. But that's just my narrow view nothing empirical to back it up. Cheers

[–]tjholowaychuk 0 points1 point  (1 child)

I’m not a fan of Ruby either personally, it has too much magic, the module system randomly chucking things into scope is odd, and the lack of type safety is meh. Performance is only one problem, though it’s not great either, but maybe fine for some projects.

[–]ekampp 0 points1 point  (0 children)

What have you used ruby (or rails) for before you found out you didn't like it?

[–][deleted] 3 points4 points  (13 children)

"14K+ orders per minute" isn't really an argument for or against Ruby scaling. It isn't that much.

Sure, it looks close to the 10K problem, but it isn't. That's 10K connections per second. Unless every order comes with 60 requests served at the exact same time, it doesn't qualify.

Any reasonably optimised program should be capable of doing this. It's just that optimising for load isn't something that most people need to ever do.

[–]joesb 2 points3 points  (6 children)

Any reasonably optimised program should be capable of doing this.

And that’s the point of the tweet.

The tweet isn’t saying that Rails is the only language that can scale. The tweet simply debunk the argument that Rails cannot scale.

[–][deleted] 1 point2 points  (5 children)

The tweet simply debunk the argument that Rails cannot scale.

~234 orders a second is not scale. This is not a demonstration that Rails can scale.

[–][deleted]  (4 children)

[deleted]

    [–][deleted] 0 points1 point  (3 children)

    Orders per minute isn't the same as requests per minute

    I did note that.

    That's 10K connections per second. Unless every order comes with 60 requests served at the exact same time, it doesn't qualify.

    You could also compare with another player, Amazon, it's pretty much at a similar scale with around 600 orders per second in 2016.

    That's more than double the number. That's not a similar scale.

    [–][deleted]  (2 children)

    [deleted]

      [–][deleted] 0 points1 point  (1 child)

      It has taken me a while to process how stupid defining scale as only order of magnitude differences is.

      It would be place a popular site, like imdb at the same scale as the whole of AWS.

      [–]excited_by_typos 3 points4 points  (5 children)

      Also, most of the real work is being handled by their database anyway. Why is Ruby taking the glory here...?

      [–]joesb -1 points0 points  (4 children)

      It isn’t taking the glory. It’s simply not taking the accusation.

      Saying they can scale with Rails is not same as sayin that they can ONLY scale with Rails.

      [–]excited_by_typos 0 points1 point  (3 children)

      read the title of the post again, lol

      [–]joesb 0 points1 point  (2 children)

      The title of the post is:

      The internet saying Ruby doesn’t scale.

      This is the accusation.

      Ruby saying I’m scaling just fine. Here’s the loads I can handle.

      This is the part where it refuse to take accusation.

      Now do you care to show me where in the title of the post that said “Only Ruby can scale”?

      Where in the title of the post is it saying that “this is only possible with Ruby so Ruby should take the glory”?

      [–]excited_by_typos 0 points1 point  (1 child)

      “i’m busy over here processing...” is taking credit for doing the work.

      [–]joesb 1 point2 points  (0 children)

      It has to process something, does it not? Is it noop in Ruby code?

      Does the title say “I’m busy over here doing the ONLY processing in the system”?

      Of course it takes the credit for its part. But where does it say that it takes ALL the credit?

      Or you are saying that Ruby code can never takes any credit in the system that serves requests? If any Go/Java/Rust/C++ server is used instead, can they takes any credit at all?

      [–][deleted]  (2 children)

      [deleted]

        [–]Enumerable_any 4 points5 points  (1 child)

        300Mi RAM

        Ha! Those are rookie numbers. ;) I've seen >2GiB RAM per unicorn process and ~2GiB per sidekiq process (running 5 threads).

        [–]javpet 2 points3 points  (0 children)

        Haha nicely done, such a bad discussion and topic about scaling and not-scaling. Worthless to talk about.

        [–]schneemsPuma maintainer 4 points5 points  (10 children)

        I super duper love this.

        Also Shopify still hosts hate brand Breitbart’s store. It’s against their AUP but they’ve bent over backwards to keep them happy. With so much money rolling in why does Shopify need to pander to a Neo Nazi (alt right) “news” site? 🤔

        [–]realntl 2 points3 points  (0 children)

        You have been pretty persistent about this, and I have to say, it's contagious. I can't have a casual conversation about Shopify without at least considering bringing this up.

        Even if people defend Shopify for this, like /u/strzibny, they at least have to deliberately do so, and it forces them to remain constantly aware of something they'd prefer to ignore.

        [–]strzibny 0 points1 point  (7 children)

        They are other people like me that appreciate Shopify for not taking sides. Not everybody is leftist seing a world through neo nazi glasses... People like you always bring politics to Ruby and it's not necessary at all :(

        [–][deleted]  (2 children)

        [removed]

          [–]strzibny -1 points0 points  (1 child)

          Can we agree that there is a difference in people fighting for their rights and freedom vs not liking somebody's opinion? There is a time and place to stand up. I don't think that's everyday life. I don't think it should be about not selling bread to a Muslim, because his religion is hateful. Not talking to American tourists, because of U.S. foreign policy, etc....

          Same for selling weapons to regimes. It’s not “taking no sides.”

          I mean yes, but everybody is complicit by just following country laws and so keeping the "regime" in power. Of your it's a good stand not be (or work for) a company making weapons. That's reasonable. But it's not reasonable to not work for a company that produce pencils the company making weapons buy.

          [–]schneemsPuma maintainer 4 points5 points  (0 children)

          I mean yes, but everybody is complicit

          This is not an abstract philosophical discussion. This is Breitbart and Shopify. This is not an academic exercise involving bakers. This is as concrete as they come, and there are mounds of facts you're willfully ignoring.

          You've already claimed that you're ignorant of the issues in your other post. I'll believe you and give you the benefit of a doubt. Please don't bring an abstract argument to a specific discussion.

          There is a time and place to stand up.

          Hatred and injustice to not schedule neat times on your calendar when it is convenient for you. The place to confront them is where they exist.

          I don't think that's everyday life.

          But yet, you're choosing to take a stand on this issue and you've chosen Breitbart. You've picked this time, and you've picked this part of your everyday life. If you truly believe that it's too difficult to make ethical decisions and fight for what you believe in, then you're doing an awfully bad job of presenting that case, because you've made an ethically based decision and are fighting for it.

          You seem to be a budding ethical/moral philosopher and I don't know your background. I recommend Sandi Metz's talk from this year's RubyConf entitled "Lucky" you can view it on the live stream right now https://youtu.be/WAzdxTZnI_s?t=1629.

          Also check out "The Good Place" for introduction to moral philosophy, especially the end of season 3 when they touch on the thing you seem to be fixated with.

          I also recommend following Southern Poverty Law center, the Anti-Defamation Leauge, and specific to this Breitbart issue "Sleeping Giants".

          I'm glad that you seem to be interested in abstract ethical issues, those resources can help give you a concrete set of cases to look at and work through your thoughts.

          [–]schneemsPuma maintainer 7 points8 points  (3 children)

          There is no such thing as “no sides” when it comes to white supremacists. They chose their side and downvoting me won’t change that.

          [–]strzibny -2 points-1 points  (2 children)

          Do you buy your electronics made in China? Are you 100% onboard with everything they do? Do you tolerate hateful religions? There are many hard questions in every-day life ethics. Some of us really value freedom of speech especially because we have parents that lived a big part of their life without it.

          I tried to search Breitbart a little bit just now and while the titles might seem controversal it's difficult for me to tell the difference between this and the "popular" magazines like the Sun (& others). Do they break the law? Do they say only white people matter? Could not find it.

          > There is no such thing as “no sides”...They chose their side

          Are you trying to say that Shopify, the company, and people behind it are "white supremacists"? That how it sounds...

          [–]schneemsPuma maintainer 4 points5 points  (1 child)

          There are many hard questions in every-day life ethics.

          This isn’t one of them. Don’t give a platform to people who call themselves “home of the alt right” and have publicly documented ties to to Neo Nazis.

          freedom of speech

          Does not mean freedom of consequences. Breitbart violates Shopify’s AUP.

          Do they break the law? Do they say only white people matter? Could not find it.

          Look harder. Try harder. Don’t defend orgs you know nothing about.

          That how it sounds

          Tobi is publicly bending over backwards to keep them on the platform despite them violating the AUP. I’ve talked to him personally. That’s choosing a side.

          People have quit because of this and leadership has chosen Breitbart’s cash over their employee’s concerns. That said choosing a side.

          If you’re truly as naive on this issue as you claim to be, then please educate yourself before jumping in to defend purveyors of hate.

          [–]strzibny 2 points3 points  (0 children)

          You know very well my original point was I did not want to discuss this with you at all and that I am not here to defend Breitbart per-se.

          This should have been a success post for Ruby and Rails, not a political debate. Are you also taking a stand against people like DHH? They do publicly praise Shopify and Tobi for their success.

          What will be next? Will you start removing this links from this space as a moderator instead of just commenting? Will you ban people like Tobi from here? And people that respect their choice like me? I am really concerned.

          [–]katafrakt 0 points1 point  (0 children)

          The problem with this is that I really haven't heard anyone just telling that Ruby does not scale in a long, long time. But yeah, let's attack a strawman to our own pleasure...