Hacker News Reader

Comment by rdhgfdgrdhgfdg | Hacker News Reader

How is it demised? Shopify, Stripe and many new YC startups use it.

I think it's easy to say it's declining based on things like Red Monk's ranking, but with GitHub, Stripe and Shopify behind it, it's not going anywhere soon. And apparently Rails us is slowly increasing: https://arstechnica.com/gadgets/2021/09/php-maintains-an-eno...

Gitlab, too

Yeah, three companies worth an estimated $300B can keep any language alive. It’s fascinating to track the second wind of out-of-fashion languages, held aloft by a few mature companies that depend on it.

I'd argue even without them Ruby would be alive in the sense that the core language would get frequent updates. Even Perl is still alive https://github.com/Perl/perl5, even in a healthier state than I would have thought.

Oh wow, Perl is still getting monthly updates - I knew it was on the decline but I thought the whole Perl 6/Perl 7/Perl 11 fragmentation had left things in a worse state.

I’ve heard of Raku (Perl 6), but didn’t realize there was a Perl 7 or Perl 11. Pretty interesting problem. In Java land you get Java 8, current Java, Groovy, Kotlin, etc. So Perl is in good company in this regard.

Perl 11 was a thought experiment. It never actually became anything beyond a website expressing that notion. It got no traction from anybody apart of the originators. And of that I'm not really sure either.

Facebook and PHP are kind an interesting twist on that. Facebook spent a lot of time and money on Hack/HHVM, then the PHP core devs responded with a new version of PHP that is, in many cases, faster. Though Hack/HHVM is still better for async work.

Isn't that graph hopelessly tainted by eg. the dominance of WordPress? I mean, yes that's PHP, but just because 80% of sites are running it doesn't mean 80% of development is in PHP. Far from it.

All those kind of charts have the same problem. It’s like asking “what food do people like the most?”, and answering “rice” because so many people eat it every day. The problem is that the question is so vague you can answer it many different ways, and all of the answers are correct.

What people usually mean when they use those stats is “look how popular my choice of language is”.

It is, but discounting PHP because of WordPress from that graph is still interesting - I doubt there are free one-click installs for ASP.Net like there are for WordPress for example, but are there for Ruby on Rails?

The comparison does not make sense. WordPress is a CMS that happens to be written in PHP, while ASP.NET and Ruby on Rails are frameworks for building web services which don't do anything by themselves. At best you would get a blank "Hello world" page and nothing more from a "one-click" installer.

That graph counts site using Shopify. And shopify represent 80%+ of RoR usage.

Stripe does not use Rails. It uses Ruby for some backend services with its own custom ORM framework, logging etc.

Rails hasn't had any interesting updates since version 4, and arguably introduced a few regressions IMHO (I'm looking at you, active storage and action cable)

Ruby hasn't evolved much either.

Rails only scales so far and then scaling gets really challenging, obviously the named companies have figured it out, but its not easy. For example, rails due to the high coupling between models and the database, rspec test get very contrived trying to setup the db state for each test run. Compared to other languages like Python or golang where the sql-layer is abstracted from the model layer.

Compared to languages like Python which provide very similar developer experiences but also the power of ML modeling, ruby is falling behind.

I highly doubt that you will reach the scaling limits of rails unless you have a massive product and even if you do Python would not be a good replacement.

Depends on the product. The Rails architecture is fine for CRUD apps, and Heroku will happily take more and more money for more and more database capacity. As long as your ARPU is solid, you're fine scaling like that.

But there are more things in the world than CRUD apps. I'm building tools to track hate on social media, and there's a lot of social media out there. Rails, or any RDBMS-centered architecture, won't cut it. And if you're not using Rails, then I think the case for using Ruby isn't very strong these days; Python has a bigger community and is much stronger in important niches, like ML. So we picked Python as our default language not because the Python runtime is vastly more efficient than the Ruby one, but because the ecosystem is a much better match for our needs.

I wish it were the other way, as honestly I like Ruby better as a language. But my personal tastes are ultimately a pretty small factor when I'm picking the tooling for a project.

For implementing ye olde business logic, which is far more common in software development than cool tech such as ML that is discussed a disproportionally high amount compared to its real-world usage, Ruby on Rails wins. Sure, there are lots of frameworks that are good for shipping business features quickly, but Ruby on Rails is still among the leaders of that group due to concise code, magical defaults that give you a boost, an excellent ORM, view helpers for sooooo many common scenarios and edge cases that the JS world is still playing catch-up to, etc. And a lot of the new defaults in Rails 7 are aimed at reducing complexity and rescuing developers from the insanity of front-end development.

Great for CRUD, yes, but plenty more than that. Soooooo many apps don’t need to wrestle with a huge amount of data or even a data warehouse or analytics or a data lake or any data science or anything requiring even a blazing fast query time on a super complex gnarly data model, and most of those would ship faster by using Rails, and be easier to maintain as well.

But the devs don’t tell management that……

You and the person you're responding to are agreeing that you should use the right tool for the job, and there are plenty of jobs that Rails isn't right for.

There's a lot of "ye olde business logic" in what I'm building, for people who often change their mind about what they want. A Rails API (with Postgres and Elasticsearch) makes this fairly easy to handle, especially with the limited staff we have. A Vue.js client provides the fancy UI the users want.

You still have the GIL in python to overcome.

Not really. ML in Python basically means lots of C++ libraries and you can just split processes as much as you want as it's easy to parallelize. You could do the same in R, Ruby, any scripting language really (but Python already has all the glue stuff ready to go and is easy).

Ruby (MRI) also has a GIL

It sure does.

If you will grow big enough surely you will need some kind of web presence - then you can introduce Rails :) Or don't. Honestly having the team on one language makes a lot of sense.

If you are just trying to pull as many records from an api and run it through ML Python would make a good choice.

If you wanted a website to handle traffic rails or even php would be a better. Both have a more mature ecosystem and both allow for rapid development.

Rails doesn't scale? Github's the largest code repository site in the world. Stripe's one of the largest fintech sites in the world. Shopify is one of the largest ecommerce sites in the world. There's also Airbnb, TripAdvisor, many others that are huge.

Also, you can write shitty, slow code in any language. You can make too many calls to the DB in any language. You can also scale to Google size in any language.

Python isn't a quick language. Also most of the ML bits are C++ bits. Ruby is faster than Python for most things. But Google (and others) have done well with Python (and other bits). Facebook got huge with PHP (which no one truly likes).

Ruby is a fine language (also very pleasant to use), Rails powers many huge companies, sometimes nitpicks are just that.

Stripe never used Rails. It uses Ruby with in-house ODM libraries, logging frameworks, and more. And a lot of those features are being moved to Java services.

> Rails doesn't scale? Github's the largest code repository site in the world.

You know, i think i understand both of the viewpoints here. Personally, i'd say that Rails doesn't scale as well as i'd expect it to. You can definitely build scalable systems in it, though you'll end up throwing a whole bunch of hardware resources, when compared to certain other languages and technology stacks, to serve similar load.

For example, right now i self-host a GitLab (https://about.gitlab.com/) instance for managing my code repositories, CI builds and so on. Even with just me using it (alongside some automated processes), it routinely eats up close to 4 GB of RAM, which in my case is an entire VPSes worth and costs me about 60 Euros a year with Time4VPS (affiliate link, if you'd like to check it out: https://www.time4vps.com/?affid=5294) but would cost me way more in AWS, GCP etc. One could argue that that's not too expensive, but not everyone earns a lot of money and running 10-20 VPSes does eventually add up, since i can't afford colocation and my residential homelab setup with a WireGuard tunnel to bypass ISP NAT with a proxy VPS is pretty slow, even if i can afford more storage, RAM and CPU power that way.

Compare that situation to projects like Gogs (https://gogs.io/), Gitea (https://gitea.com/), GitBucket (https://gitbucket.github.io/) and sourcehut (https://sourcehut.org/) - i'd argue that all of them on average use less CPU resources and memory for accomplishing similar tasks.

However, we cannot ignore the fact that using Ruby might have been exactly what allowed for quickly creating the functionality of GitLab and many other platforms and tools out there, GitHub included, so the choice between usable software and innovation in the near future and performant software possibly years from now is a tricky one.

There are probably good arguments for both, but noone can declare either to be better. Personally, i don't mind using Ruby, Python or even PHP when it makes sense and i don't need to worry about scalability from day 0.

it routinely eats up close to 4 GB of RAM, which in my case is an entire VPSes worth and costs me about 60 Euros a year

You are absolutely correct that running other peoples Ruby code is expensive. I would argue similarly for Java because of the high RAM requirements.

However, if you are a company developing your own software, if you use a more productive technology and it spares just 1 programmer then you have paid for a few hundred VMs and running costs become insignificant compared to labour costs.

This is an argument in favour for both Rails and the Java monsters.

Github does make it work, but you can see there's a tradeoff for that. Like in this blog post:

https://github.blog/2020-08-25-upgrading-github-to-ruby-2-7/

You see mentions of 70 second application boot times. Also interesting is the reference that a future upgrade to Ruby 3.x might increase performance by a factor of 3. That would mean they are leaving quite a lot on the table right now.

Basically, yes, they make it scale, but that's not free.

Ruby 3 being 3x faster is based on a video game emulation benchmark. Rails sites won't see anything like that. The ruby team chose a really specific benchmark to target and it's frustrating that it's not communicated well, leading to understandable misunderstandings.

Somewhat interesting then, that Github cites the 3x without that context.

You don't know what you are talking about. Every Rails release from 4 adds a ton of new stuff, bug fixes to the framework.

ActiveStorage is great addition - storing files on AWS now takes 30 minutes at most to setup. You don't need to use external gems for the same functionality now. Labeling it as a regression is nonsense as Rails before didn't have the functionality at all.

Ruby also evolved a ton since Rails 4. Just look at changelogs or something.

Scaling Rails is same as scaling any other stack. If your software grows it will run into bottlenecks no matter what you use. Rails is no harder to scale than anything else. It mostly is about people, not stacks anyways.

And i think mentioning ML points in a direction that you don't know much about normal web development since for 99% of web things you don't need any ML at all.

ActiveStorgae was launched half-baked. Downloading files on the back end was missing from 5 and not introduced until 6. This seriously burned us as we had to put off implementing a ton of what should be easy reporting features until we could get around to upgrading from 5 to 6. Rails strategy of bundling everything together was a huge problem. With Rails7 it looks like ActiveStorage has finally reached parity with Paperclip, so while its nice that there's a built-in option, fundamentally we're still back to where we were years ago, as its not like it took longer than 30 minutes to setup Paperclip either.

Arguably the most popular filetype stored with a rails app is images, but ActiveStorage didn't even support CDNs. 3rd party gems like CarrierWave supported CDNs do.

Instead of adding exactly what gems you need, rails forces you to jump through hoops to removed bloatware (ActiveText, ActiveCable, ActiveStorage).

Moving off of the rails asset pipeline to webpack was silly. If you're running a SPA, you should have a fully separated web-app and tooling stream instead of trying to merge your backend and frontends. For server side rendering, asset pipeline was good enough IMHO.

ActiveText doesn't even support CRDTs. Otherwise it doesn't really add much value to advanced text editor eco-systems.

The change logs are either adding bloatware that only Basecamp asked for, bug fixes, or security patches.

> And i think mentioning ML points in a direction that you don't know much about normal web development since for 99% of web things you don't need any ML at all.

This sounds like someone that has either only worked with webapps with very few users and not at big tech scale. You can get away with not using ML in b2b products with 5 customers, but at some point you will need to add ML to scale.

Man, is calling ActiveStorage a regression ever spot on. Wish we'd never have used it and stuck with Paperclip.

ActiveJob was Rails4, so I can see where you're coming from there, but ActionMailbox from Rails6 has been a huge win for us. However Webpack has been a disaster. And then the odd evolution of Turbolinks and Stimulus in parallel.

With Rails7 rolling back Webpack and uniting Turbolinks and Stimulus under Hotwire, ActiveStorage finally getting to a good place, and ActiveRecord getting more and more niceities between 4 and 7, then factor in Ruby3's nice perf improvements, I'd say Rails is actually in a much more interesting place than it has ever been. The road from 3 to 7 has been rocky for sure, but for the first time in awhile I'm actually excited to spin up a new Rails project.

Reply on news.ycombinator.com