I'm pretty experienced in Node and React, and discovering Rails recently has been an absolute joy. I feel like I've made the opposite journey from everyone else on HN, because I joined the programming community _after_ the big RoR hype and during the Node/React hype.
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 :)
I’m with you. Writing and testing Ruby is a blast, and it’s so easy to write clean, readable code with it. Performance isn’t great, but it’s just so nice. Rails adds a lot of nice magic on top that makes it even better.
JavaScript (even with TypeScript) and frontend frameworks are…quite a journey by comparison.
I love the lang.. TBH though performance has never been something I see as a fault in the language.
I've almost always found (for my apps) that it's data access that's the hold up. Like if I map the issues, n+1 or bad indexing have almost always taken the lions share of slower code bits.
It irks me when people sight the lang or ruby as having bad memory or being slow. I've seen a tweak of the indexing cut response time to 25%. I even managed a 10x gain off of one index adjustment.
Stay tuned about performance, the Ruby JIT being built by Shopify is gonna narrow the gap. It's now 25-30% faster than CRuby , we'll see in a year how faster it gets.
Source: https://speed.yjit.org/
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
This is the most common slowdown I've seen in rails before. strict_loading mode can help, as can the bullet gem.
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.
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.
Interesting read. Do you recommend a resource to learn rails for the reactjs developer? Seems like only the opposite exist nowadays.
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.
Nice to see that front-end people find it so good to change to Rails. Have you discovered Hotwire already? It helps get JS to the minimum, just like it was the early days - only use it to add interactions.
I'm having the same experience you're mentioning with Laravel and Livewire. It's an amazing and simple way to ship really robust and reliable web apps in a fraction of the time.
I've played around with the new default frontend (no js build step at all!) and it's been an absolute joy. I was able to write basically babby's first Rails app and have it look, feel and behave like an SPA, and that's a wonderful thing for apps that need just a little bit of interactivity. While I've mostly moved on to Phoenix for my personal "weekend project" web needs, Rails is still a wonderful framework for getting an app off the ground fast.
I use Rails as a portable, light, zero-conf frontend for data exploration. Just create the minimum viable rails app (--api), fill in the database connection, and you get a powerful REPL for exploring + rake to run transformations.
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.
I have certainly turned to Rails many times to write a bunch of ActiveRecord models to play around with data in the console without ever running the web server.
Just today I was helping a junior (php) developer get setup & started with ruby.
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.
As you can read in the Rails 7 announcement, the webpacker is history already. Also, you don't even need to have the node present with ESM. So all this complex stuff you mention won't be soon required.
Rails 7 feels like Rails 1 again. So easy to get up and running, no Webpacker nonsense, back to plain CSS and JS (no SCSS, Babel, other pre-processors), plus lots of nice new features on the backend.
Yes! I have two Rails apps (5.x and 6.x) to upgrade to 7. I'm curious which one will be easier. My hunch is the 5.x app since it didn't rely on Webpacker/Node either.
While I think the new site certainly looks appealing and includes a lot more helpful information than before, there's something about the old playful, hand-drawn design that felt more like it embodied the ethos of Rails.
Going to somewhat hijack this to ask a question. Are there any popular non-Rails uses for Ruby? I'd like to learn Ruby but it seems that Python and Ruby occupy the same space and use cases so you really only need to know one of them.
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.
Tiobe and Stack Overflow rankings don't mean much. Look how popular Tiobe ranks VB due to Excel macros, or SO ranks Bash and PowerShell very highly simply because people ask a lot of questions about it.
I cited the three most popular rankings. I don't know what else to do here.
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.
I mean, it's not Java, C#, Go or JS. It never was that big.
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.
Popular as in industry usage? Which is comparatively very small.
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.
Not yet, but it's now in the category of "You won't get fired for picking X". It's seen as enterprise-y and 'safe' and yes, is definitely quite used.
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.
The important question is would you have enough choices in Job Hunting if all you know is Go. And Go seems to be close to if not already a self sustainable status.
You're right, although doesn't really change my premise. I use Bash everyday, even though I have never tried learning it, don't really care about it, etc...
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.
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?
Ok the Tiobe => Fortran is complete horse shit and we all know it. Fortan and Perl are both more popular than Go in that ranking I mean come on. But sure I agree Ruby is a nichey language, usage-wise about the same as Swift/Scala or maybe even Go. Somewhere in the top 10-15 I'd guess. If you look at web backend languages (e.g remove C/Visual Basic/C++) Ruby is probably top 10.
There are definitely uses cases for Ruby without Rails. It's a great command-line scripting language, for example, filling the slot of an evolved Perl. There are also lighter-weight approaches to web scripting, such as Sinatra and bare Rack HTTP servers. I have no idea how prevalent that is. I did it for several small but well used apps.
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.
As a Ruby developer, I really fail to see any benefit or Ruby over Python (or even Node) for commandline scripting.
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.
What have you built lately in Python/Node 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.
Panda's et all do investigate Data. There are tools in Ruby for Datascience but the resources are thin or completely lacking.
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).
If nothing else, Python’s miserable package management ecosystem makes me reach for Ruby instead. I’ll take Bundler over requirements.txt, pipenv, poetry, etc. any day.
I use Ruby without rails all the time. It’s extremely convenient for shell scripting (basically anywhere I might have used Perl in the past).
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.
> It’s extremely convenient for shell scripting (basically anywhere I might have used Perl in the past).
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.
A lot of iOS build automation tooling is dependent on Ruby. fastlane is the de-facto standard in this space, which is a Ruby gem and CLI application. As a result, every iOS developer almost inevitably has to learn at least some basic Ruby to cobble together a deployment pipeline for their app.
It's a great example though, I really like how readable Homebrew formulae are. Run "brew edit go" or "brew edit pkg-config" to take a look at how things are downloaded and built.
I like ruby but the recent static typing feels a step backwards having have to write a separate file, unlike typescript where you can incrementally add typing to the actual source code.
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.
Dragon Ruby is a relatively recent game making toolkit with one of the main devs being also one of the main SDL devs. It's a full programming language so you can use it for whatever you want, it just is most popularly used for RoR.
I have a bunch of APIs running in AWS that are written in pure Ruby. My Slack status automation is written in pure Ruby. Most of the things I integrate with have SDKs for Ruby.
As long as Shopify keeps using it, Ruby will have a place in the world!
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.
I use Ruby for Rails and for scripting. I script in Ruby anything I used to write in Perl up to about 2010 and I feel too complex to write in Bash. JavaScript is a no go in that space because of async, Python (which I make more money from than from Ruby) is just (subjectively) uglier and less convenient. Maybe this is because I was more in love with Perl than with C in the 90s.
I first learned rails almost 15 years ago and at the time, there was already a proliferation of getting started blog posts targeting different major versions of Rails. It was a hot mess with older tutorials referencing modules that were deprecated, unmaintained, etc.
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.
The home page redesign is a framework website done right. If you want to draw people to a tech stack you need to show, not tell.
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.
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.
Hey and Basecamp pay the bills so that Rails can be what it is. I don’t mind a name drop. It couldn’t have been more subtle and it was actually very relevant. Didn’t seem like an ad to me.
I really like they use Hey to show how a real application can be done using rails. DHH shows the internals of Hey in some tutorial and I found it very interesting.
I recently tried to build a relatively simple blog app with Vapor just to learn it. Once I got to trying to find third party libraries for things I needed it got very frustrating. I just needed to interact and generate a key using the AWS sdk. My hacky solution was to use the golang lib and compile it to C then import it. It was more hassle than it was worth for me. I like swift but it doesn’t feel like the ecosystem is interested enough in server for me. Hope to see that change but I’m not holding my breath.
Elixir, or rather Phoenix - more specifically, is not good for traditional web apps, in my opinion. You will basically reinvent everything like in the JavaScript world. The functional way of programming looks great at first but there is a reason why it isn't used everywhere, if it is so good :). Feel free to explore though. And make your own opinion.
I've tried it a bit (via https://phoenixforrailsdevelopers.com/), and it seems very cool especially with the realtime features, but I greatly prefer Swift as a language.
Aside from Rails 7 release, what I'm more excited about is the new homepage which also got updated with this release.
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.
Relation.load_async seems like a BFD - too bad I probably won't get to use it at my current job - we're only now starting to talk about the move to rails 5 - still stuck with Rails 4.2 and Ruby 2.5 (eehh).
Congrats to the team on this release, been using Rails for over a decade and it makes my day job so, so, so pleasant.
Despite me writing off Ruby as a career path for the last five or six years (and I stand by that), out of nowhere a client has dropped a simple Rails API in my lap as part of a consultancy role and so I've updated it, deployed it and am about to rewrite it to add tests and move the logic to more sensible places. And - as before, it's a joy to use and work with and be productive again. Looks like I'm updating to Rails 7 then...
did they have full rails 7 upgrade/migration guide? like how to remove ujs and turbolinks, how to remove the webpack and setup the js and css bundler for rails pre 7?
Fool me once, shame on me.
Fool me twice, shame on... well, you know what I mean.
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.
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.