7 ms·

I keep seeing small incremental speed improvements and overall these changes amount to a compounded effect over time. Yet we keep hearing that ruby is dead or

I keep seeing small incremental speed improvements and overall these changes amount to a compounded effect over time. Yet we keep hearing that ruby is dead or rails is dead and the very fact that we have large companies like Shopify or Stripe working hard to make the language and tools faster is proof that this is not dead...

deleted 5y ago
[deleted]
defaultname 5y ago
No one says that Ruby is dead, beyond in the rhetorical "as the cool new thing" angle. But sure, there are companies that were started with Ruby back when it was the cool thing (2008 - 2011ish), and inertia, along with a heavy dose of cargo culting, has them doubling down. If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust? I posted a couple of weeks back that it is remarkable that almost all Ruby advocacy/development comes from Shopify, and here is yet another example. Similarly, recent claims about Ruby's growth among the "top N websites" was more than 100% accounted for purely by a quirk in the way Shopify implements their storefront (as a subdomain which allowed Shopify's choice of technology to trojan horse in the metrics onto hundreds of thousands of domains). Clearly people make solutions with it, in the same way that people made remarkable solutions with PHP.
- freewilly1040 5y ago
  I would be curious to hear what someone who’s written both go and Ruby with a type system (forget what it’s called) is. My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better. To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.
  - maherbeg 5y ago
    I worked on Ruby code at Stripe using Sorbet and currently work in a Go code base full time now! Sorbet is pretty incredible and IMO was a huge benefit in a massive code base. Not having to worry about nil checks and always knowing the shape of the input data to functions was immensely valuable. It made data transformations really easy. I'm also a big fan of sum types which is available in Sorbet. It made expressing failure conditions with data really easy to do, and obvious to users of your code. This wasn't a pattern used everywhere though which is understandable given that it came much later in the Stripe code base. Go is actually a pretty nice language. It really is easy to pick up and be pleasantly productive in it. The built in libraries are extremely good, and the eco-system seems to favor using as many of the standards where possible (e.g. http middlewares all use the same patterns, no matter which framework you choose). I really dislike error handling in Go though. It's hard to actually know what errors you're receiving from functions you're calling, especially as they trickle their way up. For instance, if you're wanting to display certain error types to your users, you have to hope you've enumerated all of the potential errors returned and handle them in a janky manner (errors.Is / errors.As). I also really dislike that lots of things can be nil, and the compiler won't really help you there. You just have to know that some things are interfaces vs others being structs. The way interfaces are defined and used in Go are quite nice and it ends up being really easy to refactor something slightly to make it easier to test. edit: summary, I think I would agree with you that starting with Go is likely the better option for many types of backend services. Ruby on Rails is still really hard to beat for productive web oriented services though, and I think you could do pretty well mixing the two together.
  - joelbluminator 5y ago
    Some Rubyists moved on to newer typed tech like Sorbert or Go and some want nothing to do with it. I wouldn't make such broad generalizarions.
- Mikeb85 5y ago
  > If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust? Not a chance. Dynamic languages, especially Ruby, are way more productive than Go and Rust. Go is basically a less complicated, vm-less Java and Rust is a safer C++. Neither compete with Python, Ruby, Javascript or PHP.
  - JamesSwift 5y ago
    And thats not even taking the ecosystems into account. Ruby and Rails as an ecosystem to build SAAS products are massive vs Go/Rust.
    - Mikeb85 5y ago
      Yup. But I'd say part of the reason the ecosystem is so big is a testament to Ruby's productivity. Go seems great in a team environment for enterprise software, Rust seems great for software designed to last forever, but I've never met anything that's as good at simply hacking together a solution like Ruby (maybe R for stats and related things). You can build software that does things extremely quickly.
  - defaultname 5y ago
    I'm not sure what "not a chance" is referring to. Do you doubt that companies are being built around products not built in dynamic typed languages? Because there are loads. I mean, almost every major technology company on the planet. Indeed, there are lists of the "biggest" YC companies and it's remarkable how stratified the core technologies are with the launch year. Around 2008-2011 and it was Ruby all over the place. A number of recent companies list Go as the foundation of their solution. Recently Rust has started to appear in the lists. Shopify is successful because of a business model at the right time and right place. That they use Ruby should be ancillary, but the company seemed to have hired the "big fish in a small pond" from the Ruby world so now they're cargo culting hardcore with Ruby there, making Ruby their core technology identity, to the point that they're spending enormous engineering effort to gain the benefits that everyone else is enjoying for free with alternative platforms. Which...they can afford it. But it doesn't make it right.
- joelbluminator 5y ago
  Well the advocacy comes from Stripe as well (depending on how you define advocacy exactly) and Github. Those are the big corps running huge Ruby monoliths. Is that remarkable to you in the sense you would expect more effort from other Ruby companies? I think Shopify and Stripe is pretty much enough in terms of resources. I think Cookpad and Heroku also pay for some core Ruby/Rails members to work on it full time. How much more do you need?
hardwaregeek 5y ago
I like Ruby and I'd write a lot more Ruby if I bothered to learn Sorbet. There still isn't a language that scratches that itch of productive web development with minimal boilerplate. I've mostly started to feel uncomfortable with dynamically typed languages with lots of mutability.
- ch4s3 5y ago
  This is partially why I moved over to Elixir. I'm just as productive and its dynamic, but the data is immutable.
- weatherlight 5y ago
  Hello Elixir! Hello Clojure! :)
rockyj 5y ago
I have another way to look at the same thing. Ruby/Rails as a development language/framework is great and no doubts about it. I used it for many years. Would I recommend it for any new project / startup now (other than a simple CRUD with a handful of users) - No. Shopify or Stripe are huge companies with massive codebases in Ruby, perhaps so complex that they are better off making investments in Ruby performance rather than re-writing their stack. In fact, the very fact that these companies have to spend so much time trying to make Ruby work well tells me that something is not right. For a startup which has limited resources why should I wait for 10% improvements in Ruby performance every 6 months, when I can already get on the rocket-ship of performance that is - Node.js or JVM or even Elixir. Kotlin for example even writes a bit like Ruby, has some decent frameworks available and will give me magnitudes of performance on top.
- dyeje 5y ago
  You choose Rails because you can build extremely fast with it (for a variety of reasons). The number one risk to a startup is not finding product market fit. Therefore, building fast is paramount. It doesn't matter how much load your product can handle if you never get the load in the first place. I would absolutely recommend Rails for most startups whose central product is a web application.
  - rockyj 5y ago
    I tend to disagree, this was true few years ago but there are now tons of frameworks / boiler-plates which also enable devs to launch fast and stay fast e.g Phoenix Yes, Rails is very mature but the difference is not that huge anymore.
    - ksec 5y ago
      > Phoenix Is Phoenix really that close to Rails in terms of ecosystem system maturity? I haven't done any real world work with Phoenix. So I couldn't judge. More often that not most people suggest Y is close to X. And the difference is not that much when Y is already 80% to X. Reality is that 20% is a huge difference. That takes as much time to reach the previous 80%. And this could be used across many different subject / domain. It is a common error in comparison. The only thing that came close or even exceed Rails ecosystem is actually another dead or unpopular language. PHP with Laravel.
ksec 5y ago
When people say Ruby is dead, I dont think any one actually meant "dead" in literal sense. Even COBOL is not dead. A more correct term from their POV would be Ruby is dying, roughly translating to Ruby is not growing. Or what they really meant is Ruby as a market ecosystem is shrinking. And you have to take in the context from the one speaking of it and the one listening to it. The ecosystem is practically dead in many places on Earth. US and Japan tends to be the only place with a large enough sustainable market. ( And US is big enough that you could segment it into multiple different market ) The only place in EUR that seems to be doing ok with Ruby Rails are Germany and UK. But even then I am suspecting both may be on the verge of decline if not already declining. So if someone saying it is vibrant in US and someone listening to it say from China or Eastern Europe then they will obviously have disagreement. Ruby as a language has always been the odd one out in the Top 10 ( or at least used to be Top 10 ) where it has very little to particularly zero resources backing. Every other language on the list has FAANG behind it in one form or another. But now with the help of Shopify, Github and Stripe. I believe the future of Ruby Rails is pretty damn good. Now both YJIT and Rails are tested Shopify and Github production code base. And YJIT manage to speed up one of the slowest part of Rail, ActiveRecord. Rails 7 and Ruby 3.1 may be the renaissance of the ecosystem.
- Zababa 5y ago
  I don't think the speed of Rails will lead to a renaissance. Rails was very popular at one point because it allowed you to ship a MVP way faster than with the alternatives. It was also at the peak of Heroku, so the ops part was easy. These days it's not true. Pretty much every major language has a viable Rails alternative (except JS for some reason). You could argue that we've grown backwards, as it seems that deployments are harder than before, and same with building things. I think it's a symptom of the industry being dominated again by a few big players, so the ecosystems are optimized for them. What we might see is less people moving from Ruby/Rails to X because of speed, but that's about it.
  - JamesSwift 5y ago
    We also might see more people moving back to Rails because of speed, because as they probably know now after rewriting in a different ecosystem... it was usually their app code that was the problem.
Twirrim 5y ago
Use whatever gets your product out the door. Performance, for the most part, can come later. Good enough is good enough.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

defaultname 5y ago

No one says that Ruby is dead, beyond in the rhetorical "as the cool new thing" angle. But sure, there are companies that were started with Ruby back when it was the cool thing (2008 - 2011ish), and inertia, along with a heavy dose of cargo culting, has them doubling down. If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust? I posted a couple of weeks back that it is remarkable that almost all Ruby advocacy/development comes from Shopify, and here is yet another example. Similarly, recent claims about Ruby's growth among the "top N websites" was more than 100% accounted for purely by a quirk in the way Shopify implements their storefront (as a subdomain which allowed Shopify's choice of technology to trojan horse in the metrics onto hundreds of thousands of domains). Clearly people make solutions with it, in the same way that people made remarkable solutions with PHP.

freewilly1040 5y ago
I would be curious to hear what someone who’s written both go and Ruby with a type system (forget what it’s called) is. My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better. To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.
- maherbeg 5y ago
  I worked on Ruby code at Stripe using Sorbet and currently work in a Go code base full time now! Sorbet is pretty incredible and IMO was a huge benefit in a massive code base. Not having to worry about nil checks and always knowing the shape of the input data to functions was immensely valuable. It made data transformations really easy. I'm also a big fan of sum types which is available in Sorbet. It made expressing failure conditions with data really easy to do, and obvious to users of your code. This wasn't a pattern used everywhere though which is understandable given that it came much later in the Stripe code base. Go is actually a pretty nice language. It really is easy to pick up and be pleasantly productive in it. The built in libraries are extremely good, and the eco-system seems to favor using as many of the standards where possible (e.g. http middlewares all use the same patterns, no matter which framework you choose). I really dislike error handling in Go though. It's hard to actually know what errors you're receiving from functions you're calling, especially as they trickle their way up. For instance, if you're wanting to display certain error types to your users, you have to hope you've enumerated all of the potential errors returned and handle them in a janky manner (errors.Is / errors.As). I also really dislike that lots of things can be nil, and the compiler won't really help you there. You just have to know that some things are interfaces vs others being structs. The way interfaces are defined and used in Go are quite nice and it ends up being really easy to refactor something slightly to make it easier to test. edit: summary, I think I would agree with you that starting with Go is likely the better option for many types of backend services. Ruby on Rails is still really hard to beat for productive web oriented services though, and I think you could do pretty well mixing the two together.
- joelbluminator 5y ago
  Some Rubyists moved on to newer typed tech like Sorbert or Go and some want nothing to do with it. I wouldn't make such broad generalizarions.
Mikeb85 5y ago
> If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust? Not a chance. Dynamic languages, especially Ruby, are way more productive than Go and Rust. Go is basically a less complicated, vm-less Java and Rust is a safer C++. Neither compete with Python, Ruby, Javascript or PHP.
- JamesSwift 5y ago
  And thats not even taking the ecosystems into account. Ruby and Rails as an ecosystem to build SAAS products are massive vs Go/Rust.
  - Mikeb85 5y ago
    Yup. But I'd say part of the reason the ecosystem is so big is a testament to Ruby's productivity. Go seems great in a team environment for enterprise software, Rust seems great for software designed to last forever, but I've never met anything that's as good at simply hacking together a solution like Ruby (maybe R for stats and related things). You can build software that does things extremely quickly.
- defaultname 5y ago
  I'm not sure what "not a chance" is referring to. Do you doubt that companies are being built around products not built in dynamic typed languages? Because there are loads. I mean, almost every major technology company on the planet. Indeed, there are lists of the "biggest" YC companies and it's remarkable how stratified the core technologies are with the launch year. Around 2008-2011 and it was Ruby all over the place. A number of recent companies list Go as the foundation of their solution. Recently Rust has started to appear in the lists. Shopify is successful because of a business model at the right time and right place. That they use Ruby should be ancillary, but the company seemed to have hired the "big fish in a small pond" from the Ruby world so now they're cargo culting hardcore with Ruby there, making Ruby their core technology identity, to the point that they're spending enormous engineering effort to gain the benefits that everyone else is enjoying for free with alternative platforms. Which...they can afford it. But it doesn't make it right.
joelbluminator 5y ago
Well the advocacy comes from Stripe as well (depending on how you define advocacy exactly) and Github. Those are the big corps running huge Ruby monoliths. Is that remarkable to you in the sense you would expect more effort from other Ruby companies? I think Shopify and Stripe is pretty much enough in terms of resources. I think Cookpad and Heroku also pay for some core Ruby/Rails members to work on it full time. How much more do you need?

hardwaregeek 5y ago

I like Ruby and I'd write a lot more Ruby if I bothered to learn Sorbet. There still isn't a language that scratches that itch of productive web development with minimal boilerplate. I've mostly started to feel uncomfortable with dynamically typed languages with lots of mutability.

ch4s3 5y ago
This is partially why I moved over to Elixir. I'm just as productive and its dynamic, but the data is immutable.
weatherlight 5y ago
Hello Elixir! Hello Clojure! :)

rockyj 5y ago

I have another way to look at the same thing. Ruby/Rails as a development language/framework is great and no doubts about it. I used it for many years. Would I recommend it for any new project / startup now (other than a simple CRUD with a handful of users) - No. Shopify or Stripe are huge companies with massive codebases in Ruby, perhaps so complex that they are better off making investments in Ruby performance rather than re-writing their stack. In fact, the very fact that these companies have to spend so much time trying to make Ruby work well tells me that something is not right. For a startup which has limited resources why should I wait for 10% improvements in Ruby performance every 6 months, when I can already get on the rocket-ship of performance that is - Node.js or JVM or even Elixir. Kotlin for example even writes a bit like Ruby, has some decent frameworks available and will give me magnitudes of performance on top.

dyeje 5y ago
You choose Rails because you can build extremely fast with it (for a variety of reasons). The number one risk to a startup is not finding product market fit. Therefore, building fast is paramount. It doesn't matter how much load your product can handle if you never get the load in the first place. I would absolutely recommend Rails for most startups whose central product is a web application.
- rockyj 5y ago
  I tend to disagree, this was true few years ago but there are now tons of frameworks / boiler-plates which also enable devs to launch fast and stay fast e.g Phoenix Yes, Rails is very mature but the difference is not that huge anymore.
  - ksec 5y ago
    > Phoenix Is Phoenix really that close to Rails in terms of ecosystem system maturity? I haven't done any real world work with Phoenix. So I couldn't judge. More often that not most people suggest Y is close to X. And the difference is not that much when Y is already 80% to X. Reality is that 20% is a huge difference. That takes as much time to reach the previous 80%. And this could be used across many different subject / domain. It is a common error in comparison. The only thing that came close or even exceed Rails ecosystem is actually another dead or unpopular language. PHP with Laravel.

ksec 5y ago

When people say Ruby is dead, I dont think any one actually meant "dead" in literal sense. Even COBOL is not dead. A more correct term from their POV would be Ruby is dying, roughly translating to Ruby is not growing. Or what they really meant is Ruby as a market ecosystem is shrinking. And you have to take in the context from the one speaking of it and the one listening to it. The ecosystem is practically dead in many places on Earth. US and Japan tends to be the only place with a large enough sustainable market. ( And US is big enough that you could segment it into multiple different market ) The only place in EUR that seems to be doing ok with Ruby Rails are Germany and UK. But even then I am suspecting both may be on the verge of decline if not already declining. So if someone saying it is vibrant in US and someone listening to it say from China or Eastern Europe then they will obviously have disagreement. Ruby as a language has always been the odd one out in the Top 10 ( or at least used to be Top 10 ) where it has very little to particularly zero resources backing. Every other language on the list has FAANG behind it in one form or another. But now with the help of Shopify, Github and Stripe. I believe the future of Ruby Rails is pretty damn good. Now both YJIT and Rails are tested Shopify and Github production code base. And YJIT manage to speed up one of the slowest part of Rail, ActiveRecord. Rails 7 and Ruby 3.1 may be the renaissance of the ecosystem.

Zababa 5y ago
I don't think the speed of Rails will lead to a renaissance. Rails was very popular at one point because it allowed you to ship a MVP way faster than with the alternatives. It was also at the peak of Heroku, so the ops part was easy. These days it's not true. Pretty much every major language has a viable Rails alternative (except JS for some reason). You could argue that we've grown backwards, as it seems that deployments are harder than before, and same with building things. I think it's a symptom of the industry being dominated again by a few big players, so the ecosystems are optimized for them. What we might see is less people moving from Ruby/Rails to X because of speed, but that's about it.
- JamesSwift 5y ago
  We also might see more people moving back to Rails because of speed, because as they probably know now after rewriting in a different ecosystem... it was usually their app code that was the problem.

Twirrim 5y ago

Use whatever gets your product out the door. Performance, for the most part, can come later. Good enough is good enough.

deleted 5y ago

[deleted]