Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is Ruby on Rails still relevant?

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 160 posts

Re: Ask HN: Is Ruby on Rails still relevant?

#131

Post by mountainriver »

weatherlite wrote: post #108
mountainriver wrote: post #47

Earlier quoted context omitted.

I work at a company with a large Ruby monolith and it’s a disaster. If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful. You want a scalable system that’s easy to write and will grow with you? Write basic Go services.

> You want a scalable system that’s easy to write and will grow with you? Write basic Go service What's so easy about Go? I don't get it. Honestly. What's so hard for you to do in Ruby? And who's to say that in 15 years those shiny Go services you're working on won't become shit after dozens of changing devs had their way with them? Turning a codebase into shit takes time.

Go was designed to prevent this is why its great, Ruby was designed in a way that fosters bad dev practices

Re: Ask HN: Is Ruby on Rails still relevant?

#132

Post by nobleach »

weatherlite wrote: post #121
nobleach wrote: post #118

Earlier quoted context omitted.

It absolutely does. When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win". One bumps up against the node count that is hit by the load balancer. (NodeJS experiences this quite a bit too). Rails excels in heavily cached configurations. This requires less volatile data. My main point here is, that while one can work hard to try and tune Rails (…

> My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it) That's what I'm saying - you don't need to "work hard" to tune Rails in 99% of cases - your bottlenecks (if any) will probably be in the database layer. k8s simply solves it, so unless your argument is "infrastructure costs" or something I don't agree with your case. Shopify has such tremendous scale I th…

Yes, scaling horizontally can be quite expensive. For a startup that begins their journey with Rails, and finds out quickly how expensive that is, it can be a show stopper. Shopify and Stripe are used as an example simply because I want to agree that it is possible - given a ton of resources.

So, if I could tell you, that for your next startup, you could start with something that is easier and cheaper to scale (I find "a few more pods" very disingenuous as many benchmarks say otherwise), why would you choose something that requires a lot more resources? Because Rails is neat? I just don't see the allure at that point. It's why we're seeing companies like Podium, Divvy, PagerDuty move away from it. It's great to get a proof of concept out the door. So many stories are out there of folks that are moving away from it for their "next step".

Re: Ask HN: Is Ruby on Rails still relevant?

#133

Post by mountainriver »

hiyer wrote: post #93
mountainriver wrote: post #47

Earlier quoted context omitted.

I work at a company with a large Ruby monolith and it’s a disaster. If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful. You want a scalable system that’s easy to write and will grow with you? Write basic Go services.

A Go monolith would be just as hard to maintain as an RoR monolith. This is not a shortcoming of the framework.

Nope, Go is more opinionated and was designed to work on large teams and codebases with junior engineers. It enforces best practices where Ruby just lets you shoot yourself in the foot

Re: Ask HN: Is Ruby on Rails still relevant?

#134

Post by mountainriver »

likortera wrote: post #123
weatherlite wrote: post #109

Earlier quoted context omitted.

This is so true. Now there's ORM for Go (Gorm), and maybe a few web frameworks, but it just feels like any other beginning ecosystem - not much on Stackoverflow if you run into problems, docs aren't that good yet, incomplete APIs, missing functionality. And it has the same Node mindset of not having a major framework to tie everything together like Rails does- which I hate. To go to your bosses and tell them you have…

Well, the usual "reasoning" is that Go is easier to maintain, faster, will require less hardware, etc... all of those things might be true. What is not told in is the other side of the story, the one where you will have to write, test, document and maintain a TON more code... which usually ends up in just overall lower quality as it is pretty hard to find developers writing better code than the code you usually find…

Go autodocuments really well

Go has better safeguards to prevent bad dev behavior

There shouldn't be any more tests, you're testing an API either way

Re: Ask HN: Is Ruby on Rails still relevant?

#135

Post by mountainriver »

boboroshi wrote: post #119
mountainriver wrote: post #47

Earlier quoted context omitted.

I work at a company with a large Ruby monolith and it’s a disaster. If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful. You want a scalable system that’s easy to write and will grow with you? Write basic Go services.

Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I…

> n great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts.

This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev

Re: Ask HN: Is Ruby on Rails still relevant?

#136

Post by mountainriver »

jaredcwhite wrote: post #77
mountainriver wrote: post #50

Rails is like PHP. It’ll probably never die because people just keep propping it up. There are much better options, but some people just like the crap they know

Rails is like PHP — well thanks for that compliment! I'd much rather program in modern PHP than in any of the other obvious competitors to Ruby. From what my friends who use Laravel say, that's actually a pretty awesome (and certainly Rails-inspired) framework if you're a PHP dev.

Thats great!

Re: Ask HN: Is Ruby on Rails still relevant?

#137

Post by postmodern_mod3 »

mountainriver wrote: post #47
ericskiff wrote: post #23

We're still starting new greenfield projects in Rails every week, and I still believe it's the best foundation for SaaS products. It's great for developer speed and efficiency, the ecosystem of gems is amazing, and we've been able to scale every project we've needed to. We're incorporating React and GraphQL more these days for complex components and APIs but they pair nicely with Rails.

I work at a company with a large Ruby monolith and it’s a disaster. If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful. You want a scalable system that’s easy to write and will grow with you? Write basic Go services.

You can write "complected" monoliths in any language. You can also write SOAs in any language. If you need native performance, Crystal is a better option, as it provides much of the same syntax, semantics, and stdlib as Ruby, but with Strong Typing. Go is a bit too simple.

Re: Ask HN: Is Ruby on Rails still relevant?

#138

Post by postmodern_mod3 »

mountainriver wrote: post #135
boboroshi wrote: post #119

Earlier quoted context omitted.

Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I…

> n great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts. This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev

How so? Go does not prevent you from writing a monolith. Furthermore, Go does not actually require that you check the err return value of functions.

Re: Ask HN: Is Ruby on Rails still relevant?

#139

Post by likortera »

mountainriver wrote: post #129
likortera wrote: post #99

Earlier quoted context omitted.

I've been at a company that did this, they started migrating everything to Go because it was the new cool thing to do and everyone was in love with it. One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations. Validations were custom wrappers on some validation libraries and validation errors w…

Huh, well I've written lots of Go services and worked in lots of Go architectures and it was all worked really well actually. Looks a lot better than spaghetti code in a monolith Maybe you're doing it wrong?

Maybe I'm not that interested in how nice it looks and more in how many people are necessary to maintain it and provide something useful to customers at a reasonable cost for my employer.

Re: Ask HN: Is Ruby on Rails still relevant?

#140

Post by likortera »

mountainriver wrote: post #134
likortera wrote: post #123

Earlier quoted context omitted.

Well, the usual "reasoning" is that Go is easier to maintain, faster, will require less hardware, etc... all of those things might be true. What is not told in is the other side of the story, the one where you will have to write, test, document and maintain a TON more code... which usually ends up in just overall lower quality as it is pretty hard to find developers writing better code than the code you usually find…

Go autodocuments really well Go has better safeguards to prevent bad dev behavior There shouldn't be any more tests, you're testing an API either way

We're not talking here about documenting apis.

We're talking about documenting an architecture, how pieces work together, what tools are available, where to put things, etc. Check the documentation of any major web framework. That's what we're talking about.

Post reply on HN