12 ms·

This is really exciting news. Lots of folks slam Rails for being slow and inefficient despite there being massive sites using it at scale (Shopify, GitHub, etc.

• tiffanyh 5y ago
  Have you looked at Phoenix? A ton of new Rails features/development you mentioned is inspired by work the Phoenix team built, who were also once core Rails contributors. https://www.phoenixframework.org/ https://www.phoenixframework.org/
  • weatherlite 5y ago
    What does Phoenix have to do with it? The guy can't say anything good about Rails without us talking about Phoenix? Have you looked at Django? Have you looked at Laravel? Have you looked at Go? Rust? Node? We get it everyone is doing web frameworks noawdays, Rails isn't unique.
    • tempest_ 5y ago
      Phoenix is often mentioned in conjunction with Rails because Elixir's syntax is often described as "Ruby like" and the guy who made Elixir is(was?) a member of the rails core team.
      • weatherlite 5y ago
        Yeah I get it, thanks. I still think it would be nice to stop it.
        • RexM 5y ago
          Stop discussing technologies that were made specifically to address the short-comings of the topic of the article?
        • robertlagrant 5y ago
          > Yeah I get it, thanks. I still think it would be nice to stop it. It would be nice for the rest of us to have informed, considered responses in comments rather than little rants. But it seems as though no one's getting what they want today.
      • gregors 5y ago
        As someone who uses and likes Elixir and Ruby, the syntax is more accurately described as Erlang and Ruby in a car crash.
    • throwamon 5y ago
      Sheesh, why so much hostility? Elixir and Phoenix were created precisely to address Ruby's and Rails' shortcomings, and by noteworthy Rails contributors no less. They're incredibly good (paradigm-shifting even), the community is great, etc. They're also not mainstream yet, so it makes perfect sense to mention them. Just because you're tired of hearing about something it doesn't mean there aren't (lots of) people who have never heard about it. (See https://xkcd.com/1053/ https://xkcd.com/1053/) In fact, if you're tired of hearing about this, you might want to expand your bubble a little bit. (I have no involvement with them, just a passerby.)
• ferdowsi 5y ago
  I don't think it's coming back. The big players who started with Ruby during the peak of its 2008~ hype curve are having serious scaling pains and are looking to other more performant languages as a way out. Engineers at these companies are going to be taking these lessons elsewhere. This isnt even mentioning the compelling environmental arguments against a computationally taxing dynamic language like Ruby, which is going to be louder in the next few years.
  • weatherlite 5y ago
    It's not coming back to what it was in 2012 but it's also not disappearing. It's here to stay.
  • dangerface 5y ago
    > compelling environmental arguments against a computationally taxing dynamic language Cost of development has always been the more significant cost over compute power for these businesses. Considering the entire web uses under 10% of the global energy rewriting your entire stack in c++ for the small performance improvement is not going to make a dent in that. Why would businesses do this for such a small environmental improvement when they could spend half the money putting in solar and produce significantly more green energy than their stack uses?
  • playpause 5y ago
    > The big players who started with Ruby during the peak of its 2008~ hype curve are having serious scaling pains and are looking to other more performant languages as a way out. Interesting, how do you know about this? I was under the impression GitHub were still mostly happy with Rails.
    • ferdowsi 5y ago
      Github has been rewriting performance-critical components in Go for a while now. https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/ https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-dr... > Although GitHub.com is still a Rails monolith, over the past few years we’ve begun the process of extracting critical functionality from our main application, by rewriting some of the code in Go—mostly addressing the pieces that need to run faster and more reliably than what we can accomplish with Ruby.
• midrus 5y ago
  I really hope some sanity comes back to this industry. Rails and Laravel are the best tools by far to build like... 90% of what we build on the internet (Other 10% being offline first apps and stuff like figma, etc). It just hurts to see how my team, and previous teams I worked with struggle with all the SPAs and microservices, and Go backends and GraphQL nonsense when what we're doing are just fancy crud forms with maybe one or two really interactive widgets overall. So much time and money wasted just for following fashion.
  • brightball 5y ago
    I’d add Elixir and Phoenix to that list and then agree with you.
    • MathCodeLove 5y ago
      I'd add Phoenix to the list when it gets its documentation in the same echelon as that of Rails or Laravel. It may be as productive if you already know how to use it, but good luck building anything non-trivial on your own if you don't.
      • brightball 5y ago
        Don’t you usually learn how to use your tools before you build with them? This feels like a strange response.
        • nickjj 5y ago
          I've always found the Phoenix docs to be more like references. There's "guide-like" aspects to it but in my opinion it's no where near the level of where the Rails docs are. I agree with the person we're replying to, I almost always found myself having to research third party sources when learning Phoenix (blog posts, IRC, etc.) to get answers to questions that I never had to ask about Rails, Flask or Django because their docs covered it very well. The Rails doc feels like you have DHH at your side guiding you on exactly how to do something in the context of a practical application and whenever you think to yourself "that's great, but what if I want to do...", often times the very next sentence in the docs will answer your exact question. The Rails routing docs https://guides.rubyonrails.org/routing.html https://guides.rubyonrails.org/routing.html are a great example of this when they talk about namespaces and scopes but there's a million other examples. It feels like it was written by folks who have been through the thick of it and back 100 times over to extract out the exact questions folks would have when using various features of the framework. Each piece of the docs feels like it's a mini book written on par with any book on a technical subject and then there's a completely separate reference guide docs with more examples. Even the styling of the page itself just feels good. It's really easy to skim and navigate. The Phoenix docs feel more like a big wall of text with a few small headers and code blocks. It's hard to explain but personally my brain identifies the Rails docs as easy to mentally parse where as the Phoenix docs are not based on nothing more than the styling aspect alone. Overall the Rails docs feel like they are written with a ton of empathy around the person reading them, completely holding your hand from beginning to end to solve a practical issue which is exactly what you need when learning something new. The reference guides are always there if all you care about are a few quick examples.
• pizza234 5y ago
  > At the same time you can still run a single $20 / month server for "smaller" apps even with Rails + Sidekiq + Action Cable + Postgres + Redis all running on the same server to power your solo developed SAAS app with thousands of customers. This is true but in a narrow sense. Rails and Ruby are inherently inefficient, both in the performance and memory profiles. Rails is theoretically threadsafe, but not really - I've been hit by a threading issue just within the first hour of testing, and even if Rails was, the ecosystem isn't. Which means, one needs multiple processes, which requires lots of memory. Speed isn't great, either. I can't really do apples-to-apples comparison, but I think it's realistic to state that equivalent, statically typed, applications are very significantly faster (without explicit optimizations), which requires more computing units.
  • Lio 5y ago
    Things are changing on this front. We now have better fibres for IO bound code and ractors for thread safe CPU bound code. Personally I don’t think ractors are completely solid but I don’t think it will long until they are. I think Ruby’s future is pretty rosey compared to a few years ago. I would even say that small projects can avoid Sidekiq and Redis by using Good Job and Postgres making them even cheaper to start with.
    • pizza234 5y ago
      Regarding the ractors, I'm a big fan - I believe true multithreading in a language with a GIL is a revolutionary change. On the other hand, I also believe that Ruby has always had a culture of single threading, so for the ecosystem to adjust (in practice, for having threadsafe libraries), it will take a very long time (if ever; I'm pessimitic and personally believe the ecosystem will never catch up, but of course, I wish all the best :)).
• ksec 5y ago
  >while having a p95+ response time of <= 100ms. Which is where the argument began. Emphasis on the 100ms. But lets not derail ( no pun intended ) into that again. >PRs like this just mean things are going to get even better than they already are and is probably a precursor to converting a bunch of Rails internals to use Fibers over time. And the fact this actually got merged. For the longest time watching rails I thought no one was interested. Samuel Williams seems to be the only one pushing for it.
• qudat 5y ago
  Ruby has a severely lacking ecosystem imo and since it is virtually a language to support rails, so I find it hard to believe it will pick up anymore traction than it already has. Static typing, lack of static analysis tooling, and autoformatting are sorely missed. Whenever I work on a ruby/rails codebase I feel like I've gone a decade in the past. The DX is not that great and many other ecosystems have comparable DX with a modern toolset.
• llamataboot 5y ago
  I think there is a hacker news law that says that any post about a feature of a language or framework will eventually devolve into a general argument about whether that language or framework is good or not, and have nothing to do with the specific feature :D
• zzzeek 5y ago
  > Lots of folks slam Rails for being slow and inefficient despite there being massive sites using it at scale (Shopify, GitHub, etc.) with very commendable response times and uptime. Github is moving away from activerecord for exactly these reasons: https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/ https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-dr... > Although GitHub.com is still a Rails monolith, over the past few years we’ve begun the process of extracting critical functionality from our main application, by rewriting some of the code in Go—mostly addressing the pieces that need to run faster and more reliably than what we can accomplish with Ruby. full disclosure, I'm the author of SQLAlchemy for Python. But I certainly wouldn't expect Github to migrate from Ruby to Python for speed reasons, it would be like trading up your Ford Pinto for a Dodge Dart - not worth a rewrite :). Right now if you have middleware that is to be crushed with billions of reqs per hour, interpreted languages are simply not going to cut it.
  • jrochkind1 5y ago
    That's a good blog post, thanks for posting! I do not think "moving away from activerecord" is an accurate summary of what you yourself quoted, "extracting critical functionality from our main application… mostly addressing the pieces that need to run faster and more reliably than what we can accomplish with Ruby." Anyway, ruby and python are indeed pretty close performance-wise, for whatever reason python has become more popular (and it clearly has), it's not performance! Yet people always bring up performance when talking about why ruby isn't more popular... doesn't seem to be hurting python much.
    • robertlagrant 5y ago
      I think it's because when they say Ruby they mean Rails, and the paradigm the Rails ORM uses is good for simple queries, but doesn't scale well. SQLAlchemy/Hibernate use a different paradigm, which scales a little better.
  • no_wizard 5y ago
    except NodeJS, apparently, and this is far back as 2011, when LinkedIn switched to NodeJS from Rails https://venturebeat.com/2011/08/16/linkedin-node/ https://venturebeat.com/2011/08/16/linkedin-node/
• BosStartup 5y ago
  We migrated a rails app, that needed in memory data structures, from rails to java. We went from needing rolling restarts and 100 aws servers all cpu bound, to running 10% cpu on 2 java servers never needing a restart. Ruby and rails is great for a PoC or a quick crud app, but it is not close to being performant which usually doesn't matter but sometimes it does.
  • robertlagrant 5y ago
    It's hard to know what solved the problem here. I wouldn't assume that it's the Java bit, although it could be.
    • BosStartup 5y ago
      Oh got it, I should outline more of the problem we faced. We had a high throughput server that needed a fair amount of in memory data to service the requests. The in memory data would update, one set of the data would update very quickly while the larger data set would update slowly. Two things on this: 1) Ruby is not concurrent, it is multi-threaded but not concurrent. When ruby starts up you generally create a new process per CPU to ensure you can utilize all cpus. This is generally fine for a CRUD app but does not work well if you really need to share in memory data structures in a low latency way, it will result in any changes to memory being repeated for each process, so a 32 core machine is 1/32 as efficient with memory. 2) Ruby, at least at the time, had a non-compacting garage collector. This over time leads to memory fragmentation which ends up causing ruby to run out of pages, as such you run out of ram. This mean with Ruby you have to be careful if you get closer to the limit of how much ram you have on a machine and you are allocating/freeing large spans of memory, if freeing memory doesn't free the page you can still run out of memory. This appears as a memory leak for the machine but ruby appears to still just be using the same amount of memory. Only fix for this is having rolling restarts. Java using a compacting garage collector, which can help alleviate this issue, of course it does come with some pauses. I also found the ruby schedule is not pre-emptive. This might have changed but at the time it meant if you had a lot of threads that were waiting on external IO that the ruby machine's performance deteriorated. Java's scheduled appeared to be more performant. Looking at this post makes me realize I should turn this into a blog post with links to the actual numbers to demonstrate each issue clearly.