[cutler]

But you factored-out developer productivity. What you gain in reduced server costs is lost many times over in developer productivity. Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++. They did the math and the business case for Rails was more compelling.

[pdimitar]

> But you factored-out developer productivity.

Let's not act like everyone who tries Rust gives up. OK? Sure it's definitely more difficult but people are learning and practicing and the pool is slowly expanding (me included, though I am not at production-grade experience yet).

> What you gain in reduced server costs is lost many times over in developer productivity.

Are you exaggerating for dramatic effect? I'd say depending on your people's seniority the productivity loss is anywhere from -50% to -500%, which is hardly "many times over".

You absolutely do iterate slower with Rust writing web backends -- no two ways about it. But you also (a) exaggerate the multiplier and (b) underestimate the long-tail of gained productivity that a language like Rust brings to the table (strong static typing et. al.)

And even if we take into account your comparison between server costs and programmer productivity -- there are areas where correctness and speed are more important than Joe and Susan being able to crank out 17 CRUD endpoints this week. I feel that this nuance is often ignored.

> Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++.

I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.

I am consistently blown away by the protected and downright pampering environments that some HN people have lived in. It's pretty brutal out there though, and somebody has to point that out to you every now and then, lest you forget it (which it seems that you did).

> They did the math and the business case for Rails was more compelling.

They did no math, except one: how easy it is to hire 5 new devs in the next 1-2 months. No other analysis was involved whatsoever. Again, I've looked from within, a good number of times.

---

I am all for an informed debate but that seems to be difficult with you as you resort to exaggerations and dramatic language.

For the record, I don't do my main work neither with Ruby on Rails nor with Rust (though I know both, or should I say I knew RoR because I haven't used it in a while now). I got no horse in the race, I am simply looking for an objective discussion based on merits that can hopefully ignore network effects and popularity. Technologies absolutely can and have won by utilizing network effects and popularity (see: Python) but that does not say much about their objective merits.

[ksec]

>I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.

Luckily we now have company that is large enough with incentive to optimise it.

[wredue]

Rails is no more productive than go, and a developer taking 20 extra minutes (frankly, not likely, even if we’re talking rust) to write go rather than Ruby is not going to cost more than the $1000 a month the extra Ruby servers cost you just to run.

“But but but developer productivity” is a myth.

[cutler]

It sounds like you haven't worked with many startups which is where Rails has been the goto option for a very long time. Rails is a framework. Go is a programming language. Show me a Go command line which sets up a fully-baked MVC app complete with data model, migrations, CORS, caching, asset pipeline, mailer, mailbox, chat(Action Cable), job queue and a Hotwire equivalent. While you're baking all of that yourself I'm launching our MVP. There's Buffalo but you compared Go with Rails so I assume you meant rolling your own using just the Go standard library.

[pdimitar]

> While you're baking all of that yourself I'm launching our MVP.

That's the only thing RoR wins at: speed of delivering first MVP.

Once you get into areas where companies don't die if they can't deliver a demo next week, RoR is not at all impressive or even consequential.

[wredue]

I think that’s as far as the grand scheme of a project goes, coding productivity is a myth.

Can a python or ruby dev bang out Advent of Code faster than I can in zig or rust? Sure. Is advent of code representative of a multi-year long business system where coding is 15% of the time cost at the high end? Nah.

When you look at the actual bills and where the actual time goes, spending time on optimizing the code pace of a MVP is simply not valuable. You’re saving a small percent of a small percent of time at the beginning to accept using languages that are not know for their steady state support ability.

[pdimitar]

Yep, agreed on all accounts. People simply love their languages and will point out any area they "win" at, even if it's inconsequential and not at all important. And that's happening a lot, including TechEmpower benchmarks, speed-to-first-MVP, and many others.

[hello_moto]

Oh gosh, stop it.

I skip Ruby hype but I know RoR and I use Golang professionally to build microservices serving Fortune 10,50,100,500, whatever and I wouldn't use Go to build a web-application.

Golang for microservice that relies on other microservices are great (i.e. my Golang service doesn't handle authN/authZ, but another service does), Golang for monolithic web-app that has to handle db migration (yeah I know something exist), implement multiple crud objects (remember, Golang microservices typically has smaller context and challenges than a medium size web-app) is pain in the ass!

PS: cut my teeth in Java servlet/jsp, moved on to Spring Framework+GWT, skipped RoR went straight to JS and ended up in Golang for the last 5+ years. I'm not Rails worshipers but I'd probably pick Java Spring ecosystem over Golang for monolithic web-app.

[pdimitar]

It's not a complete myth. But I'd agree that it's overblown and overly touted.