Hacker News Reader

Comment by timeimp | Hacker News Reader

>The most in-demand skill was Ruby on Rails, with engineers skilled in this framework and scripting language receiving 1.64x more interview requests compared to the marketplace average. Ruby on Rails bumped Go from first place in 2022’s report to fourth this year.

Woah. That’s an interesting finding.

I wonder what RoR is doing to make it so in-demand?

View on HN

It's not necessarily in-demand. It's the ratio of jobs to applicants. Both numbers can be low which anecdotally feels right for Rails. It's not the new hotness anymore but there's still plenty of systems to maintain/expand. Can be hard to hire because fewer engineers want to do it but the systems can't easily be transitioned to a new language.

RoR enables developers to make a lot of progress on their app in a short amount of time... initially. Most developers have never seen a legacy Rails app, or are still in the self-deluded "this time it'll be different" phase. So they jump wholeheartedly into the Rails ecosystem and build their app the "rails way". Not knowing the pitfalls, they fall into all of them. A few years later, you have a successful Rails app with (1) slow, data-coupled tests (2) spaghetti code in your models and controllers (3) probably dockerized, relies on heavily outdated linux version and no one can update it within a sprint so it never happens. So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).

I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase.

I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)

> random middlewares

The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code.

If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.

> If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.

That's just the chain of responsibility pattern [1] and I've only seen middleware operate that way. Why wouldn't you want control over the order?

[1] https://refactoring.guru/design-patterns/chain-of-responsibi...

> data-coupled tests

I’m intrigued what this means, or how you’d decouple your tests from all data.

I can't know exactly what the OP means, but I'm guessing they're referring to the tendency for Rails tests to rely heavily on the database and its behavior. This technique is often rationalized for being a partial substitute for end-to-end testing, given that it tests the integration of the app with its services, and that's not wrong per se. It does come with a penalty because constantly building and tearing down the database has consequences in terms of performance and state leaking between test cases. A lot of the time, this reliance on the database is not (or should not) be necessary; it should be possible to test units of the application in isolation, even including the model->controller->view cycle, without needing to include any knowledge about what database or ORM are being used. Just building in-memory data on the fly is safer and faster, and when tests are faster then developers are more likely to run tests frequently and spot issues earlier.

Again, as with many things, it's not a Rails-specific problem. It's an issue in many kinds of codebases, and is an issue with the Ruby community in general. I understand the arguments around coupling tests with the data layer implementation, but I just don't agree when it comes to most of the useful tests being performed.

Thank you for this excellent response!

This describes a lot of my reasoning for why I left Rails for a more frontend/JavaScript focus.

I don't think it's necessarily a problem specific to Rails. It's an issue that the Ruby community that they may never see as a true problem. To their credit, having a system that sucks developers into making simple apps that grow into monstrocities seems to have created a ton of job security for Rails developers. In terms of developer happiness, I really beg to differ once any given Rails application is more than a year old.

Rubyists love object orientation and metaprogramming, which I personally see as massive mistakes outside of some niches. Ruby applications in 2023 still have long chains of inheritance, and still employ lots of metaprogramming, and still use tons of syntactic sugar, and still think along the lines of classes rather than methods/functions, and still allow for side-effects on mutable objects. I've found that at least 80% of issues typical to Rails codebases are related to those styles of software development. Most of those are unnecessary for writing most apps using Rails.

> So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).

That's the true black-pill of senior-level software engineering. Chances are, as a senior engineer, your job is to figure out the mess rather than make sure anything was done appropriately in the first place. In retrospect, I enjoyed my job as a junior and even mid-level engineer more than being a senior engineer because I often got to work on new and interesting problems while senior engineers had to toil over figuring out some incredibly complicated and boring shit created by the previous engineering regime, as well as by the junior engineers as a whole. Because the business will always be pushing for more features and more deadlines, this problem never gets fixed, hence being a senior engineer becomes little more than an exercise in Sisyphean futility. And the pay is just enough that you don't go fishing instead.

I'm just glad I only spent around 3 months as a senior Ruby engineer before switching to JavaScript, despite all of JavaScript's faults.

Rails provides a sensible and productive pattern for MVP but doesn't provide much guidance past a certain complexity level (Service Objects etc). Once the app grows past a certain size, more bespoke architecture needs to be applied and this will live or die on the competence of the team. Spaghetti code is not inevitable but can result from devs who are used to the hand-holding of less complex Rails apps.

Dunno where you are pulling docker from, that is completely orthogonal to Rails development.

I took the Docker comment as a sort of dig at Rails teams throwing tech at problems in an inappropriate way with the goal of overcoming poor decision making. Not sure how fair that is since the use of Docker et al is often an exercise in cargo cult tech.

At the very least a docker/containerized app is really nice for development envs especially if there is a variation on hardware/machines used

Yeah, dragging in docker is perhaps unfair, but Ruby apps suffer in a docker environment especially because of how much native code Ruby gems like to include (and how incredibly brittle they are under slightly different C++ compilers...)

Many of today's big tech cos, which were unicorns in the 2005-2015 era, were built on top of Ruby/Rails.

Today those companies have diversified their tech stacks but for the most part the core rails monoliths aren't going anywhere. They need engineers to work on them.

Probably advertising skew. I remember Hired being advertised on RoR specific boards and sites.

I think there are many RoR projects that continue to run, so probably demand still there - we've been maintaining several RoR projects for 7+ years. Recently we've stepped into several JS projects that have 2-3 competing JS frameworks in the same project. Any project becomes difficult to maintain over time without a continuous and thoughtful investment of time, but at least Rails doesn't have that particular problem of framework churn (even if parts of it may change as a whole it has an upgrade path that is well trodden). We do a lot of React/Next.js etc. work, but for the most part Rails is what we reach for (maybe with a sprinkling of React) when we have a standard web project, ie. most of them.

Yep, I have RoR on my resume/LN profile from years ago (rails 3.x), and I get recruiters spamming me - mostly for legacy maintenance/modernization/porting to another stack type jobs.

I've moved on, not so interested in going back...

In my experience with Hired there are a lot of companies that started around 2010 that chose RoR and haven’t quite made it yet.

Same result as 2021.

Must be due to all the "it is dead and forgotten" hate Ruby gets :)

because languages that were popular before but aren't now are always a hit.

see COBOL for example.

Reply on news.ycombinator.com