Rails 7 Released
rubyonrails.org
rubyonrails.org
Trying out rails, I understand how much magic is involved here. Because I've had to build all this crap myself - many, many times over. Complicated things become simple, and tasks that usually make me sigh (add a new data point and add it right through Knex, Hapi models, routes, redux actions, redux store, dispatch/selector and template) turns into a SINGLE COMMAND. Sold :)
Very excited about this new release!
Edit: I wrote a blog about this a while ago btw, but there are many others pieces out there like it: https://nikodunk.com/a-node-js-developer-discovers-rails/ - using it to create https://electrade.app currently.
JavaScript (even with TypeScript) and frontend frameworks are…quite a journey by comparison.
I see so much focus on this on web frameworks generally and it strikes me as almost always the wrong thing to optimise for.
I don’t know rails, the last time i tried it was circa 2007 and yet I’d confidently adopt it given the right situation.
If i had a choice between shipping features 2% sooner or saving $10k / year on server costs, I’d almost always choose sooner. Let’s be honest, a rails dev team is moving more than 2% faster than a java/c# web dev team.
If i have 5 devs and they’re all 2% more productive, that could be around $10k of free developer output but it’s more than that, developer productivity compounds. 75% off my server costs doesn’t.
I would argue that the performance hit isn't from ruby or the framework, but from people abusing the database with lazy loading in active record. Force people to fetch all the data they need in one query (similar to Ecto), and your performance will improve. There's some config value that disables lazy loading too
That said, it is also quite slow when you actually do need requests per second or rows per second, but the usual thing is to throw more machines at it,reduce the amount of magic in the hot path (like activerecord-import for bulk data if that's still maintained,) or use something else for the hot path.
As someone who created their app in Next.js this year, I can tell you the Node.js ecosystem is in absolute shambles. We are making a WYSIWYG / ecommerce platform for authors, so we need the ability to make and preview live changes.
After finishing our MVP with a no-code solution, we decided to move to a custom Next.js app in as little time as possible. Big mistake. I had the urge to dig into Rails but I was much more comfortable in React. That being said, it's been a nightmare dealing with package upgrades, ESM vs CJS, running tests, adding Typescript, etc.
I believe, for example, creating the preview component would have been significantly faster in Rails than Next.js.
Recently we migrated to Next.js v12 for speed improvements. So many roadblocks. It took forever to debug. Again, mostly due to dependency resolution issues.
Blitz.js is supposedly going to be the Rails of JS but there is no way they'll ever have the support that either Next or Rails will receive.
Who would have thought that the “Data Visualization Toolkit” would be about Rails?
Turns out, it’s pretty sweet actually! rails new, g migration, baddaboom. I’ve done this a few times, but usually use chartkick rather than d3 as the book suggests.
RVM, gems, bundler. Then onto rails. Upon first attempt to launch rails it choked on yarn requiring to install packages.
And then I had to go through node, npm/yarn, webpacker, rails is primarily the backend, webpacker manages the front end. And it all seemed needlessly complicated.
I love that rails have doubled down on the low-js direction. Progressive enhancement, the whole js ecosystem is there if/when you need. But until then KISS.
We will see...
No. I'm going to get downvoted for this, but Ruby isn't popular itself (with or without Rails). It's barely more popular than Fortran, according to TIOBE[1]. It cracks the top 10 according to Redmonk, but has been generally declining since 2012[2].
Somewhat shockingly, it's even less widely used than Rust according to Stack Overflow[3].
They also found Ruby has a 53% loved vs. 47% dreaded score, compared to Python's 68% and 32%. It's especially surprising that Stack Overflow's respondents like Ruby less than JavaScript and SQL, the two most frustrating languages I have ever been forced to work with myself.
> Python and Ruby occupy the same space and use cases
This is absolutely untrue. I personally loathe Python, but it is perhaps the most useful language you can learn right now, and it barely overlaps with Ruby.
It's huge in statistics/data science and machine learning. It's not the most common web backend, but it still has a fairly large ecosystem for the web. It's rapidly rising in popularity, too.
1. https://www.tiobe.com/tiobe-index/
2. https://redmonk.com/kfitzpatrick/2021/03/02/redmonk-top-20-l...
3. https://insights.stackoverflow.com/survey/2021#most-popular-...
Isn't the Stack Overflow one done by a survey, not just by analyzing the questions?
I really don't think Bash and Powershell are more popular for actual development than C++ and Go respectively. People just use them because they're there... Making the rankings a lot less meaningful.
I'd be willing to bet money that Bash is way, way more popular in development than Go.
> in development
This can be taken a few ways. I don't use Go, but I interact with Bash. So you're right in a sense.
I'd also never write a web-app in bash, nor a non-trivial program, nor anything that isn't a shell script. So is it really meaningful when people are looking for a language to write a GUI app, web app, mobile app or game in?
If you mean popular as in "many people like using it", I would question your (and their) sanity.
According to Stack Overflow's survey[1], people enjoy Bash/Shell more than they enjoy Ruby.
I personally hate both Ruby and Bash, so I assume my sanity is beyond question.
1. https://insights.stackoverflow.com/survey/2021#most-loved-dr...
My own personal experience as a CTO and startup investor: I haven't seen Ruby (or even met someone whose primary language is Ruby) in a long time.
I think it had a moment ~10 years ago when a lot of people started companies using Rails. Some of them still use it, most of them just went out of business.
It hasn't been big since then. It seemed to only ever have become popular in a fairly limited bubble of startups, especially in Silicon Valley.
But some pretty successful startups used it and some successful companies today use it. It's been a tool used to spawn quite a few billion+ dollar companies.
The fact it's used internally at Google and MS alone means it's got traction. I'm willing to bet lots of enterprise shops are using it for things, even if it's not #1.
Ruby is a fine language that some people have ridden to great success. It is still a fairly niche language.
We're on a popular website written in Arc -- likely the only website written in Arc. Popularity isn't everything and I'm not suggesting it is.
Ruby developers is small in % but rather large as an absolute number.
Smt88 is correct in that it is increasingly a niche. Churn rate is greater than retention rate. Junior Developers cant find jobs with Ruby and Rails, and they switch to others that do find them jobs. Companies only want to hire experience Ruby Rails developers but some of them moved on. It is a vicious cycle.
The point is even if Reddit was written in Arc, it has no bearing on Arc's industry status. It needs to be in a self sustainable ecosystem.
It’s not going to vanish anytime soon and the Ruby team continue to push improvements.
Unlike Python the ecosystem hasn’t become so large that it’s become impossible to keep track of.
It’s likely to remain my go to language for small projects in large part because writing Ruby is just fun!
https://www.quora.com/When-do-I-use-FORTRAN-over-Python-and-...
Ruby and Python share a lot of commonalities as languages. But their constituencies vary substantially, and that matters. Academic, probably Python. Working "interactive" agency, probably Ruby. Process automation, probably Ruby again. Author's implementation of new algo paper, probably Python.
I wouldn't think either-or. If it's worth familiarizing with one, it's probably one more weekend to be walk-on-ready for both.
Other than "I already know Ruby". In fact, I'll often go for the -for me- more unfamiliar Python for such tools. Knowing it will cost me more effort, but also knowing that the libraries, documentation, education and off-the-shelve solutions are far, far better and move available.
I'm not saying those use cases don't exist at all, but I don't think it's as common as you're making it up to be. As a Ruby dev the last 8 years I didn't have many times when some key functionality was only available in Python/Node. I can see it happening in web crawling or data science but those aren't common to every day web development.
A scraper using Scrapy. Had a tool in Ruby with Hydra (multitreaded) and message cueus and whatnot to speed it up. Spidy is just faster. Not because of the language, but because the tooling is much further along and has far more effort poored into.
Server/infra management: ported from chef to ansible. Not for speed, but because stability and availability (of a.o. resources). Unexpected side-effect was that ansible was actually faster and used far less resources on the servers (chef-deamon was notoriously bad). Not sure why, but I don't think its the language design.
FluentD, moved to flowgger and plain-old-syslog. FluentD is an awesome piece of software, but it was hogging our (micro)servers enough to be noticable, measurable and show up in the billing (as higher CPU/memory vpses).
You might also want to ask the Japanese community as I have heard it is big there.
Homebrew and YAST (Suse Linux) are written in Ruby. Stripe uses Ruby but not Rails.
Basically anything you'd use Perl for, + a bunch more uses, and of course Rails and web stuff.
Check how many top YC companies use Ruby.
And fair enough, tools come and go. Ruby is still the best write-once language I've used though, and Rails is still a top web framework.
The Sequel gem (rather than ActiveRecord) and the Parallel gem play really well together. Anytime I need to do some scripting against a database it’s very convenient.
Exactly the uses cases that I want to "steal" from Python, Ruby, Perl, etc.
Not because Next Generation Shell is "better" but because it's focused on the use cases - https://github.com/ngs-lang/ngs/wiki/Use-Cases ... while still being a "real" programming language.
As long as Shopify keeps using it, Ruby will have a place in the world!
https://developer.squareup.com/blog/the-state-of-ruby-3-typi...
And when I saw ruby isn't included in the list of supported language for the next gen JetBrains editor, perhaps due to low sales of RubyMine, I felt its best days may be over.
https://www.jetbrains.com/fleet/
(Scroll down to the list of programming language icons)
"Ruby/Rails will be supported in Fleet. No timeframe, though."
Hardly. And that bothers me as a Ruby (not rails) developer.
There was Chef, still is around, but Chef "lost" from Ansible and Terraform.
There are some commandline tools, but I slowly see them replaced by Go, Rust, node or Python versions. `github`, `heroku` etc.
And there are numerous small or tiny platforms, systems and toolkits that failed to get traction and live a (happy!) live with a tiny audience. Think about sinatra, sequent, gosu, (the ruby version of) cucumber, kiba-etl, etc.
But I'm pretty sure most of these tools, frameworks and platforms are there because or Rails. To cater people, shops and teams "that already know Ruby inside out" (because of Rails) and therefore choose their, say, ETL system in Ruby too.
A good example is authentication. There was one widely used community module that made it easy to add authentication to an app... Until it was no longer the popular way to do things and all the tutorials had moved on to something else. I believe that module was eventually deprecated entirely with the next major version of rails.
I haven't touched rails in maybe 10 years now and I'm scared to try to find the right way to catch up.
Anyone have a good recommendation for how to learn modern Rails?
Fwiw, I'm not looking to start and flamewar but having been a (mostly backend) Python guy for the last 8 years, things seem to still move quickly but have fewer breaking changes in the Python world.
It would all be very familiar!
Just fire up a new project and off you go!
As for authentication, if you want a ready to go solution, then Devise is still current and pretty much the default!
Development of Gems like Attachinary are now deprecated in favour of Rails' Active Storage.
I'm not an expert, but I still dip in and out, and find I can still get by with the basics I learnt back on v3!
YMMV :-)
??? Python 3 fiasco?
Rails moves fast but Ruby has kept backwards compatibility since 1.9...
A video showing DHH building an app, then examples of household names that were built on Rails, then concise code samples outlining how you put an app together. Brilliant!
Contrast this with frameworks that gush about how awesome they are on the home page, but make you dig through pages of documentation just to understand basic concepts and what supposedly makes their approach unique.
But what are its problems? Where will I hit a barrier?
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'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.
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.
[0]https://github.blog/2021-08-11-githubs-engineering-team-move...
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).
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.
GIL (Global Interpreter Lock) is the Python name. GVL (Global VM Lock) is the Ruby name.
Though with Ractors in Ruby 3 it's not actually global (unless one Ractor is a “globe” and a multiractor program is super global.)
Yep, Crystal is not as mature as Rust even these days, but it is cute and useful.
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.
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 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.
But I will say I hope to switch soon to something Rails-inspired, like Vapor, in a more modern language, like Swift.
The docs are bad, and when you google for answers you almost always find "here's how to do it rails" first.
All the things that Elixir sells as good fall under the YANGNI. Code swapping sounds great, until you add in docker and red green deploy.
Immutable data seems great, but threaded code isn't all that common in most web apps. (not near business logic threads that is)
I don't see it as mature enough (despite its history) And it's hard to hire for.
I haven't used Ruby in a while, how far have they moved to stricter typing?
I feel they were great in 2012, but right now PHP/Laravel still looks easier to build/prototype w/ and the community is just huge.
For the longest time, I felt the Rails homepage did not do proper justice in explaining the true potential of the framework, especially to the folks who are not aware of Rails and visiting the site to gather some ideas.
This new homepage does a phenomenal job of providing good idea about the framework like who uses it, code snippets, mission statement, helpful links and the good old DHH video on how to build a blog.
> Ruby on Rails scales from HELLO WORLD to IPO
Also, this statement hits home for me. Exciting time to be a Rails developer.
Congrats to the team on this release, been using Rails for over a decade and it makes my day job so, so, so pleasant.
NOPE
The business "doesn't see the value".
I don't think you need to write it off, especially if you're a consultant. That's just bad business thinking, knowing Ruby is a hot asset.
That being said, rails does have an upgrade task now. I have a lot of faith in it, but absolutely zero trust.
Let us know when Rails can safely be updated from one tiny version to the next. I'm tired of Rails developers telling me that nobody can touch any of the myriad packages that're part of Rails, even when there are significant security updates, due to fear of breaking things.
For example I just upgraded a Rails app from ruby 2.7.3 to ruby 3.0.3 and all gems already have compatible versions to 3.0.3.
So what gems are you using there that they cannot be updated?