3 ms·

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 t

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.
  - tomnipotent 5y ago
    So in other words Rails has been a success for them.
    - ryeguy 5y ago
      The context here is whether or not they're still happy with it.
      - nickjj 5y ago
        > The context here is whether or not they're still happy with it. In 2018 GitHub got acquired for 7.5 billion dollars. Rails got them to that point and they've been up and running since 2008. I'd say that's a very big success. Given GitHub's contributions to Rails master and other activity around projects like https://github.com/github/view_component https://github.com/github/view_component, from the outside it looks like they're still very happy with it. It's hard to say if we'd ever get a real answer on what they think internally, it would be pretty unlikely that their CTO is going to publicly write an official company blog post on "I wish we didn't choose Rails".
berkes 5y ago
People too often cite "speed of the language" as the only reason to abandon Rails (and Ruby). But this is a bit of a stretch, because you'll hardly ever have this performance problem at all and if you do, paying a little more for hosting infra "solves it"¹. You'll hardly ever reach the scale at which this truly starts to matter. I'm certain there are other, far more valid reasons to migrate to Java, .net, Go, Rust or whatever. Rails' opinionated setup might simply not fit your use-case. Lacking language features (Interfaces, Typing, etc). Poor libraries(in your domain). Complex deployment- and operating stack. Too few good and experienced developers who know and like Ruby around and so forth and so on. There are numerous reasons to move away from Rails and Ruby. Speed is but one. And often the easiest to solve in other ways. ¹ Actually, in my previous role as Rails consultant I often did performance tuning for Rails. 99.99999% of the times the executing time nor the GIL, nor the GC, are the problem. But the database is. Poor DBA, in my experience is the thing that makes most Rails apps slow. For which I blame Rails, because it makes it so damn easy to forego any sane design on the DBA, and just hobgobble together some `@user.devises.active.order(:used_at).messages.new` in your views, which fires the worst ever query on your database.
- waffle_maniac 5y ago
  Poor database performance is a thing at my current gig. But often the only solution is having a custom view made.
  - berkes 5y ago
    > But often the only solution is having a custom view made. Sometimes. But I'd urge you -and every Rails dev struggling with this- to look at how and where you can decouple and separate the concerns in your (quite likely) ball-of-models. Most often that is a far more sustainable solution. One that helps you not only with performance.

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.
- tomnipotent 5y ago
  So in other words Rails has been a success for them.
  - ryeguy 5y ago
    The context here is whether or not they're still happy with it.
    - nickjj 5y ago
      > The context here is whether or not they're still happy with it. In 2018 GitHub got acquired for 7.5 billion dollars. Rails got them to that point and they've been up and running since 2008. I'd say that's a very big success. Given GitHub's contributions to Rails master and other activity around projects like https://github.com/github/view_component https://github.com/github/view_component, from the outside it looks like they're still very happy with it. It's hard to say if we'd ever get a real answer on what they think internally, it would be pretty unlikely that their CTO is going to publicly write an official company blog post on "I wish we didn't choose Rails".

berkes 5y ago

People too often cite "speed of the language" as the only reason to abandon Rails (and Ruby). But this is a bit of a stretch, because you'll hardly ever have this performance problem at all and if you do, paying a little more for hosting infra "solves it"¹. You'll hardly ever reach the scale at which this truly starts to matter. I'm certain there are other, far more valid reasons to migrate to Java, .net, Go, Rust or whatever. Rails' opinionated setup might simply not fit your use-case. Lacking language features (Interfaces, Typing, etc). Poor libraries(in your domain). Complex deployment- and operating stack. Too few good and experienced developers who know and like Ruby around and so forth and so on. There are numerous reasons to move away from Rails and Ruby. Speed is but one. And often the easiest to solve in other ways. ¹ Actually, in my previous role as Rails consultant I often did performance tuning for Rails. 99.99999% of the times the executing time nor the GIL, nor the GC, are the problem. But the database is. Poor DBA, in my experience is the thing that makes most Rails apps slow. For which I blame Rails, because it makes it so damn easy to forego any sane design on the DBA, and just hobgobble together some `@user.devises.active.order(:used_at).messages.new` in your views, which fires the worst ever query on your database.

waffle_maniac 5y ago
Poor database performance is a thing at my current gig. But often the only solution is having a custom view made.
- berkes 5y ago
  > But often the only solution is having a custom view made. Sometimes. But I'd urge you -and every Rails dev struggling with this- to look at how and where you can decouple and separate the concerns in your (quite likely) ball-of-models. Most often that is a far more sustainable solution. One that helps you not only with performance.