There are many tradeoffs. The good news is that hardly any projects and startups will hit those. Or, when they do, they have the resources and funds to transition.
Anyway:
Ruby is slow. Terribly so. Rails even more. The optimisation is on speed of development and that comes (a.o.) at the cost of runtime speed. Memory usage is terrible too. Easily solvable by bigger or more VMS though.
Ruby, with its runtime, is complex and hard to build and deploy and host. Heroku et al take that away from you, but "getting it running on your laptop" alone is a sysyphian task. I've worked at and managed teams where this remained a timesink: where devs spend significant time "Debugging their environments".
Rails is simple MVC with loads and loads of magic. Opinionated patterns such as their own take on ActiveRecord, MVC make this worse. If you dislike these patterns or architectural choices: you'll have a bad time. If you want, or need to implement other patterns (such as, but not limited to, hexagonal architecture, event-sourcing, adapters, dependency injection etc) you'll have a hard time and Rails will work against you. Very hard.
Related to this: It is hard (but not impossible!) to keep an ever growing Rails app clean, agile, and stable. Rails works against you in this: it's often easier and quicker to Do The Bad Thing that it is to Implement The Proper Abstraction Or Pattern. It optimizes for speed of development - perfect for MVPs or PoCs, at the cost of maintainability.
Ruby is weakly typed. If you want, or need the protection or guidance of a compiler in typing, this, Ruby won't help you. Additional tools like (complex) linters, static code analysis help and are required to keep a long running project workable. Extensive testing of everything is The Solution Of Ruby to all this: need to ensure your method works when it gets a null (nil) passed: write tests: no compiler will help you.
Ruby is dynamic to the extreme. Many people will feel very uncomfortable with this (only part rightly so, IMO). But a practical downside is that no IDE or vim-setup can help you like you may be used from Java, .Net, Rust or C(++). Refactoring is basically "rerunning the tests over and over. And over. And again".
Edit: and some smaller, but, depending on case, important too:
Rails' fetish with ActiveRecord makes nearly all Rails apps extremely tightly coupled to the database and the data-model. To inverse this: you're data-model is bounded by what Rails needs and wants (in practice: in theory this can be worked around). If you consider that all long-lived projects carry "data" along the journey, but that codebase is iterated constantly, having such tight coupling and rigid requirements on your data-model is a big risk.
Rails' is ever-growing. It's "batteries included" idea is great for starting. But that makes it ever growing in size and complexity.
Rails' architectural style or modules and includes make the common way of writing things hard to test, hard to maintain and hard to debug. For example ActiveRecord::Base is a terrible violator of the Single Responsibility Principle: your models connect to the database, manage storage, manage state-machines, can render themselves, can serialize themselves, manage their validations, manage and coordinate listeners and callbacks, manage identification, have a giant API for fetching and querying in the database, manage their dependencies on other models, manage other models, and so on, and so on. And that when "testing" is the most important tool to keep a Rails app solid and stable.
I think Rails is great, work in it full-time, and would by default choose it for any web app I built, without some compelling reason to choose something else. But the points in that post are at least mostly true.
Ruby certainly isn't the fastest language around. I've found it fast enough for most purposes though. I don't think there's a real noticeable difference from other interpreted languages for most applications.
Our teams don't find it complex at all to build or host or set up dev environments for. No more so than other languages at least. I do recommend using CLI debuggers like byebug instead of VS Code or Rubymine, their GUI debuggers always seem to be a PITA to set up and keep running. CLI is definitely the preferred environment in Rails land.
I'd describe Rails as highly opinionated. It's baked-in opinions about most things are mostly high-quality, though not perfect for everything. If you go along with it, you can get a lot of stuff done fast. If you're determined to do things some other way, you may have a rough time. IMO, if you just want to get a webapp going and don't want to think too much about architecture, it's better to just do things the Rails way. There's decent options to refactor later if needed.
Ruby is an extremely dynamic and flexible language. This is both good and bad. Good in that you can do whatever crazy thing you end up needing to do in it. Bad in that if you end up with a codebase with 20 crazy things done, it can get awful hard to figure out what the heck your code is doing, where functions are defined, etc. There's a ton of Gems around that add various helpful features to Rails. My impression is the ecosystem has gotten much better in the last 5-10 years as far as popular mainstream Gems not doing crazy things with Ruby that make apps a huge pain to debug, but YMMV.
I do think ActiveRecord is the best ORM out there. It is also highly opinionated though - it's gonna be messy if you don't name your tables and columns in the patterns that it likes. It does mostly give you clear and efficient SQL for most situations, and make it straightforward to drop down to raw SQL when it's needed.
The lack of type-checking does mean that you'll want to write a lot of specs and run them often, since it's the only way to ensure your app keeps working. I used to kind of poo-poo thorough testing, but I've been bitten by really simple bugs making it through code review and initial deployment too many times.
> Ruby, with its runtime, is complex and hard to build and deploy and host. Heroku et al take that away from you, but "getting it running on your laptop" alone is a sysyphian task.
Is it? And compared to what? I don't think it's hard at all:
- You can install Ruby from a system manager (super convenient) or with tools like ruby-install+chruby and ruby-build+rbenv. So that's one command or a handful of well documented commands you copy&paste.
(You can use CentOS/RHEL modular packages or Fullstaq Ruby packages for your server to skip the long compilation step.)
- Once you have Ruby, you should install -devel packages for libraries you use (this is same for all dynamic languages that need the C header file for compiling the extension).
(This depends on the application.)
- You make Bundler to install your gems by running "bundle install". If you installed your header files, this step shouldn't stop you.
- You run the Puma app server by "bin/rails s" (in development) or "bundle exec --keep-file-descriptors puma -C config/puma.rb" (in production) while making sure the RAILS_ENV is set properly.
(Puma has a lot of different configurations, but you can do defaults.)
Now you are up and running, and should wrap the above as a systemd service or within a Docker container on production servers. I don't see how this is so much more difficult than other stacks? Python is slightly less convenient I think.
In the Rails demo I made for Deployment from Scratch the Ruby bits are not very long, nor hard.
>ruby, with its runtime, is complex and hard to build and deploy and host. Heroku et al take that away from you, but "getting it running on your laptop" alone is a sysyphian task. I've worked at and managed teams where this remained a timesink: where devs spend significant time "Debugging their environments".
I've solved that problem with docker compose. it took a while to get it right, but since then everybody can clone the repository, run one command and start developing.
but, yeah these are all valid points. As always, YMMV.
Yup. Docker helps with this. As can e.g. cloud9 or codespaces. If I read it correct, this is the main reason Github moved there[0]
But I consider that a workaround. When the tooling gets so complex that you need more (complex) tooling to help manage that, the problem lies deeper.
Compare it to e.g. Go or Rust. Where you (or a CI) builds something and deployment literally can be a `scp target/release/foobar foobar.com:/usr/bin && ssh foobar.com systemctl restart foobar`.
I say this as someone who has been hosting Rails apps for decades: it sucks and it is hard. I have a full-blown Rails hosting (ansible, Digital Ocean, Linode and some more) but still often grab a Heroku or do the docker-dance, because some edgecase is causing havoc.
That Ruby performance is horrible. Also - it's constantly changing. What was true last year might not be true next year.
Source - https://speed.yjit.org/
Compared to Both nodejs and python: lasst time I looked Ruby performed notably worse.
Note that I've been a Ruby developer for over 12 years now. Worked in Ruby-shops almost exclusively. Yet the performance is often so bad that I have to do work in python. E.g. quite recently a scraper, wrote it in Ruby -obviously-, found out that we couldn't get performance acceptable, rewrote it in python. Our ETL using Kiba-ETL had to be ported over to a rust-based ETL set because the nightly process took longer than 24 hours, causing it to hit it's own mutex locks. The Rust-based system ran this same data-conversion in under two hours on the same server.
This is not hate on Ruby. It's a known fact it's one of the slower languages and runtimes out there. It's getting better and getting there fast.
Yet the tradeoff of being extemely developer-friendly is that performance suffers. I'd gladly take that tradeoff every day (untill it becomes inpractical and we port that ruby tooling to something else).
> E.g. quite recently a scraper, wrote it in Ruby -obviously-, found out that we couldn't get performance acceptable, rewrote it in python
How is Python gonna improve performance when writing a scraper, it's mostly about doing a bunch of network requests right? You could do threading in Ruby you know. Both Python and Ruby have a VM lock (GIL, have no idea what it's called in Python).
Python is good choice for scraping due to the many ready made libraries but I don't get how performance was a win over Ruby.
Node is a different story, V8 (and competing JS engines) had huge effort poured into them by Google/Microsoft so it's fast.
Python never had that kind of investment afaik.
We will see if Shopify can narrow the gap between Ruby and JS, I know it's a reach but they already improved Ruby performance around 25-30% since the project started (about a year?). I am optimstic the performance gap will narrow since what makes JS faster is a JIT. There is no magic here, only effort and investment which costs money.
There's hardly any resources for Crystal: tutorials, courses, books etc.
And learning something new is an investment too. Learning Crystal (or even sorbet) may help to solve the immediate problem. But I then have a skill that is hardly relevant anywhere else. Contrary to Rust, which has a bright future and is in high demand.
Anyway:
Ruby is slow. Terribly so. Rails even more. The optimisation is on speed of development and that comes (a.o.) at the cost of runtime speed. Memory usage is terrible too. Easily solvable by bigger or more VMS though.
Ruby, with its runtime, is complex and hard to build and deploy and host. Heroku et al take that away from you, but "getting it running on your laptop" alone is a sysyphian task. I've worked at and managed teams where this remained a timesink: where devs spend significant time "Debugging their environments".
Rails is simple MVC with loads and loads of magic. Opinionated patterns such as their own take on ActiveRecord, MVC make this worse. If you dislike these patterns or architectural choices: you'll have a bad time. If you want, or need to implement other patterns (such as, but not limited to, hexagonal architecture, event-sourcing, adapters, dependency injection etc) you'll have a hard time and Rails will work against you. Very hard.
Related to this: It is hard (but not impossible!) to keep an ever growing Rails app clean, agile, and stable. Rails works against you in this: it's often easier and quicker to Do The Bad Thing that it is to Implement The Proper Abstraction Or Pattern. It optimizes for speed of development - perfect for MVPs or PoCs, at the cost of maintainability.
Ruby is weakly typed. If you want, or need the protection or guidance of a compiler in typing, this, Ruby won't help you. Additional tools like (complex) linters, static code analysis help and are required to keep a long running project workable. Extensive testing of everything is The Solution Of Ruby to all this: need to ensure your method works when it gets a null (nil) passed: write tests: no compiler will help you.
Ruby is dynamic to the extreme. Many people will feel very uncomfortable with this (only part rightly so, IMO). But a practical downside is that no IDE or vim-setup can help you like you may be used from Java, .Net, Rust or C(++). Refactoring is basically "rerunning the tests over and over. And over. And again".
Edit: and some smaller, but, depending on case, important too:
Rails' fetish with ActiveRecord makes nearly all Rails apps extremely tightly coupled to the database and the data-model. To inverse this: you're data-model is bounded by what Rails needs and wants (in practice: in theory this can be worked around). If you consider that all long-lived projects carry "data" along the journey, but that codebase is iterated constantly, having such tight coupling and rigid requirements on your data-model is a big risk.
Rails' is ever-growing. It's "batteries included" idea is great for starting. But that makes it ever growing in size and complexity.
Rails' architectural style or modules and includes make the common way of writing things hard to test, hard to maintain and hard to debug. For example ActiveRecord::Base is a terrible violator of the Single Responsibility Principle: your models connect to the database, manage storage, manage state-machines, can render themselves, can serialize themselves, manage their validations, manage and coordinate listeners and callbacks, manage identification, have a giant API for fetching and querying in the database, manage their dependencies on other models, manage other models, and so on, and so on. And that when "testing" is the most important tool to keep a Rails app solid and stable.