Ask HN: Is Ruby on Rails still relevant?

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...

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.

DHH's blog video feels pretty dated now. Does anyone have any pointers to a decent video tutorial that starts from the basics?