Hacker News Reader

Comment by ulizzle | Hacker News Reader

The problems with Rails are the same as with Ruby as it was with Smalltalk: just too easy to make a mess (the nature of dynamic languages), and its community suffers from a nasty case of groupthink.

Notice the cliche "Rails is so much more than a framework."

The same magic that makes one so productive at the beginning (start-up stage) is what comes back to bite you in the ass when the project grows into an actual product; unless you are careful and willing to trade off speed-to-market, which isn't what you want to do with a startup.

Catch-22 because the app has gone off the rails by the time you are successful, and everyone says: "Oh, you shouldn't have done that."

View on HN

Could you share some examples of this?

I am a bit over >1 year with Rails and I don't see this to be the case. There is some "group think" perhaps, but every ecosystem has that (Whats the "pythonic" way or Java way to write x). I work at Shopify which uses Ruby and Rails extensively, and I don't think things have "gone off the rails". We use other technologies where appropriate, but for the core business logic cases, Rails is fantastic.

You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc; which is something you can't say publicly, and even if the company did, it would be heavily doctored to make a good impression on stakeholders.

That's why I think the argument is a weak appeal to authority. Throw enough money at a problem, and you can scale anything involving computers. Notice how expensive is Heroku.

But you can't add more team members to a project and expect things to go faster, which is where the real problem with Rails lies.

I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience.

The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively.

I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it.

At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way.

Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.

Just because you can’t square it with your experience doesn’t mean much. What you want to do is compare your experience with others.

Rails can work well but it’s going to be expensive. Everything is a trade-off.

Because Devs don’t see operating costs, they don’t feel the pain.

Seeing as developer salaries are the biggest cost and I just talked about how I've seen fewer developers deliver more over significant time with Rails your comment doesn't make any sense.

Anyway both of our opinions are based on anecdote. It would be interesting to see an analysis on real data but I wouldn't trust that anyone could get that data from industry, correctly accounting for failures.

Your experience matches mine. 100% agree on this.

Those metrics you’re asking for, I’ve seen them to vary wildly within the exact same stack at different companies, or even within the same company at different teams.

I don’t think they have anything to do at all with the stack. I think they’re more related to the people, the working culture, the practices and in particular the rotation and the “happiness” within the team

The sheer amount of tooling that Shopify has built to overcome this is a good example.

https://shopify.engineering/shopify-made-patterns-in-our-rai...

"Going off the rails" isn't an indication that Rails is bad, as much as a claim that it can't fit the needs of a company with either splitting to other technologies ("We use other technologies where appropriate") or painting outside of the Rails lines.

Any company at scale develops these other solutions to help scale. A company using Java and Spring does the same or C++ or whatever. Shopify seems to be unique at the largest (I think) Ruby/Rails shop, so they are leading the way developing a lot of these tools. I don't think that its significantly different than Google making Guava, Map Reduce, etc.

Bandcamp and hey aren't scalable?

Like, I am the first person to be pessimistic about a framework or language, but I've been working with both Ruby and Rails since 2007. Every single company that has strayed outside the defaults in the name of 'making a scalable app' has spent tons of money in tech debt, maintenance, etc. Yet the companies that stayed on the tracks had very few issues with scalability or tech debt.

I think pretty much all developers seem to forget that when you bring in a third party library or a unique pattern, you also inherit maintenance in both those areas.

The problem isn't the language or framework, the problem is that developers try to solve problems by deviating from tested and proven methods. "Convention over configuration" is what Rails is built around. Why do so many people prefer configuration over convention? Why not just pick another framework, or possibly even language if you are going to do this?

Note that I'm not affiliated with Rails, companies financially affiliated with Ruby and/or the Rails framework, and have no desire to be. I just like building awesome stuff.

Most companies are nowhere near a Shopify or a Google. I think it's totally fair to to admit that Rails is just one of many equivalent solutions that will eventually require scale out in a complementary technology, but that's not the sales of pitch of Rails.

Out of the box, Rails apps typically suffer from testability issues with fat models, problems caused by overuse of OOP patterns, and “ball of mud” lack of separation of domains. There are many ways to solve these problems with gems and specific disciplinary patterns, but Rails does not go out of its way to show them to you. Most people find their way out of the problems only after they are deep into them.

This is not specific to rails, at all. It can happen with any stack you use. If you prefer building on top of some minimalist framework, then it’s very likely you end up with worse problems. If you don’t because you’re an excellent programmer, then you wouldn’t have had those problems with rails either.

It’s not the tools what make things a mess or a great piece of art. It’s the people using it.

Do you use RSpec? Devise? etc.

There is your example.

Saying that dynamic languages are prone to make a mess is a kind of groupthink in itself.

Frankly, I think the bigger cliche is: “sure, it’s easy to get started, but Rails doesn’t scale!”

Rails apps are way over represented among large web-based businesses. Shopify, GitHub, Gusto, Airbnb, etc. There are countless examples of Rails scaling beyond what anyone could reasonably expect their web app to need.

I've worked with Rails at two companies: 500px and Shopify. The former was what I take to be typical use of gems and monkeypatching magic. I didn't like it, though I ended up doing myself to get other issues under control. (And luckily much new development were as separate services in Go.)

The Ruby/Rails at Shopify is much more sane (by my definition) looking much more like regular API made using a statically typed language (lots of Sorbet type info). There is of course dynamic magic, but tends to be limited rather than preferred, and where feasible static Sorbet type info is generated to match what the magic produces so users of magic can operate as if it was just a static typed library with a bit of DSL. There's enough in-house specifics that I wouldn't even call it Ruby on Rails, but rather Shopify Ruby/Rails and it's constantly evolving. There can be 3 ways of doing something: the old way (being phased out), the current way, and perhaps a new one being tested out in some part of the codebase.

Those companies are a product of the last wave, when Rails was very popular in tech, especially amongst San Francisco circles. There are also a lot of examples of that size that left Rails or never jumped on that trend. This is also an argument from survivor bias. You have to count the failures too, which we don't have numbers for.

It's not that it can't scale; it's just that it's too easy to make a mess in the way, which would prevent you from doing so.

So what ends up happening is that you pay for mistakes or someone else's, but at the end of the day, you are still on your own.

This list cements the idea that without massive budgets Rails becomes a challenge once you reach a certain point. The argument against Rails isn't that it can't scale, but that doing so requires a certain level of complexity that is untenable for certain sizes and types of teams.

Shopify has built massive tooling (https://shopify.engineering/shopify-made-patterns-in-our-rai...). Github was stuck on an old version of Rails for years due to the amount of customization they had done. (It was actually a big deal when they finally were able to run on the latest version: https://github.blog/2018-09-28-upgrading-github-from-rails-3...)

I hope that you'll watch the recording of the talk when it's released. The context of the "cliche" is with regard to the community, the framework, and why Eileen continues to remain on the core team. It's nothing to do with the design or functionality of the framework itself. :)

Incidentally I feel Rust is the reverse Ruby: more work (sometimes much more work) up front, but the big payoff comes in the long run.

Many typed languages are like that, but the big difference is that they admit the trade-off. In Ruby on Rails, dissent is a big taboo, so they blame the problems on the devs (the unwashed nameless masses) rather than tackle the problem itself.

That's why you have all these different tools and concepts; since they try to sandpaper over all the magical complexity by adding more complexity, it becomes a no-true Scotsman trivia game.

What trips me up tbh is how tech history repeats itself almost verbatim. The Smalltalk story is very similar but with a different cast.

In what way is Smalltalk similar? Its main problem was that it stopped evolving.

All software suffers from this. The whole point of programmable computers is allowing systems of unbounded complexity. Every tooling discussion degenerates into "it's a foot gun" vs "you're holding it wrong".

If you remove friction, people will build bigger foot guns. If you install too many guardrails, holding it right requires contortion.

The point is not which set of tools you use. There is no substitute for understanding the problem domain, the tools at hand and the labor market you have access to. Everything has a cost, you can't get free advantages from some technical insight or another.

I think there's a large class of apps where you end up writing less than 30-50k lines of code and things aren't a problem in the end.

I've built a video course platform now in Flask, Phoenix and Rails and I've built about 60% of the platform in all 3 tech stacks. The Rails app has ~7k lines of code (LOC count includes everything but tests), it's substantially less than the others. The Phoenix app was by far the worst of the 3 in terms of how much code I had to write and overall "difficulty" of the code. The Flask app sat somewhere in the middle, at times it made doing certain things easier and more efficient than Rails but if I had to rank overall developer happiness and how easy it was to do things it would be Rails > Flask > Phoenix where let's say Rails is a 8.5 in terms of happiness, Flask is a solid 7 and Phoenix was maybe a 4 or 5. This includes a number of real-time elements like having a persistent video player that survives across page navigations, notifications and comments being broadcast to all connected clients with authentication and more.

Surprised about your score for Phoenix.

What exactly were the painpoints?

My impression was Elixir / Phoenix was ranking high in developer happiness.

Developer happiness includes all facets of development IMO. The language, 3rd party packages, the overall ecosystem, the community, etc..

Elixir isn't really in the same ballpark as Python and Ruby for package support. Lots of 3rd party vendors don't have official SDKs for Elixir and having to recreate certain components of those SDKs manually can be very tricky. This is especially true for payment gateways like Stripe, Payal, Paddle and others since there's gory details about certain things aren't as easy as making an HTTP call with a token. So you end up having to recreate these things from scratch because most community versions are abandoned due to them being maintained by 1 or 2 people who stopped using it.

Also, LiveView's APIs keep changing. The amount of churn was out of control for a few years where it felt like every few months you had to make drastic rewrites to keep up with it all. At the same time the docs are very minimal and community support through blog posts weren't there in the same way they are for Rails and Flask. It felt like you were on your own to solve everything in a fast moving world with an ever growing API.

Then for the language, Elixir didn't click for me, even after writing 10k lines of code. I felt like I could get pretty far and understood enough to get most things done but I felt like I was getting stonewall'd quite frequently and couldn't solve certain basic problems after exhausting all pre-existing resources (my brain, docs, blog posts, open source projects, etc.). I don't feel I have this same issue in Python or Ruby. There's such a big community that nearly everything can be found, or at least get you to the point where you can apply something to your domain without asking in chat for help.

A good example is https://github.com/josevalim/nested-map-reduce-traversal which is something Jose and I worked on a few years ago. If he didn't step in and provide an example on how to do what's essentially a nested loop while modifying a counter in Elixir I would have had to stop developing my project. I still have to step back and spend a full 5 minutes trying to mentally parse his solution where as the Python and Ruby solutions are immediate with no effort.

When trying to build a pretty big project, these routine blockers or having to spend 3 hours (or 3 days) down a rabbit hole vs just doing it in a few minutes make a big difference -- this is also after spending months learning the language and ecosystem already. You end up getting fatigued from having to build so many libraries to get to the point where you can work on your main's app goal and it's demoralizing getting hard blocked. There's also this pit in your stomach that's concerned at how quickly you can get stuck in a way that you can't self-resolve. When trying to build a business, these are all very dangerous things.

You put all of that together and my happiness level for Elixir was kind of low.

It's nothing personal, just my opinion. I think it has good ideas and concepts in places but it didn't feel like the juice was worth the squeeze for someone like me who didn't already have many years of functional programming experience beforehand. Flask and Rails are both fast enough where you can build a million dollar a year business on a single $40 / month server with tens of thousands of customers. You can still get p95+ <= 100ms response times from your back-end in this scenario and both tech stacks have a good story for using websockets nowadays. Thankfully Hotwire Turbo is back-end agnostic which means you can build really nice feeling front-ends with any tech stack with minimal JS. I'm really happy DHH pioneered this pattern with Turbolinks which evolved into something wonderful.

Thanks for sharing your experience.

Somehow makes me think for this web stuff just use a well established glue language / toolkit with a huge and thriving community, e.g. like you mentioned RoR, Flask or even Laravel ;) - which lets you focus more on building your solution for your business problem.

And for certain things where it's niche, e.g. you need real time with hundreds of thousands of nodes, self healing etc features, use Elixir with BEAM.

No problem.

Yep your comment sums it up well. Although Kubernetes does allow you to horizontally scale decently well with any tech stack. I've run a few Flask + Celery apps (replace that with Rails + Sidekiq or whatever your preferred stack is) on Kubernetes and it's working out quite nicely. Zero downtime deploys (and even node upgrades) with a deployment model that makes sense for individuals and large teams (gitops philosophy using well supported tools like Argo CD, etc.).

For things that don't need that scale, a single server with Docker Compose does the trick. I've been doing that for about 8 years now with Docker and Ansible. ~20 lines of YAML configuration to get a machine from ground zero to fully up and running, secured and serving any Dockerized app of your choosing over a custom domain with SSL with automated DB backups, monitoring, logging, etc..

Reply on news.ycombinator.com