Hacker News Reader

Comment by herbst | Hacker News Reader

I don't think Ruby 3 will change anything with that. I am one of those who never jumped the boat and still doing their daily coding with ruby, rails & co.

The ecosystem changed a lot, as it always did. Many youngsters learn that single language works everywhere, learn that server and frontend may share their code. If they end up using Rails they likely spend more time in their react files than anywhere else.

The reason why I don't find nice RoR jobs anymore is because most of them are looking for a react/Vue developer with rails skills and not the other way around.

Also I am not sure why you think there should be cheaper Devs. Cheap Devs means unskilled labor, which means a less optimal code base. The situations I built RoR apps for always had a high testing, optimization, quality standard and liquid development process, essentially using all the strengths rails has to offer. why they choose rails in the first place.

View on HN

As somebody who jumped ship, I sort of regret it. I tough I could share more code between the backend and the frontend with JavaScript but that sort of died early on when frameworks like Meteor where declared “the wrong way” of doing things. Hell, in the frontend department SPAs where the big thing for a long time and now with frameworks like Next.js we are going back to server side rendering and static pages. We had that with our Rails apps 8 years ago.

I honestly think that a good and modern Ruby team would have somebody like you, somebody like me and two people that want to switch to Ruby because they like the language better.

When it comes to the react/vue dev with some rails skills. Yes I get you, but a lot of those jobs are for people like me. I’ve been doing Ruby (and Rails) about 5 to 6 years of the last 10 years and JavaScript every step of the way for 13 years now (frontend and backend). I fit the full stack role but I honestly don’t believe that you need more than one of us in a Rails team. I would rather split the rest up between ruby/rails devs and javascript/react/vue devs.

I hear you. The best team I've been in was a rails core dev, me and a trainee with a good portion of modern frontend skills. We build amazing (boring) software, I am sure most of it still in use even thought they don't do rails anymore when our team split away.

I think that is also the general idea. You only need one or two expensive rails guys and some other people who don't find MVC weird, willing to learn, to setup a proper efficient team for any project.

I am in the same boat, but jumping back. Folks at the non ruby company all had fond memories of rails apps and missed the simplicity. The tangled mess of TypeScript was a disaster codebase with massive tech debt.

One of the biggest issues ruby faces is performance. The productivity of the language is undeniable. That is a big reason start-ups so often choose ruby. Eventually Salesforce or Microsoft acquires these ruby start-ups though that the apps run up against enterprise managers who have traditional baroque "cost optimization" incentives. Very few people, especially managers, are comfortable making the argument that paying for more machines is better than paying for more cheaper devs so you see these successful apps rewritten in java, C#, etc. Someone shows execs a chart with costs per user plummeting (usually with a deceptive Y axis), everyone pats each other on the back, and then they lament not being able to find ruby devs when they acquire the next company. I'm hopeful that ruby can close the perf gap enough to slow/stop this weird cycle.

You are saying this as if C# is not a ridiculous productive language.

> One of the biggest issues ruby faces is performance

You can follow along Shopify's progress with the JIT https://speed.yjit.org/. Seems promising.

Ruby's performance as a function of infrastructure cost was largely fixed back with Ruby 2.2. Today it's even faster and uses less memory.

The performance problems were 99% invalid database usage, poor or overly aggressive pre-emptive indexing, or bad active record usage.

Developers lacked education in basic database design, and given rails made it do easy, yes that resulted in a lot of slow code and overloaded RDS instances.

But it was entirely possible to build highly scaling rails apps back in 2012. When I ran Wanelo's engineering team we squeezed 300K+ rpm's on a relatively small cloud foot print. It has since been migrated to Heroku.

Reply on news.ycombinator.com