You say that like it's a point in support of Ruby, but, yes, absolutely, Python should be thrown under that same bus. Both languages are dramatically slower than other languages that are available. My little hobby programming language with a bytecode VM I wrote myself in a single C file is faster than Ruby and Python. It would be hard to design a language that isn't easy to make faster than Ruby and Python.
They both pay an incredible runtime performance cost for their deep support for dynamic runtime metaprogramming and mutability. If you don't want those features, I don't think it makes sense to use those languages.
For comparison, elixir's Ecto doesn't allow lazy loading
Where I work, our main product is a Rails monolith, over 10 years old at this point. The few serious performance issues we currently have are due to complicated SQL queries written back when the DB was much smaller.
Why?
That's precisely the problem. If engineers were a dime a dozen, then Rails could be a great choice. Boring tech is a great place for businesses to be, in theory. Back here in reality, finding engineers is pretty hard, and the ones who we can find, are all only interested in working with Cool New Shiny Toys. If we posted a Ruby ad, we wouldn't get any bites. It's not used here.
Boring tech is great, until it becomes a noose to hang yourself with.
If engineers are hard to find then isn't using a framework that maximises developer productivity the way to go? Rails definitely falls into that category.
Related, we recently advertised for Rails and React engineers. We had about the same number of applicants for each position but the Rails engineer quality was in general higher than the React engineer quality.
Languages are not like cars. You cannot take a professional Rust engineer and drop him into a Ruby environment and expect him to be immediately highly productive, as if you were switching him from a Miata to a Ferrari. Languages need to be learned all over again, their ecosystem needs to be learned, beginner code needs to be reviewed by someone senior who is more familiar with the language. You can't just make an executive decision to go with Ruby because it has a reputation for productivity and expect immediate productivity gains.
Are they not, though? The narrative is that there's simultaneously too many engineers coming out of school and yet it's extraordinarily difficult to hire engineers. Which is it? Or are most engineers really that bad that they're unhirable?
> Back here in reality, finding engineers is pretty hard, and the ones who we can find, are all only interested in working with Cool New Shiny Toys.
I definitely believe you, but I wonder how much of this is self-fulfilling. Maybe a lot of engineers get into cool-tech because more jobs are demanding it, and their perception is they'll be quickly obsolete if they work with boring-tech. Most newbs seem to look towards startups first, which are going to be using cool-tech a lot of the time, but there seems to actually be a lot of interest on HN in working with boring-tech at either nontech companies or BigCo.
It's both. You need to be a large company to hire junior talent. The local market is mostly startups without well-developed production guardrails and well-gardened, too long backlogs. The large companies cherry-pick for the relatively few junior positions that open and they aren't using Ruby internally. Thus the Ruby ecosystem hasn't developed here.
> but there seems to actually be a lot of interest on HN in working with boring-tech at either nontech companies or BigCo.
HN trends senior talent which has been around the bloc enough times to know that stacks change and people don't. Most of the labor market comes into interviews and want to impress you with how many languages they know.
Some people have decided that that isn't good enough for their company though.
Expecting engineers to self-teach from a book is practically begging for NIH syndrome and a rewrite in two years.
I always ask myself (and the team at large) "how much time/effort will it take to reach parity using the new tool-set?". The answer usually settles the debate immediately.
As a new shop, without a known depth of knowledge and talent, I'd probably avoid Rails if scaling is a concern, but if I'm Gitlab or Shopify or some place with world class Ruby engineers, I'm staying the course.
A lot of us are. I don't think Gitlab is in any shortage of resumes...I tried. Might be the market collapse or whatever reason, didn't even get past the initial HR interview. It's also possible my country of residence isn't high on their list...we are expensive.
I dont think that's the case. I think Ruby is dismissed because it's not a boring language, but has none of the safety of the other "shinier" languages.
- It's loosely typed and most orgs end up putting in some type system since it can get unwieldy
- Performance is poor at scale
Both can be "patched" fairly easily at scale though:
- Start introducing a typing system: https://sorbet.org/
- Split heavy throughput services out into things like Go, Java, etc.
There's this meme that Rails "just doesn't scale" and is "yesterday's software", but neither are necessarily true. Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it. There's things I don't like about both Ruby and Rails, but it's a perfectly viable and productive way to build websites. A very scant number of businesses need to be at the scale of Twitter or The Google, in which case Rails can be a great choice.
But I imagine Rails is being increasingly dismissed by newbie developers as being obsolete and not-cool. Mature companies may realize it's in their best interest to communicate that their boring-tech works just fine and that they have no plan on changing to cool-tech. If it's true, then someone's got to say it, right? Someone needs to be interested in working with Rails. Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices.