Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.
Google, Facebook, Amazon and Twitter beg to differ (not completely C++, but for services where it makes sense). Also nginx, passenger and other parts of your Ruby app.
Shrug, you have no idea what you are talking about [1]. Also nginx and passenger are webservers and claiming they are not part of your web app is a pretty wild claim when they literally send http responses to browsers (unlike memcached).
I think you're the one who got confused with the context here.
We're talking about web-app, not microservices.
We're talking about CRUD with DB migration, sessions, caching, etc.
I recalled Google's dl.google.com was implemented in C++ and Brad F rewrote it with Golang. We're not talking about microservice that serves file here. We're talking about the main web application that serves wikipedia, youtube original version (they might had revamped it sometime post acquisition with web gateway and bajillion microservices), Google Search (was Java servlet), Facebook original web-app (was PHP, became HVVM/H4CK.
So yes, I _know_ what I'm talking about in terms of the context of a web-application here. Do you?
RoR and whatever C++ based web backend there is count as a valid comparison in my book. But comparing the languages itself is maybe a bit off.
On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.
Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.
Nah. One rust based server can power the same number of connections as 10-100 ruby based servers.
This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).
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.
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.
>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.
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.
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.
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.
Yes and no, some languages like Python and Ruby do introduce overhead even in conditions where waiting for the DB is 80-90% of the time spent on a web request -- that much is true. But the database I/O problem is definitely not pretend. It's very real.
They all have their niches. Rust is difficult but rewards you for your persistence.
I do appreciate Rust a lot but nowadays find myself reaching for Golang more often. I simply don't have the extra time and energy to learn the final more advanced Rust pieces in my own leisure time so I'll learn it whenever I can but yeah, in the meantime: Golang to the rescue.
> I simply don't have the extra time and energy to learn
Nobody does these days. Language is just a tiny piece of the whole Cloud ecosystem aside from k8s, docker, different storages (elastic, rdbms, mongo), different monitoring/metrics solution, etc.
I work for a company that is testing Rust and the complain was that the tooling wasn't there compare to Golang.
I am not interested in being put in a corner where I have to defend web backend creation that I don't even practice. I only said it's being done by people. Feel free to reject it or degrade it as being "a curiosity", from where I am standing reality disagrees with you though.
You're right about that, and that's something I believe the Ruby team is struggling with, to show where Ruby is useful outside the Web field. Everyones picture of Ruby is web related thanks to Rails, there is no question about it.
And I find that bit sad because Ruby is also good at other things like building cli apps (have a look at Metasploit for example) & gluing different moving parts together, creating your own DSL thanks to its flexible language structure.
I wouldn't say Ruby is better than any other languge though, all general purpose language could probably achieve the same result, it's just a matter of taste.
We're venturing in the not exhaustively objectively proven benefits and virtues of strong static typing but nowadays I reach for Golang and not for shell scripts (or Ruby, or Python).
Why?
Just today I again had to do Homebrew cleanups so one recipe can install. Likely my fault, 100% sure about it, but I just need non-confusing tools in my life.
...Or I kept grooming my homemade cross-machine provisioning scripts (i.e. install baseline tools like git and a few others, and then bring my up entire environment along) and in the end it still couldn't source a script that is right there in the file system and even after I made sure it got sourced, it still couldn't find the stuff inside it... while all other 20+ such similar `source stuff.zsh` work just fine.
At one point you do get fed up. (And yes I know this is not strictly related to strong static typing; it's just one example of a thing that will reduce bug surface.)
Ruby is easy to write. And that's the problem. People tried to do too much with it. And it's early glory of including a gem that monkey-patches the core library APIs did not do it any favors either.
Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.
But yeah, that's venturing into philosophy which was not the topic.
TL;DR: Ruby is fine but is fairly limited for my taste. My needs are far bigger and they also include maximum 50ms of startup time.
>But yeah, that's venturing into philosophy which was not the topic.
I guess you touch on something why many of the discussions on HN and Internet fail to get the point across, when you could have someone in their 10s or 20s who couldn't understand it. Just like how we were told when we were young.
>Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.
It is unfortunate this line of fine balance thinking is not well understood by many, young or old.
It may be worth comparing this new JIT to fast implementations of dynamic languages, like LuaJIT or SBCL for Common Lisp (SBCL is an AOT compiler and not a JIT though).
It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.
Anything and everything that has a web backend is a fair game for comparison.