Live data from Hacker News

Autotuner: How to speed up your Rails app

railsatscale.com

21–30 of 68 posts

Re: Autotuner: How to speed up your Rails app

#21

I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.

This thread seems to be getting some views. I'm looking to break into the Rails work, but it seems rough trying to get into a job doing Rails work as a junior, not quite senior role. I have other development experience, primarily in Ruby and Objective-C.

Any advice? I know the job market is a bit of a rough one right now as well.

Re: Autotuner: How to speed up your Rails app

#22

Earlier quoted context omitted.

The problem is the "just switching" typically means a full rewrite and has a ton of logistic challenges. Are you gonna higher an entire second team? What happens to feature work on the current system? If you keep going full-throttle on features, you'll never catch up. If you stop developing features for a prolonged time, you are putting your entire business at risk. Writing new services in Java might help, but still…

Rails on JRuby was a tenable proposition last I looked. Been a while though.

I was in a large org that did this for a while. It was extremely painful to be this far off the beaten path.

When you stay in the well trod C Ruby path, you benefit from the hordes of others who cleared the landlines before you. With JRuby, not so.

Re: Autotuner: How to speed up your Rails app

#23

Github: https://github.com/Shopify/autotuner It’s incredible how much Shopify is investing in Rails (& Ruby for that matter). And I assumr the investment is paying off because otherwise they wouldn’t continue like this.

I wonder what the break even point would be to just have switched to use JVM.

Stripe tried switching lots of code to the JVM and it was a huge disaster. Unless you already have lots of small services with clean interfaces and their own data stores that can be incrementally switched, you spend far more time bending over backwards to keep two systems running (one with some limited parity with the other) in tandem.

The cost of running the system is almost never bottlenecked by the performance of the language itself, but rather the responsibilities of the system and cleanliness of the code. Plus, in the migration, you start incurring the cost of your Ruby code calling your JVM code (and vise versa; your systems are almost certainly not a DAG), which almost certainly has higher overhead than whatever speedup you'd get from running code in the JVM in the first place. And then you're sharing protobufs/thrift files/whatever between different languages and libraries of varying degrees of quality (good luck with those Ruby protobufs!).

Before you know it, writing a little tool to optimize your Ruby garbage collector sounds like a really great idea.

Re: Autotuner: How to speed up your Rails app

#24

I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.

Where do you get the idea that the rails ecosystem is striving? I work on a big Rails monolith as part of my day job and the amount of abandoned libraries in the ecosystem and general quality of libraries is pretty miserable if compared to Golang, Java, Python, JavaScript and others.

I'm not saying it's a bad technology choice for a new company when all you need is to build a CRUD web app fast, but I wouldn't use it for anything that requires you to serve >1MB of JSON API responses or anything that requires concurrency, substantial IO, lots of API interactions with external services, low latencies, lots of memory or compute heavy computations, etc.

Re: Autotuner: How to speed up your Rails app

#25
post #24

I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.

Where do you get the idea that the rails ecosystem is striving? I work on a big Rails monolith as part of my day job and the amount of abandoned libraries in the ecosystem and general quality of libraries is pretty miserable if compared to Golang, Java, Python, JavaScript and others. I'm not saying it's a bad technology choice for a new company when all you need is to build a CRUD web app fast, but I wouldn't use it…

Just to give you a concrete example:

We use grape-api for some of our API endpoints. I needed to set some custom cache headers for some GET API responses and was looking into gems that do that for grape. They have a list of 6 libraries in their docs [1] that they recommend.

Their newest commits were 4, 9, 9, 10, 8 and 9 years ago, respectively. This is just one example, but I would bet half of the libraries in our transitive dependency tree haven't seen any maintenance in this decade.

https://www.ruby-grape.org/projects/ [1]

Re: Autotuner: How to speed up your Rails app

#26
post #19

I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.

with hotwire, rails is nearly a superpower. 90% of what react gives you at a tiny fraction of the dev time costs.

And a fraction of initial load time... and HTML rendered on first load without adding anything to the framework.

Re: Autotuner: How to speed up your Rails app

#27

I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.

Ruby is incredible. It is still one of the best choices for a platform to build a company or a product quickly with. If it cannot keep up with your scale, throw more hardware at it and it will still be worth it in terms of time and man-hours saved. I only ever wanted compile-time linting and better autocompletion such as in the case of Elixir LS. Does something like that exist for Ruby now? How is Crystal these days?

There is ruby-lsp and ruby-lsp-rails. For the former to shine you do need to use sorbet but for any moderate to large sized rails app I'd personally recommend it anyway. Yes it's not perfect, yes it has a learning curve but boy does it make refactoring easier, faster and safer.

ruby-lsp-rails builds on top of that and hands out information on models and routes mostly

Re: Autotuner: How to speed up your Rails app

#28
post #11

Earlier quoted context omitted.

I would imagine with cutbacks on spending/investing I think people getting leaner and meaner will re-visit the sheer productivity you can get out of it. Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app) I can't even fathom what it w…

I remember what happened in the early 2000s and how companies pulled back on the tech they were using. A few years ago I was convinced that fat front-end stacks are a luxury of companies with "free" money, and that the industry would be making tough choices. (To be clear, there are applications that the SPA approach is best for, but many applications are being built that could just as well be served by an old-school…

I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.

Re: Autotuner: How to speed up your Rails app

#29
post #11

Earlier quoted context omitted.

I would imagine with cutbacks on spending/investing I think people getting leaner and meaner will re-visit the sheer productivity you can get out of it. Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app) I can't even fathom what it w…

If you haven't given Turbo and Stimulus a shot, I would recommend it. Way faster to write than React, and super fast and performant. I would say its definitely the way to go with Rails pages that aren't extremely simple.

Thanks! Definitely aiming to try them out

Re: Autotuner: How to speed up your Rails app

#30
post #11

Earlier quoted context omitted.

I would imagine with cutbacks on spending/investing I think people getting leaner and meaner will re-visit the sheer productivity you can get out of it. Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app) I can't even fathom what it w…

> I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison. Seconded. At my org, Ruby/Rails is our competitive advantage. Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed. The main downside is rails doesn't scale well re: complexity so regular refactors are n…

While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement full multi-level bills of materials? "

I said "no, can't do that - that's huge".

A weekend later of experimentation (thanks to one very kick-butt gem on that has an amazing way of managing trees) "actually, we may just be able to - it's going to be a long road though - setting expectations..."

A period of time later we've now implemented a full BOM planning/tracking system, tested well upto and beyond the numbers of items these types of companies expect.

To the point they cancelled their renewal with a big/established ERP vendor and went with us instead.

There's definitely some instances where speed to market trumps everything else. We can go optimise queries later on.

What's been fascinating is I left my day job 2 years ago (to the month). We've gone from unheard of to becoming the market leader in our space. There is absolutely no way that could have been done with any other stack (without spending 5x the money - and I argue that co-ordinating a bigger developer team it almost wouldn't matter what money you throw at it, it gets exponentially harder getting everyone on the same page for delivery).

At my old workplace I couldn't convince the .NET team for love nor money to look outside the box.

Post reply on HN