Ask HN: Is Ruby on Rails still relevant?
159 comments
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.
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.
"trying to build services alongside it is truly awful"
That makes no sense. It's very easy to build a REST API in Rails in which case you can connect to that API from services written in other languages. Conversely, you can easily call out to other services' APIs from Rails.
In fact, I'll go so far as to say building a few choice services in particularly performant (lower-level) languages alongside a main Rails monolith is the best organizational pattern for larger applications and enterprise deployments. You get all the benefits of Ruby & Rails for most happy paths, as well as the benefits of "This goes to 11!!!" performance for the critical paths which need that.
That makes no sense. It's very easy to build a REST API in Rails in which case you can connect to that API from services written in other languages. Conversely, you can easily call out to other services' APIs from Rails.
In fact, I'll go so far as to say building a few choice services in particularly performant (lower-level) languages alongside a main Rails monolith is the best organizational pattern for larger applications and enterprise deployments. You get all the benefits of Ruby & Rails for most happy paths, as well as the benefits of "This goes to 11!!!" performance for the critical paths which need that.
Yup its just that everyone else needs to learn the spaghetti code in the monolith. Which is universally hated by everyone not in the rails ecosystem
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 know other teams did the same (at least consumer and merchant), but I didn't work on those projects so I can't speak to them.
I've seen 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.
After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches.
Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable.
These are all tools in the tool kit. Use what lets you ship.
I've seen 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.
After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches.
Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable.
These are all tools in the tool kit. Use what lets you ship.
> 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
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.
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 were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time.
Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented.
It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth?
The Rails application.
if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice.
But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application.
People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time.
Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.
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 were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time.
Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented.
It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth?
The Rails application.
if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice.
But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application.
People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time.
Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.
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 to migrate from Ruby to Go to improve productivity is a blatant lie.
To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.
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 in popular full stack frameworks.
But managers/directors, etc aren't idiots. They swallow it and they accept it even if they know the trade offs, because what's not told here is that if management says "No, that's madness" then people quit, and that's worse. So there we go with our super performant microservices for our 10 reqs/s app.
But managers/directors, etc aren't idiots. They swallow it and they accept it even if they know the trade offs, because what's not told here is that if management says "No, that's madness" then people quit, and that's worse. So there we go with our super performant microservices for our 10 reqs/s app.
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
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.
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.
What do you mean there shouldn't be any more tests?
huh? Go has had ORMs for ages and they are fine
> 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.
“Those who cannot remember the past are condemned to repeat it.” – George Santayana, The Life of Reason, 1905.
> if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Gosh I'm old.
“Those who cannot remember the past are condemned to repeat it.” – George Santayana, The Life of Reason, 1905.
> if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Gosh I'm old.
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 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.
Just on time! https://news.ycombinator.com/item?id=31191700
Rails does not have to be written as a monolith. Typically, junior programmers who are trying to move very fast do that. Most of the places where I have talked to people who have a monolith are looking for ways to split it into services.
If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.
If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.
Not sure Go is a very good example here, compiled languages have a huge maintainability advantage in monoliths (at the cost of compile time).
Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.
Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.
"Rails monoliths are so much more difficult to maintain"
I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages.
"manipulate things globally"
Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.
I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages.
"manipulate things globally"
Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.
Global? In "Rubyland?" No. That's just not true. Not at all.
That's totally fair, it seems to trend toward a monolith though, just from what I've seen
I work at a company with a large Rails monolith and it's a delight, and so is the monolith.
I've had great experiences with both Ruby and Go. Both are a joy to write, and can handle most use cases. When I'm writing Ruby I sometimes wish I had Go's type system and lightning fast test suites. When I'm writing Go, I sometimes wish there were more conventions so I didn't burn so much time thinking through the absolute perfect way to architect every little thing. Still, they're both wonderful languages that hopefully fade to the background of your consciousness so you can focus on the actual business goals at hand.
Use Sorbet. It provides a better type system than the go typing system.
> 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.
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
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
Ruby may not be opinionated but Rails is - convention over configuration is a core philosophy. It's one of the reasons it's so easy to get started with.
Monolith vs microservices is not the problem. It's architecture and code design in most cases.
When i hear "Rails monolith is a disaster" what it usually boils down to 8 out of 10 times is people putting their business logic inside models or controllers, when really it should live in its own set of classes, usually called services or service objects.
Here's a guide https://codeclimate.com/blog/7-ways-to-decompose-fat-activer...
When i hear "Rails monolith is a disaster" what it usually boils down to 8 out of 10 times is people putting their business logic inside models or controllers, when really it should live in its own set of classes, usually called services or service objects.
Here's a guide https://codeclimate.com/blog/7-ways-to-decompose-fat-activer...
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.
Why is a disaster?
I ask this genuinely as I am interested to see what pain point people have with Rails.
I ask this genuinely as I am interested to see what pain point people have with Rails.
Two primary reasons:
1. Ruby is a very flexible language, and that has its ups and downs. While it makes it a very pleasurable easily modifiable syntax, it also leaves a lot of room for bad patterns. Ruby won't judge someone for taking an ill-advised approach to a problem, so it's easy for newcomers or novices to lay foundations that cause trouble later on.
2. Ruby is very prominent in startups, which are the companies most interested in immediate results. This often leads to favoring short-term advantages such as getting a feature out today to secure a deal rather than long-term advantages such as taking the time to keep a maintainable code base. Some startups with strict budgets will also hire people with less experience early on, leading this to pair with point 1 more often than we'd like.
That said, I'm a Ruby dev and have no interest in working in any other language (other than JS on the frontend). It's a beautiful tool to those who treat it well and I'll happily use it for just about any project.
1. Ruby is a very flexible language, and that has its ups and downs. While it makes it a very pleasurable easily modifiable syntax, it also leaves a lot of room for bad patterns. Ruby won't judge someone for taking an ill-advised approach to a problem, so it's easy for newcomers or novices to lay foundations that cause trouble later on.
2. Ruby is very prominent in startups, which are the companies most interested in immediate results. This often leads to favoring short-term advantages such as getting a feature out today to secure a deal rather than long-term advantages such as taking the time to keep a maintainable code base. Some startups with strict budgets will also hire people with less experience early on, leading this to pair with point 1 more often than we'd like.
That said, I'm a Ruby dev and have no interest in working in any other language (other than JS on the frontend). It's a beautiful tool to those who treat it well and I'll happily use it for just about any project.
in my experience, the main pain point people experience is:
a) they don't like Ruby for whatever reason, b) they probably only deal in backend or only deal in frontend, and so don't understand the value of the bundled dev experience rails delivers, and therefore c) because of a + b they find the moderate learning curve to be extra painful, so they lash out.
at the end of the day it's all just code. why would it be harder to integrate a service in Rails than in Go? of course it isn't.
a) they don't like Ruby for whatever reason, b) they probably only deal in backend or only deal in frontend, and so don't understand the value of the bundled dev experience rails delivers, and therefore c) because of a + b they find the moderate learning curve to be extra painful, so they lash out.
at the end of the day it's all just code. why would it be harder to integrate a service in Rails than in Go? of course it isn't.
Shopify Developer here (opinions are my own) we are running Ruby on Rails (obviously) and we do well with it. It's fast to develop, fast to deploy, fast to test. I have no complaints with it. I would say my gut says that there are fewer bugs, fewer issues, fewer on call incidences, less downtime, and faster development speed than when I worked in a Java shop with micro-services and serverless and plenty of modern things. Technical culture, discipline, quality of engineers and leadership matter so much more than what your tools are imo.
"Technical culture, discipline, quality of engineers and leadership matter so much more than what your tools are imo."
Yes! Behind every principle there's a promise. https://twitter.com/jessethanley/status/813904788702183425
Yes! Behind every principle there's a promise. https://twitter.com/jessethanley/status/813904788702183425
> Technical culture, discipline, quality of engineers and leadership matter so much more than what your tools are imo.
Hear! Hear!
Hear! Hear!
First check https://israilsdead.com/.
If you want to learn Ruby on Rails in 2022 please check https://gorails.com
If you want to learn Ruby on Rails in 2022 please check https://gorails.com
Define dead. Some people don't think Cobol is deal. Or Fortran. In this sense the code is still run somewhere and there are still jobs to be had.
But the question is probably around one's personal choices: is this the framework to invest my energy and time? Are there far better frameworks? Where is the market headed?
In the early days of Rails, and indeed any popular framework, the sense we get of an explosive growth. As a result of this there is an imbalance of jobs and developers and jobs seem easy, plentiful and well compensated.
This is really a question of the ratio of dev:positions. Most answers to this tend to focus on the positions component (take a look at stack, or upwork or indeed or whatever!). Perhaps someone on HN will suggest a metric or public gauge for the competition as well.
Edit: added slightly more context
But the question is probably around one's personal choices: is this the framework to invest my energy and time? Are there far better frameworks? Where is the market headed?
In the early days of Rails, and indeed any popular framework, the sense we get of an explosive growth. As a result of this there is an imbalance of jobs and developers and jobs seem easy, plentiful and well compensated.
This is really a question of the ratio of dev:positions. Most answers to this tend to focus on the positions component (take a look at stack, or upwork or indeed or whatever!). Perhaps someone on HN will suggest a metric or public gauge for the competition as well.
Edit: added slightly more context
For people in this thread comparing _Rails_ with _Go_ can you please help me understand something about Go:
Is it a language that also has in std/core library web framework like support? Like PHP?
I ask as I dont understand why people say drop Rails and learn Go. And I am looking to learn a new language along with Ruby and Elixir.
Why is Go compared with Rails and not with Ruby?
If Go does not include a default support for web frameworks then what web framework would you suggest for doing a web SaaS like management of posting on social media?
I dont want to create this but i use it as an example as it has image uploads, date/time, jobs, … things I can do easily in Rails and have already battle tested solutions available.
I ask as I dont understand why people say drop Rails and learn Go. And I am looking to learn a new language along with Ruby and Elixir.
Why is Go compared with Rails and not with Ruby?
If Go does not include a default support for web frameworks then what web framework would you suggest for doing a web SaaS like management of posting on social media?
I dont want to create this but i use it as an example as it has image uploads, date/time, jobs, … things I can do easily in Rails and have already battle tested solutions available.
The Go standard library has all you need to stand up a basic HTTP service. Which isn't the same as Rails by a long shot, but it does fit in well with what a lot of places are doing these days.
yeah, you'll see this argument a lot.
If someone feels like re-implementing all the wonderful conveniences of rails in Go, more power to them. However, that's a MASSIVE amount of work that you'll be doing _instead_ of actually making the webapp.
Go is great, but it's built in HTTP support isn't even _remotely_ equivalent to the many years of accreted utility in Rails.
To put it another way, it's a false equivalence. No-one should EVER say "learn go" instead of rails. Now, if they said "lean Buffalo" ( https://gobuffalo.io/ a Railsish framework in go) instead of Rails you could have a very reasonable discussion.
If someone feels like re-implementing all the wonderful conveniences of rails in Go, more power to them. However, that's a MASSIVE amount of work that you'll be doing _instead_ of actually making the webapp.
Go is great, but it's built in HTTP support isn't even _remotely_ equivalent to the many years of accreted utility in Rails.
To put it another way, it's a false equivalence. No-one should EVER say "learn go" instead of rails. Now, if they said "lean Buffalo" ( https://gobuffalo.io/ a Railsish framework in go) instead of Rails you could have a very reasonable discussion.
This is fairly inaccurate. The stdlib accomplishes a lot and unless you absolutely must have a wizard in your CLI to generate routes then you really aren't missing much at all. Having designed products in both, I'd prefer Go these days because unless I'm making todo apps there is a lot of decision and freedom taken out of my hands by using rails.
All of this disregards the speed advantage of go. There is no comparison between the two.
All of this disregards the speed advantage of go. There is no comparison between the two.
Generators, while nice, are nowhere near the most important thing that Rails brings that are often overlooked, even by "full featured" frameworks in other ecosystems.
- Migrations are well-implemented, and I've definitely wasted many cycles at other startups dealing with hand-rolled migration tools that are nowhere near Rails.
- The ORM (ActiveRecord), while very opinionated, is pretty full featured and suitable for 95% of use cases (and makes it fairly easy to drop out of it if needed)
- There's a host of security features that are taken care of you by Rails out of the box, including CSRF protection, session security and password hashing with a sane strategy and good algorithms (I'm sure there's others I'm missing)
- Websocket functionality comes out of the box with newer versions of Rails
- Asset handling, including minifying and digesting assets is included.
- Directory structure is set up for you (seems minor, but it's a huge productivity boost when joining a new team knowing where everything should be).
- A standard approach to background queueing, built in a way that it's extensible for different queue / worker backends (i.e. your jobs are cross-compatible with different background libraries and backend servers - I can come onto a Rails job that stores background jobs in Postgres, SQS, Redis, or anything else and how the jobs work is consistent).
Regarding speed, I'm certainly not going to argue that Ruby is faster than Go, but at least for the problems that I tend to work on, raw language execution performance is never really the bottleneck. It's cheap to throw money at, and 99% of the time when I look at poorly performing actions the culprit is the database or an external service.
- Migrations are well-implemented, and I've definitely wasted many cycles at other startups dealing with hand-rolled migration tools that are nowhere near Rails.
- The ORM (ActiveRecord), while very opinionated, is pretty full featured and suitable for 95% of use cases (and makes it fairly easy to drop out of it if needed)
- There's a host of security features that are taken care of you by Rails out of the box, including CSRF protection, session security and password hashing with a sane strategy and good algorithms (I'm sure there's others I'm missing)
- Websocket functionality comes out of the box with newer versions of Rails
- Asset handling, including minifying and digesting assets is included.
- Directory structure is set up for you (seems minor, but it's a huge productivity boost when joining a new team knowing where everything should be).
- A standard approach to background queueing, built in a way that it's extensible for different queue / worker backends (i.e. your jobs are cross-compatible with different background libraries and backend servers - I can come onto a Rails job that stores background jobs in Postgres, SQS, Redis, or anything else and how the jobs work is consistent).
Regarding speed, I'm certainly not going to argue that Ruby is faster than Go, but at least for the problems that I tend to work on, raw language execution performance is never really the bottleneck. It's cheap to throw money at, and 99% of the time when I look at poorly performing actions the culprit is the database or an external service.
There are a lot of things that rails gives you out of the box automatically which require either a lot of additional code in Go’s ecosystem.
CSP, csurf tokens, param parsing with array and hash map params, strong params, automatic response codes (201 for created for example), etags, … just from the top of my head. I’m sure I could find dozens more if I start looking.
All of those are possible in every stack of course but rails already gave you all of that from the time you typed “rails new”
CSP, csurf tokens, param parsing with array and hash map params, strong params, automatic response codes (201 for created for example), etags, … just from the top of my head. I’m sure I could find dozens more if I start looking.
All of those are possible in every stack of course but rails already gave you all of that from the time you typed “rails new”
you can go quite far with golang without needing any other library/framework with just std library which means less dependencies and lesser things to worry about in case of maintaining your code base, upgrading it with newere go version and ease of operation(since it is single executable).
Some of the basic things that you need that don't require frameworks are
1. http/https
2. authentication
3. sending mails
4. templating(it isn't powerful but you get by)
5. background jobs
6. date/time etc.
I am not familiar with ruby but my understanding is you don't get these out of the box you will need framework like rails for it. How easy/difficult it is to upgrade rails? for golang if you are sticking to stdlib it is trivial. If it is easy to upgrade/maintain/operate rails and you are familiar with it than don't switch.
I am not familiar with ruby but my understanding is you don't get these out of the box you will need framework like rails for it. How easy/difficult it is to upgrade rails? for golang if you are sticking to stdlib it is trivial. If it is easy to upgrade/maintain/operate rails and you are familiar with it than don't switch.
Upgrading Rails itself has been relatively simple for at least the last few versions. Between Rails 2 and Rails 4 upgrades were very painful, but that's settled down significantly. You won't necessarily get the new features available with new versions, but especially recently things tend to stay fairly backwards compatible, and when functionality is removed it's almost always moved to a separate library that can just be included with little fuss.
Rails is also a fairly complete package, and you can get very far without additional libraries. Once you do start to bring in libraries it can get painful, particularly if you stray off the path of very popular libraries, but it's nowhere near the Javascript ecosystem.
You're right that Ruby itself won't get you far in terms of a webserver, but the vast majority of web development is done with Rails so in that context it's analogous to thinking of Rails as almost part of stdlib when thinking about web development specifically.
Rails is also a fairly complete package, and you can get very far without additional libraries. Once you do start to bring in libraries it can get painful, particularly if you stray off the path of very popular libraries, but it's nowhere near the Javascript ecosystem.
You're right that Ruby itself won't get you far in terms of a webserver, but the vast majority of web development is done with Rails so in that context it's analogous to thinking of Rails as almost part of stdlib when thinking about web development specifically.
I don't think most are directly comparing them as it might seem on the surface. Simply pointing that, if ruby is past its prime, then rails is as well. We don't know what the end project is for everyone, so choosing a web framework here in the comments is kinda early in the discussion anyway.
There simply is no evidence whatsoever that Ruby is past its prime. People are committing myriad logical fallacies: comparing go language to rails framework, anecdotes about Ruby monoliths, incorrect statements of fact about Ruby capability and more.
I like Go, but this is a terrible comparison and I’ve not seen a single comment make a valid point about Ruby’s alleged demise.
I like Go, but this is a terrible comparison and I’ve not seen a single comment make a valid point about Ruby’s alleged demise.
Sounds a bit defensive, it is "past its prime":
https://octoverse.github.com/#top-languages-over-the-years
However, that doesn't mean it is dead, or you can't still do great things with it. Most platforms continue fine on into their twilight years :rofl:. Lotsa folks here getting shit done with perl and lazarus ide.
https://octoverse.github.com/#top-languages-over-the-years
However, that doesn't mean it is dead, or you can't still do great things with it. Most platforms continue fine on into their twilight years :rofl:. Lotsa folks here getting shit done with perl and lazarus ide.
You are confusing popularity with capability. Ruby is less popular than it was, but it is still very healthy and solving problems. It is also actively developed.
This entire exchange would not have happened if you had simply said, Ruby is less popular than it used to be.
“Past its prime” is a derogatory expression that is invalid in this use case.
This entire exchange would not have happened if you had simply said, Ruby is less popular than it used to be.
“Past its prime” is a derogatory expression that is invalid in this use case.
You've just defined “Past its prime,” congrats. :-D
> I ask as I dont understand why people say drop Rails and learn Go
Agreed. I don't think Go is that great for normal CRUD web development at all, maybe its interesting for super high concurrency / low level stuff.
Agreed. I don't think Go is that great for normal CRUD web development at all, maybe its interesting for super high concurrency / low level stuff.
Yes because it is still a hyper-effective and flexible way to build and iterate many products. And it's not just rails. The library breadth and quality of ruby libraries IME is off the hook great. Some kind of magic has happened.
Yes.
According to Hired's State of Software engineers 2022, Rails is the 2nd most in demand skill.
https://hired.com/2022-state-of-software-engineers/
According to Hired's State of Software engineers 2022, Rails is the 2nd most in demand skill.
https://hired.com/2022-state-of-software-engineers/
That post seems extremely suspect. I'm guessing that what they mean when they say "the most in demand skills" is the skills that when present on a resume, increase the odds of a user being contacted by recruiters, which isn't so much in demand as hard to find. By that metric COBOL would probably have been at the top of the list if hired had clients that used it.
The fact that there's entries for Ruby and Ruby on Rails also makes me think this, perhaps this data was just parsed.
I thought that was strange myself.
At the bottom of the page we get:
Methodology
This report is based on proprietary data gathered and analyzed by Hired’s data science teams. For the purpose of this report, Hired examined software engineering candidate interview requests and salary data from January 2020 through December 2021 inclusive. The data included reflects over 366,000 interactions between companies and software engineering candidates during this time period.
In addition to our proprietary data, we collected survey responses from more than 2,000 software engineers on the Hired marketplace to inform our understanding of software engineers’ working preferences.
At the bottom of the page we get:
Methodology
This report is based on proprietary data gathered and analyzed by Hired’s data science teams. For the purpose of this report, Hired examined software engineering candidate interview requests and salary data from January 2020 through December 2021 inclusive. The data included reflects over 366,000 interactions between companies and software engineering candidates during this time period.
In addition to our proprietary data, we collected survey responses from more than 2,000 software engineers on the Hired marketplace to inform our understanding of software engineers’ working preferences.
Do you have any evidence at all to support this or is it just a guess?
The evidence is that their "most in demand" includes none of top programming languages/tools according to pretty much anyone else. Therefore it's clearly not "in demand" in the sense that there are more job openings for those techs than for others. The explanation I posited seems like the most likely alternate definition.
Yes for three reasons:
- There's lots of RoR jobs.
- They keep improving it.
- What RoR taught me made me a better architect in every other stack.
- There's lots of RoR jobs.
- They keep improving it.
- What RoR taught me made me a better architect in every other stack.
> - What RoR taught me made me a better architect in every other stack.
I really have to second this point. I'm not 100% sure if DHH was the one who coined the phrase, "Convention over Configuration", but he's the first popular technical communicator who I remember emphasizing it in a clear way. Simply trying to be consistent about naming certain things like models or database tables (singular vs. plural) is a big win for any project. Nobody gets everything right, but RoR is filled with lots of little smart choices like that that are worth considering for your own projects.
I really have to second this point. I'm not 100% sure if DHH was the one who coined the phrase, "Convention over Configuration", but he's the first popular technical communicator who I remember emphasizing it in a clear way. Simply trying to be consistent about naming certain things like models or database tables (singular vs. plural) is a big win for any project. Nobody gets everything right, but RoR is filled with lots of little smart choices like that that are worth considering for your own projects.
I have been working on a Rails app at a rapidly growing organization for the past 6 years and I consider myself very lucky to be able to do so. Shopify, GitHub, and Stripe (to name some of the more prominent companies) all regularly contribute to the Ruby and/or Rails ecosystem, and there have been loads of wonderful improvements to both over the last several years: vastly improved performance in Ruby 3, support for static typing using RBS and Sorbet, Hotwire in Rails 7 for super low-lift client-side interactivity, and many, many more.
It’s a great time to start using Ruby for web projects.
It’s a great time to start using Ruby for web projects.
I have what I call my 80/80 rule of early-stage startups, which is that for 80% of new startups, 80% of what they need is CRUD operations (create, read, update, delete). So basically, input data in this format, store it in this format, then display it in this format.
I think Rails is one of the most productive and capable frameworks for building and evolving CRUD applications, which is the reason it still remains my recommendation for new startups.
I think Rails is one of the most productive and capable frameworks for building and evolving CRUD applications, which is the reason it still remains my recommendation for new startups.
Personally if I was starting a project in the same space as Rails/Ruby I’d go with Django/Python instead.
I prefer the “explicit is better than implicit” norm in the Python community over the “powerful yet mystifying magic” I find in Rails. (This is personal preference.)
I also appreciate Python source code being easier to manipulate with tools than Ruby, since Ruby did not have a formal grammar the last time I checked. Any tools that did exist appeared to usually include the yacc/bison file from MRI (the main Ruby implementation) as the best approximation of a language definition.
I prefer the “explicit is better than implicit” norm in the Python community over the “powerful yet mystifying magic” I find in Rails. (This is personal preference.)
I also appreciate Python source code being easier to manipulate with tools than Ruby, since Ruby did not have a formal grammar the last time I checked. Any tools that did exist appeared to usually include the yacc/bison file from MRI (the main Ruby implementation) as the best approximation of a language definition.
> "powerful yet mystifying magic" I find in Rails
Django might avoid this to some extent but Django rest framework has you covered.
Django might avoid this to some extent but Django rest framework has you covered.
Ruby has been on the downswing for a while, getting squeezed from all sides from the meteoric rise of Python on one side, JS/Typescript on the other, to higher performing static languages on another:
https://octoverse.github.com/#top-languages-over-the-years
It also has a funky syntax, while not a big deal, doesn't do it any favors in a C --> Javascript world. Django, golang, etc. are free. I don't recommend starting new projects in ruby, but as always YMMV.
https://octoverse.github.com/#top-languages-over-the-years
It also has a funky syntax, while not a big deal, doesn't do it any favors in a C --> Javascript world. Django, golang, etc. are free. I don't recommend starting new projects in ruby, but as always YMMV.
Your comment about "funky syntax" is meaningful.
I have found that people from the world of Java and similar c-style syntaxes, and especially strongly typed languages, have a sort of allergic reaction to Ruby. The reverse is also often true.
This is a matter of personal preference that actually tells nothing about what any of those languages might be good for.
Ruby/rails is less popular than it once was but it's still pretty popular. It's worth considering if you are open to the style of programming it uses. But if you love the c-style syntax, yes, you'll have problems getting used to Ruby and should try something else.
I have found that people from the world of Java and similar c-style syntaxes, and especially strongly typed languages, have a sort of allergic reaction to Ruby. The reverse is also often true.
This is a matter of personal preference that actually tells nothing about what any of those languages might be good for.
Ruby/rails is less popular than it once was but it's still pretty popular. It's worth considering if you are open to the style of programming it uses. But if you love the c-style syntax, yes, you'll have problems getting used to Ruby and should try something else.
This is the right answer. Yes people still write on rails but in my experience it’s because they haven’t used other tools.
I had a couple die hard rails members at my last company who claimed nothing was better. We made them write Go for a year and now they are die hard Go fans.
If I were writing a web app I would start with Go. It’s a great language that’s easy to learn and fast to write, with all the security of static compilation. It scales exceptionally well with large teams
I had a couple die hard rails members at my last company who claimed nothing was better. We made them write Go for a year and now they are die hard Go fans.
If I were writing a web app I would start with Go. It’s a great language that’s easy to learn and fast to write, with all the security of static compilation. It scales exceptionally well with large teams
I've never understood the Go / RoR comparisons. If someone goes from being a die-hard Rails fan to a die-hard Go fan, that feels very much like they're choosing their tools based on fashion / fandom vs. picking the right tool for the job.
Go and RoR couldn't be more dissimilar from each other. One is a relatively slow language with one of the most full-featured and robust frameworks available today, and one is a very fast language with relatively minimal tools for building web applications. The types of projects they're suitable for are completely different
Go and RoR couldn't be more dissimilar from each other. One is a relatively slow language with one of the most full-featured and robust frameworks available today, and one is a very fast language with relatively minimal tools for building web applications. The types of projects they're suitable for are completely different
I'm a die hard Ruby guy and now writing some Go and I pretty much hate it. I don't really care for performance or compile speed, I could barely care less. I want a good web framework with tons of community support and a language that lets me easily express my thoughts into code. I'm not getting that with Go.
Well said. I've been a great fan of Clojure for a long time but what stops me from using it for clients is the attitude in the Clojure community that libraries are favoured over frameworks. That's not to say there aren't a few web/REST frameworks in Clojure-land but they are invariably the product of a few individuals with no community support. And they wonder why Clojure has negligible adoption.
Go is great until you need to interface with a C library via cgo then you are in a world of pain with segfaults and the general mismatch between goroutines and C's ideas about concurrency.
I think the server side rendering part of rails has largely become obsolete but the api backend side of rails is still going strong. Some day other things like rust might replace it but I don’t see that happening any time soon.
Hmm, SSR is used quite often, it has just reached the boring stage. Also, rust is too BDSM for rapid CRUD building needs.
Obsolete is probably an overstatement but its in decline IMO. The last few companies I have worked at have moved away from SSR which seems to reflect a wider industry trend. I have worked mostly in enterprise web apps which client side rendering suits better which might have some bias.
If anything, I've seen the start of the reverse happening. The warts are starting to show on the pure SPA approach, and people are either finding ways to do more SSR with the SPA tools, or taking new approaches like LiveView in Phoenix or Hotwire in Rails to provide richer experiences while still generating HTML on the server.
The heyday of "SPA is the right approach for everything" feels like it peaked at least a few years ago.
The heyday of "SPA is the right approach for everything" feels like it peaked at least a few years ago.
Your sample is hardly representative. The big-league Node frameworks are all SSR-based due to the problem presented by pure front-end SPAs. Have a look at Next.js and Remix.
Yes, and it’s only getting better over time! Building complex front-ends, with states synced across different users, is a sheer joy using Turbo & Stimulus. It’s amazing how little JS is needed to create UIs that—when built in e.g. React—would have needed a ton of client-side code. I continue to be amazed how easy and fast it is to develop in RoR.
I wouldn't choose RoR as a new tech to pick up in 2022. Think of it like a more stylish PHP - lots of it out there, but mostly not in companies working on things that are compelling, and the market share is on the decline.
Github, Airbnb, Stripe, and Gitlab all use Ruby (on Rails) to a significant extend. Compelling things, if you ask me. Stripe is even developing Sorbet [0], a Ruby type checker.
Not that those are reason enough to use it. But I wouldn't call it the wrong decision either.
0 - https://sorbet.org/
Not that those are reason enough to use it. But I wouldn't call it the wrong decision either.
0 - https://sorbet.org/
They all started the projects from 2009-2013 picking Rails, the most popular web framework at the time: https://insights.stackoverflow.com/trends?tags=ruby-on-rails...
If you were to follow in their footsteps, you'd also be picking the top popularity web framework for your time, which as of now is things like Next.js and Django.
Big recent-era startups:
OpenSea (Django / Next.js)
Notion (Node.js)
ScaleAI (Python, Node.js, Next.js)
Substack (Node.js)
Rippling (Django / Next.js)
If you were to follow in their footsteps, you'd also be picking the top popularity web framework for your time, which as of now is things like Next.js and Django.
Big recent-era startups:
OpenSea (Django / Next.js)
Notion (Node.js)
ScaleAI (Python, Node.js, Next.js)
Substack (Node.js)
Rippling (Django / Next.js)
Shopify is another notable one.
I think it depends on the region. I started a project in Rails, and when I tried to hire people to help I found out there are very few people in my city who know anything about Rails. It's all Python and Java here.
So I'd recommend to look for job ads on local platforms and check if companies are looking for rails devs.
So I'd recommend to look for job ads on local platforms and check if companies are looking for rails devs.
Funny. I got my first full time programming job because they really wanted to do a project in Rails but there wasn't anybody else in town who knew anything about it!
Definitely a valid concern!
Though I would not let that dictate my choice of tools.
However if you want the biggest pool of "talent" and potentially the cheapest "talent" then going with the most popular is probably a good idea
Doesn't mean I'd advocate for the most obscure tech either, but it's all about trade-offs and your situation.
Though I would not let that dictate my choice of tools.
However if you want the biggest pool of "talent" and potentially the cheapest "talent" then going with the most popular is probably a good idea
Doesn't mean I'd advocate for the most obscure tech either, but it's all about trade-offs and your situation.
But hiring engineers isn't constrained by region or location so this feels like an odd argument to me.
Rails has been around long enough that there's surely no shortage of junior to very very senior engineers that will write code for you from wherever they happen to live.
Rails has been around long enough that there's surely no shortage of junior to very very senior engineers that will write code for you from wherever they happen to live.
Programming is not tied to geography unless you are dealing with physical equipment (you probably don't want three grocery store self checkout machines in your living room) or have any sort of security requirements for the project.
I get the argument for sure. Neither example is a really good environment for choosing rails specifically.
Also, not that it really matters but I just happen to be a counterpoint to both examples. I'm at home surrounded by hardware for my current work and also wrote / led a remote team instrumental in passing a federal banking audit atop infrastructure as code.
I'm on team sure there's use-cases for local hiring but they're so hard in the minority these days + it's a rails thread that I felt like my stance in my prior comment probably did hold in all cases where that might be the right tool for the job. Like all things though, it depends. :)
Also, not that it really matters but I just happen to be a counterpoint to both examples. I'm at home surrounded by hardware for my current work and also wrote / led a remote team instrumental in passing a federal banking audit atop infrastructure as code.
I'm on team sure there's use-cases for local hiring but they're so hard in the minority these days + it's a rails thread that I felt like my stance in my prior comment probably did hold in all cases where that might be the right tool for the job. Like all things though, it depends. :)
I'm good enough at English, and I've learned to collaborate somewhat effectively remotely, but if given the choice, I still prefer collaborating with people in person and speaking my native language.
Perfectly reasonable. I'll freely admit I'd never considered this argument and a language barrier does make a lot of sense. In some cases that constraint could affect the talent pool significantly.
This was also asked 9 years ago:
https://news.ycombinator.com/item?id=5483752
Interesting to compare answers to today.
https://news.ycombinator.com/item?id=5483752
Interesting to compare answers to today.
I'm guessing we'll hear the question again in 10 years...
If you Think Github, Gitlab and Shopify are relevant, then yes. Ruby on Rails remains an excellent technical choice for mature products.
Note that, just like any other tool it has pros and cons, one should analyze the system requirements and use whatever makes sense. I would however, dare say that it is a great fit for majority of businesses.
Honestly, majority of frameworks out there today will get you 90% of the way: Rails, Laravel, Phoenix and Django just to name a few.
As I get older, I tend to prefer boring tech myself..
Note that, just like any other tool it has pros and cons, one should analyze the system requirements and use whatever makes sense. I would however, dare say that it is a great fit for majority of businesses.
Honestly, majority of frameworks out there today will get you 90% of the way: Rails, Laravel, Phoenix and Django just to name a few.
As I get older, I tend to prefer boring tech myself..
My day job is as a JavaScript engineer, mostly doing React and Node. Some PHP which I never used before.
Last year during the pandemic I started to work on a side project, I picked Laravel because I heard a lot of good things, and having used Django in the past I know the value these frameworks provide. I'm building it using the "tall stack" [1] and it is just wonderful. The best part is not having to take 1000 decisions every second about what library or how to do this, or how to do that. Everything already has a place, and I can focus the little time I have to actually building what I want to build.
[1] https://tallstack.dev/
Last year during the pandemic I started to work on a side project, I picked Laravel because I heard a lot of good things, and having used Django in the past I know the value these frameworks provide. I'm building it using the "tall stack" [1] and it is just wonderful. The best part is not having to take 1000 decisions every second about what library or how to do this, or how to do that. Everything already has a place, and I can focus the little time I have to actually building what I want to build.
[1] https://tallstack.dev/
I had a call with a recruiter a few months back who said that the highest commissions were for Rails devs.
This would seem to indicate it is hard to find Rails devs, which itself might indicate devs don't like Ruby/Rails. If devs liked it and the market was growing as fast as devs were learning or slower, then commissions would stagnate or go down. So either the number of open jobs is increasing, devs are leaving, it's harder to learn than the sales pitch indicates, or a combination.
I 100% agree with your first part, but offer a slightly different conclusion - Ruby on Rails heavily skews to small startups (for various reasons not worth getting into here). Startups also tend towards Senior engineers, because they don't have the bandwidth to train junior engineers. So those recruiters are often looking for "Senior Rails" engineers which is even harder to find.
If the above is correct, it presents an interesting question to junior engineers: is it worth it to learn Ruby on Rails as a junior engineer? While there are advantages to learning Rails (it's heavily opinionated, what you learn maps very well to what professional projects look like), there is more job supply in the "python + LeetCode" path (how that relates to competition - who knows).
If the above is correct, it presents an interesting question to junior engineers: is it worth it to learn Ruby on Rails as a junior engineer? While there are advantages to learning Rails (it's heavily opinionated, what you learn maps very well to what professional projects look like), there is more job supply in the "python + LeetCode" path (how that relates to competition - who knows).
My personal experience (myself and my social group) suggests there's serious brain drain.
All my peers who started their careers with Rails that know it like the back of their hands have zero desire to ever work with it again professionally. They're all exceptional engineers who had no problems picking up/migrating to Scala/Rust without productivity loss.
On the other side, I see all the upcoming engineers that missed the initial Rails popularity wave. To them, Rails is often times much more frustrating than TS/Python offerings. There's very little freely available quality onboarding materials, getting the environment set up is incredibly frustrating with how fickle bundler has become, and deployments are still complicated.
My take is Rails is good for those who already know Rails, since the stability of it lets seasoned Rails developers carry forward all their experience. But for someone without that history, TS/Python frameworks offer a much faster/smoother onboarding process, especially with the massive familiarity advantage devs already have with Python/JS from schooling/web.
If you're going to go out of the way to learn a new language, why would you learn one that occupies the same space as one you already know?
All my peers who started their careers with Rails that know it like the back of their hands have zero desire to ever work with it again professionally. They're all exceptional engineers who had no problems picking up/migrating to Scala/Rust without productivity loss.
On the other side, I see all the upcoming engineers that missed the initial Rails popularity wave. To them, Rails is often times much more frustrating than TS/Python offerings. There's very little freely available quality onboarding materials, getting the environment set up is incredibly frustrating with how fickle bundler has become, and deployments are still complicated.
My take is Rails is good for those who already know Rails, since the stability of it lets seasoned Rails developers carry forward all their experience. But for someone without that history, TS/Python frameworks offer a much faster/smoother onboarding process, especially with the massive familiarity advantage devs already have with Python/JS from schooling/web.
If you're going to go out of the way to learn a new language, why would you learn one that occupies the same space as one you already know?
Or that the fast growing startups using it are large-scale now and hoovering up available talent. Github, shopify, airbnb, gitlab, coinbase, hulu, twitch, etc.
I wish this was true for my country. I also haven‘t seen many international remote roles for Rails.
That could be because there are less and less of them. I don't think there is enough money in the world to convince me to take on a legacy RoR system.
More so than React Native?!
React Native devs are gonna probably get paid in Equity.
Contracted Rails devs are probably working on an enterprise product that is already mature and making money.
Contracted Rails devs are probably working on an enterprise product that is already mature and making money.
As in will you find plenty of recruiters hunting for Rails developers? Absolutely. I've seen plenty of startups locally (Salt Lake/Provo) that are green-fielding with Rails. I've also seen later-stage startups that are transitioning their Rails monoliths to Elixir - and they're trying to hire folks that are willing to work on 4 year old Rails monoliths. That's not a bad thing is Rails is your thing.
I enjoyed Ruby as a language quite a bit. Having experienced some of Rails' scaling issues, I doubt I'd personally pick it for my next startup. I know time to market is vastly more important than scale, but it's also not hard to pick a different tech that DOES scale easier.
So, yes, there will be plenty of Rails projects to work on for the foreseeable future. The only concern I'd have is if you're being asked to work on a very old code base. That can get really hairy, really quickly. But that's the case with any language/stack.
I enjoyed Ruby as a language quite a bit. Having experienced some of Rails' scaling issues, I doubt I'd personally pick it for my next startup. I know time to market is vastly more important than scale, but it's also not hard to pick a different tech that DOES scale easier.
So, yes, there will be plenty of Rails projects to work on for the foreseeable future. The only concern I'd have is if you're being asked to work on a very old code base. That can get really hairy, really quickly. But that's the case with any language/stack.
> Having experienced some of Rails' scaling issues, I doubt I'd personally pick it for my next startup. I know time to market is vastly more important than scale, but it's also not hard to pick a different tech that DOES scale easier.
What part of Rails doesn't scale well? As I see it any mediocre devops can scale just about anything with some basic Kubernetes know-how, doesn't matter of it's Ruby or Java.
What part of Rails doesn't scale well? As I see it any mediocre devops can scale just about anything with some basic Kubernetes know-how, doesn't matter of it's Ruby or Java.
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 (Shopify's done it, Stripe's done it) - and I would argue that it's more of an effort than some DevOps personnel updating a pod count - it's fairly easy to start with something that is already very performant. SpringBoot is an opinionated framework for Java that has very good raw performance. I'm simply advocating that it doesn't hurt to start with something that's already pretty good. That's not premature optimization, it's just making wise decisions from the start.
My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it) - and I would argue that it's more of an effort than some DevOps personnel updating a pod count - it's fairly easy to start with something that is already very performant. SpringBoot is an opinionated framework for Java that has very good raw performance. I'm simply advocating that it doesn't hurt to start with something that's already pretty good. That's not premature optimization, it's just making wise decisions from the start.
> 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 think its ridiculous to use it as an example for the average company.
> When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win".
Why does it cease to be a win? Everyone is doing it no matter what stack they are on. So with Rails you might have a few more pods - for any startups that's going to succeed the cost is simply negligible.
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 think its ridiculous to use it as an example for the average company.
> When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win".
Why does it cease to be a win? Everyone is doing it no matter what stack they are on. So with Rails you might have a few more pods - for any startups that's going to succeed the cost is simply negligible.
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".
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".
We are not going to agree here probably. Another anecdote - because of our company's microservice/k8s architecture each dev works on their own k8s cluster. While some services are shared - most are not. That means we pay more for dev infrastructure than our production bill!
So if optimizing infra from the start is the game - why is everyone doing micro services?
10-years-plus Rails dev here, I still get requests to connect from recruiters for Rails positions at least weekly, and my LinkedIn says at the very top that I am not seeking employment
Judging by the responses here, Rails is no longer fashionable. I find it to be quite boring and predictable, which is how I like my frameworks to be
Just stay the hell away from React and it's great
Judging by the responses here, Rails is no longer fashionable. I find it to be quite boring and predictable, which is how I like my frameworks to be
Just stay the hell away from React and it's great
There is a surprisingly small amount of senior rails developers. Many who learned it when it was cool, have moved on. There are so many legit companies making tons of money on Rails stacks with 0 intention on leaving. The market is excellent for rails developers and likely will be for the foreseeable future.
At this point I think it is worthwhile to contrast Ruby against Rails. Ruby has fallen behind, if you want great meta programming, you can get all the joy, plus much better speed, by using something like Clojure. That also gives you access to the vast ecosystem of Java libraries.
But Rails is a different story. For jumpstarting a greenfield API or CRUD app, there is nothing quite as good as Rails. Django and Symfony and other frameworks have tried to imitate Rails, but Rails is still way out in front, with better tools, and the marriage of Rails tools with Ruby's advanced meta-programming is something difficult to replicate elsewhere.
If your company needs a custom CRM or CMS, Rails remains the best starting place.
But Rails is a different story. For jumpstarting a greenfield API or CRUD app, there is nothing quite as good as Rails. Django and Symfony and other frameworks have tried to imitate Rails, but Rails is still way out in front, with better tools, and the marriage of Rails tools with Ruby's advanced meta-programming is something difficult to replicate elsewhere.
If your company needs a custom CRM or CMS, Rails remains the best starting place.
Are you learning Rails from decade-old material? Because a lot has changed since then.
Not if you want to make building websites complex so that you can charge your client more.
This guy SaaS
Its a good point, there are absolutely much more simpler frameworks out there, which are good for your own side projects, your own large projects, and what fun and exciting production companies are using.
Its a good point, there are absolutely much more simpler frameworks out there, which are good for your own side projects, your own large projects, and what fun and exciting production companies are using.
I know that Ruby on Rails is still very much relevant for consultants being paid big $ to fix the disasters left by self-declared “Ninja” developers after they quit and move on to try again from scratch at another company ;)
Don't think it's a tech or language stack-related problem. You can easily find akin situation in any other stacks.
Yep I agree. However there seems to be more self-proclaimed “Ninja” programmers in the Ruby community than in others. Just my impression of course.
Super relevant! And there are tons of companies looking for Rails developers!
I know some people of the community moved to Rust or Node. But the Rails ecosystem is still the most complete out there.
The framework, as the language, is still evolving, getting quicker and integrating will all sorts of other tools (GraphQL, Elastic, etc).
Ruby is much faster in 2.7/3.x as it was in 1.9/2.0 era.
Rails is starting to try dropping node and all the JS package craziness. But still supports all them. So you can pretty much do HTML-over-the-wire, plain jQuery or go full-blown React/GraphQL/API using webpack or similar.
I know some people of the community moved to Rust or Node. But the Rails ecosystem is still the most complete out there.
The framework, as the language, is still evolving, getting quicker and integrating will all sorts of other tools (GraphQL, Elastic, etc).
Ruby is much faster in 2.7/3.x as it was in 1.9/2.0 era.
Rails is starting to try dropping node and all the JS package craziness. But still supports all them. So you can pretty much do HTML-over-the-wire, plain jQuery or go full-blown React/GraphQL/API using webpack or similar.
if you like screencasts, "Go Rails" is an amazing resource (and they are very current): https://gorails.com/
We build and maintain a lot of Rails applications, with several of them almost a decade old. We have to keep them up to date, but Rails is stable and mature and this process is fairly easy. We come across a lot of web apps written in other ecosystems, using frameworks that were popular just a few years ago and have now been mostly abandoned. Or we get bit by an app that is a few years old and now has dependencies that are completely dead and core to the application. This isn’t the case with Rails. It is just as actively developed now as it was 10 years ago, and we are confident that it’ll be just as actively developed 10 years from now. Due to the fragmentation of these other ecosystems, even though the community as a whole may be larger, finding a stack that you can depend on for a long time can be a huge challenge.
> We come across a lot of web apps written in other ecosystems, using frameworks that were popular just a few years ago and have now been mostly abandoned
Interesting, can you give a few names? Just so that I'll know to reconsider if I need to use one of them.
Interesting, can you give a few names? Just so that I'll know to reconsider if I need to use one of them.
After years spent with Ruby and Rails, and some work with Go, Elixir, and Phoenix I switched finally to Python and Django. It's fast, productive, very mature and you can find a library for whatever I imagine. I like Jupiter notebooks, Pydantic, multiprocessing, pandas, and other libs.
I tried to get used to Go several times but it always failed. Go lacks an interactive console. Its syntax is ugly and very limited and not expressive, which means I had to reinvent the wheel all over the time. Why the heck Go has not even have reduce function? It is true, that using Go ends with a TONS of verbose code. The same functionality in another language can be built in a fraction of the time and will have a much simpler and smaller code size
I tried to get used to Go several times but it always failed. Go lacks an interactive console. Its syntax is ugly and very limited and not expressive, which means I had to reinvent the wheel all over the time. Why the heck Go has not even have reduce function? It is true, that using Go ends with a TONS of verbose code. The same functionality in another language can be built in a fraction of the time and will have a much simpler and smaller code size
Here is a hint, at least every 6 months for the past 8 years there have been blog articles asking whether Rails is still relevant. It’s basically a meme at this point. We need a “no rails relevancy posts” sign like guitar shops need “no stairway”.
Still relevant. We're deploying a lot of customer apps that are written on Rails
I learned rails in college and mentioned it on a few resumes and get non stop recruiters asks about it (more than my typescript/go/react/c# stuff, and on par with my java springboot slice) so i would say no.
It's not only not dead, I'm excited about the new stuff in Rails 7.
Don't think so it is dead rather a mature and proven technology. The impact of Rails is huge and almost every other web framework has embraced parts of it.
But having worked with Rails code base, it becomes a guess work in a text editor to know what you're getting in a method. The duck typing makes impossible to be sure for text editors unless you resort to some sort of type hinting and that's not Rails's fault, that's ruby.
In 2022, given among all the choices, I'd probably go to either deno + Typescript or golang.
But having worked with Rails code base, it becomes a guess work in a text editor to know what you're getting in a method. The duck typing makes impossible to be sure for text editors unless you resort to some sort of type hinting and that's not Rails's fault, that's ruby.
In 2022, given among all the choices, I'd probably go to either deno + Typescript or golang.
Recent similar discussion:
3 months ago https://news.ycombinator.com/item?id=30022185
3 months ago https://news.ycombinator.com/item?id=30022185
Its very not dead (www.israilsdead.com). Jokes aside, it's the just perception created by everyone trying to be fancy and move to whatever is in fashion now..
I hardly get any job listings from recruiters using Rails tech stack these days. Nothing compared to 7 years ago.
These days it's mostly Javascript, Go, some Kotlin.
Regardless I work in Elixir because they can pry BEAM out of my cold dead hands. And Liveview is inspiring all other frameworks to build similar tooling that is unfortunately second-best because Elixir and Erlang's BEAM are so well suited to it's workflow.
These days it's mostly Javascript, Go, some Kotlin.
Regardless I work in Elixir because they can pry BEAM out of my cold dead hands. And Liveview is inspiring all other frameworks to build similar tooling that is unfortunately second-best because Elixir and Erlang's BEAM are so well suited to it's workflow.
Yes. It’s not the super cool framework it once was but it’s still excellent, and still in active development. Rails 7 is a fantastic release too.
To put this in perspective here are some job stats from Indeed.co.uk for London and the UK (excluding London):
London: Rails 237, Django 383, Laravel 149
UK (excl. London): Rails 230, Django 406, Laravel 1001
So, yes, there are less Rails jobs overall but considering there are less than twice as many jobs as with Django, which is powered one of the most popular languages, Rails is clearly still very active in the marketplace.
London: Rails 237, Django 383, Laravel 149
UK (excl. London): Rails 230, Django 406, Laravel 1001
So, yes, there are less Rails jobs overall but considering there are less than twice as many jobs as with Django, which is powered one of the most popular languages, Rails is clearly still very active in the marketplace.
If you're just starting out, I wouldn't go with Rails. Get really good at Typescript and React instead if you like the front-end, or Node or Golang on the back-end.
Although it's a hard choice because the books and documentation and training resources are great in Rails, so easier to level up, but I don't think that's where things are going anymore.
Although it's a hard choice because the books and documentation and training resources are great in Rails, so easier to level up, but I don't think that's where things are going anymore.
Rails is still relevant.
It's tricky more generally to see if a technology is still relevant because there is so much hype of new stuff in web development.
Usually after the plateau of productivity, you don't see too many people talking about a given technology, your only signal of success would be something like Who's Hiring and Cmd + F "rails".
It's tricky more generally to see if a technology is still relevant because there is so much hype of new stuff in web development.
Usually after the plateau of productivity, you don't see too many people talking about a given technology, your only signal of success would be something like Who's Hiring and Cmd + F "rails".
I think Ruby on Rails was the killer app that kept Ruby relevant. This kept Ruby relevant for a while but has fallen off in a lot of developer surveys. I think enough competitors in major programming languages have emerged to the point where I would consider it dying.
I share that opinion. The competition is strong, the killer app is gone.
It is for dark matter developers now, SV dark matter but dark matter.
Look for the job market in your region and field and then address e it for yourself
It is for dark matter developers now, SV dark matter but dark matter.
Look for the job market in your region and field and then address e it for yourself
I went through an interview cycle recently for remote roles. Most were (surprisingly) using Rails on the backend. Either this is because I have RoR experience in my LinkedIn (albeit little) or because it remains a popular framework. Take that as you will.
Checkout the guides: https://guides.rubyonrails.org
Even just a "Ruby on Rails Tutorial" search on YouTube will get you going, too, if that's more your thing.
Even just a "Ruby on Rails Tutorial" search on YouTube will get you going, too, if that's more your thing.
My company uses it for multiple web apps and uses ActiveRecord for scripts too.
I think it's quite popular, also speaking of testing it really has all options available. Since unit testing is now absolutely the standard, adoption of TDD has also been growing from what I've seen
It is good for getting off the ground when validating an idea, but when it comes to 10+ team it gets difficult to hire or train people as there is a several fold larger pool of accessible Java developers.
RoR is the Supreme t-shirts and Air Jordans of programming. They very much matter and are the center of the universe to the people who care, everyone else just kinda shrugs and goes about their day.
Maybe it would be the answer :) https://news.ycombinator.com/item?id=21138422
Nope. Not dead.
I'm building Avo to help developers ship apps faster than ever. Avo is to Rails what Rails is to web development.
https://avohq.io
I'm building Avo to help developers ship apps faster than ever. Avo is to Rails what Rails is to web development.
https://avohq.io
Shopify is hiring like crazy, and their stack is almost all Rails.
My company uses it still, there were some new projects recently started using it. It does the job of creating CRUD apps pretty well.
For more performance intensive tasks .NET Core is used.
For more performance intensive tasks .NET Core is used.
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
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.
[deleted]
Thats great!
No, I just accepted a Rails job offer a while ago.
A bit off-topic: But I have been always getting questions on how to start with RoR after a fair bit of Ruby knowledge.
DHH's blog video feels pretty dated now. Does anyone have any pointers to a decent video tutorial that starts from the basics?
DHH's blog video feels pretty dated now. Does anyone have any pointers to a decent video tutorial that starts from the basics?
My take:
- 34yo dev, brasilian(living in Brazil), started with RoR in 2013 and worked with it on and off since them
- was the first Software hire in a b2b e-bike engineer-DNA startup in 2019, picked Rails for the 'IoT layer', been working on it since them
In this context, I'm still very happy to be developing in Ruby and Rails and it still feels very fresh to me most of the time.
It may come down to, like Vim, it's not exactly in the new stuff department, it's 'niche', even, but the super users and hardcore community apparently will never let it down. It is very well taken care of software and I think there's a lot of people in a virtuous relationship with it i.e.: probably a lot of people running it to get things done, doing good business, making money and satisfied enough that it sort of doesn't matter much what 'kids' looking for the hot new tech to fill CVs think about it. I think RoR is super solid in this regard.
Following on the Vim analogy, I think both Ruby and Rails have the 'power tool' quality/deph in that it keeps rewarding you with more power the more you get the handle of it, there's few things like TDD on RoR. When you're senior and you're not afraid to tweak things as you want it anymore, things get really interesting. For example:
- Microservices x monoliths: I've built a Service Object layer, all Services have an API of .new(:param, :param)(sugarized to initialize_with :param, :param) and .call, .call!, .queue. These service objects can be strung together, allowing for composition. call without '!' gives you an object you can say .success?, .result and react however you want. .call! will raise exceptions. .queue runs it async in Sidekiq. We have over 40 of them, in some cases we refactored out a piece of functionality(e.g.: google sheets integration) and just deleted a whole folder of them, just like that.
All of these 'actions' can be run from any context: MQTT message, API call, console, Sidekiq, Sidekiq-scheduled, tests. In ruby *anything* can be mocked anytime, have you thought about the power of this? I can make an expectation that an --instance of a class somewhere will receive a call--, it could be mine, it could be a class in a lib, it could be something in the framework.
- Sidekiq just works and is awesome. Free fault-tolerance, performant, scalable.
- Building custom piece of architecture, ruby scripting is very powerful: we had bots simulating the motorcycles running and talking with the backend way before we actually had a board and software able to do that. MQTT messages are relayed to Rails app through a custom long running service, it's a ruby script. Later on we've twisted it to test Firmware Updates Over the Air feature, basically, scripting the script itself. So we have a CI/CD job that allow us to stress test/spec test firmware. Right now I'm doing a middleware so I'll script Rack/Rails next, TDD is going smoothly.
- Maybe tweaking it further to make it more of an a Event Driven application.
I think ultimately Ruby developers end up being good developers because of the high power+low cognitive overhead style at the heart of the language.
Now for the cons:
- It is indeed becoming niche. Junior developers probably mostly not learning it. Are they really as productive as they could be on Rails though? I think NodeJs stuff are interesting, I wonder though how productive they actually are. Is the stuff they build really bug-free? Fully featured? Well tested? From my experience they are fast but will overlook obvious bugs in their code as if it was ok. I think the Ruby community had tons of good teachers who focused on elegant working code, RailsCasts, DestroyAllSoftware, etc. Also a lot of influential devs and ppl who learned from them & similar sources, a lot of them still participating or who done amazing contributions, like Aaron Patterson, Jose Valim, DHH.. I don't know how exactly we'll deal with this at the company, but our software is so flexible I think we wouldn't have much trouble breaking it up & integrating, at the same time too, though, our application code is so easy to work on I don't think it matters much if a new dev is not a rubyist.
In conclusion, I guess it depends where you want to go with your life, I myself have always thought of handling actual heavy duty shit with software, being in a core product team, not being a 'job market b*tch' etc. Even if I'm not writing Ruby one day because we have decided to switch to something other or that I want to work on a different project that is running X, I don't really care.
In this context, I'm still very happy to be developing in Ruby and Rails and it still feels very fresh to me most of the time.
It may come down to, like Vim, it's not exactly in the new stuff department, it's 'niche', even, but the super users and hardcore community apparently will never let it down. It is very well taken care of software and I think there's a lot of people in a virtuous relationship with it i.e.: probably a lot of people running it to get things done, doing good business, making money and satisfied enough that it sort of doesn't matter much what 'kids' looking for the hot new tech to fill CVs think about it. I think RoR is super solid in this regard.
Following on the Vim analogy, I think both Ruby and Rails have the 'power tool' quality/deph in that it keeps rewarding you with more power the more you get the handle of it, there's few things like TDD on RoR. When you're senior and you're not afraid to tweak things as you want it anymore, things get really interesting. For example:
- Microservices x monoliths: I've built a Service Object layer, all Services have an API of .new(:param, :param)(sugarized to initialize_with :param, :param) and .call, .call!, .queue. These service objects can be strung together, allowing for composition. call without '!' gives you an object you can say .success?, .result and react however you want. .call! will raise exceptions. .queue runs it async in Sidekiq. We have over 40 of them, in some cases we refactored out a piece of functionality(e.g.: google sheets integration) and just deleted a whole folder of them, just like that.
All of these 'actions' can be run from any context: MQTT message, API call, console, Sidekiq, Sidekiq-scheduled, tests. In ruby *anything* can be mocked anytime, have you thought about the power of this? I can make an expectation that an --instance of a class somewhere will receive a call--, it could be mine, it could be a class in a lib, it could be something in the framework.
- Sidekiq just works and is awesome. Free fault-tolerance, performant, scalable.
- Building custom piece of architecture, ruby scripting is very powerful: we had bots simulating the motorcycles running and talking with the backend way before we actually had a board and software able to do that. MQTT messages are relayed to Rails app through a custom long running service, it's a ruby script. Later on we've twisted it to test Firmware Updates Over the Air feature, basically, scripting the script itself. So we have a CI/CD job that allow us to stress test/spec test firmware. Right now I'm doing a middleware so I'll script Rack/Rails next, TDD is going smoothly.
- Maybe tweaking it further to make it more of an a Event Driven application.
I think ultimately Ruby developers end up being good developers because of the high power+low cognitive overhead style at the heart of the language.
Now for the cons:
- It is indeed becoming niche. Junior developers probably mostly not learning it. Are they really as productive as they could be on Rails though? I think NodeJs stuff are interesting, I wonder though how productive they actually are. Is the stuff they build really bug-free? Fully featured? Well tested? From my experience they are fast but will overlook obvious bugs in their code as if it was ok. I think the Ruby community had tons of good teachers who focused on elegant working code, RailsCasts, DestroyAllSoftware, etc. Also a lot of influential devs and ppl who learned from them & similar sources, a lot of them still participating or who done amazing contributions, like Aaron Patterson, Jose Valim, DHH.. I don't know how exactly we'll deal with this at the company, but our software is so flexible I think we wouldn't have much trouble breaking it up & integrating, at the same time too, though, our application code is so easy to work on I don't think it matters much if a new dev is not a rubyist.
In conclusion, I guess it depends where you want to go with your life, I myself have always thought of handling actual heavy duty shit with software, being in a core product team, not being a 'job market b*tch' etc. Even if I'm not writing Ruby one day because we have decided to switch to something other or that I want to work on a different project that is running X, I don't really care.
Yes! Ruby on Rails remains relevant, so long as you use it for projects where it makes sense.
Rails was originally released in 2004. Since then, it has been used to build a wide range of different websites and applications. Some of the most well-known sites built using Rails are Github and Airbnb, which is why many people think of Rails when they think of web development. While it has lost some popularity in recent years, as other frameworks and languages have become more mainstream, Rails is still very much alive and kicking.
In fact, in 2018, Rails was the 7th most commonly used framework among all developers according to Stack Overflow's annual developer survey. This survey included over 100,000 responses from software developers representing over 150 countries. It showed that about 30 percent of those surveyed had used Rails "in their careers" or "currently use."
The main question you should ask yourself when considering whether or not to use Rails is whether or not you can use another tool that would be better suited for your project. If you're looking to build a website with a lot of dynamic functionality that needs to be delivered at lightning speed, then Rails could definitely be your best option.
Rails was originally released in 2004. Since then, it has been used to build a wide range of different websites and applications. Some of the most well-known sites built using Rails are Github and Airbnb, which is why many people think of Rails when they think of web development. While it has lost some popularity in recent years, as other frameworks and languages have become more mainstream, Rails is still very much alive and kicking.
In fact, in 2018, Rails was the 7th most commonly used framework among all developers according to Stack Overflow's annual developer survey. This survey included over 100,000 responses from software developers representing over 150 countries. It showed that about 30 percent of those surveyed had used Rails "in their careers" or "currently use."
The main question you should ask yourself when considering whether or not to use Rails is whether or not you can use another tool that would be better suited for your project. If you're looking to build a website with a lot of dynamic functionality that needs to be delivered at lightning speed, then Rails could definitely be your best option.
Since the screencasts are over 10 years old now, I'm wondering if Ruby on Rails is still going strong. What resources would you recommend to get into Ruby/Rails specifically? Same question for TDD? Thanks!
[0] https://www.destroyallsoftware.com/screencasts/catalog