4 ms·

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 wa

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?

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?