[Ylmaz]

I like this quote from 'The art of Unix Programming' published in 2003

"While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly constant dollars.

These plunging costs change the economics of programming in a fundamental way. Under most circumstances it no longer makes sense to try to be as sparing of machine resources as C permits. Instead, the economically optimal choice is to minimize debugging time and maximize the long-term maintainability of the code by human beings. Most sorts of implementation (including application prototyping) are therefore better served by the newer generation of interpreted and scripting languages. This transition exactly parallels the conditions that, last time around the wheel, led to the rise of C/C++ and the eclipse of assembler programming."

[dilippkumar]

In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second.

Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation.

I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc. This also ignores the decades worth of excellent tooling we've built up for C++ (static analyzers, fuzzers, etc).

At a startup, when building things fast matters more than costs, sure. I buy the argument for Node or Python or any other interpreted backend. But once you start to scale, things change after some threshold. Unless you're facebook[1].

[0]. https://www.techempower.com/benchmarks/#section=data-r21

[1]. https://developers.facebook.com/blog/post/2010/02/02/hiphop-...

[timerol]

> I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc.

The problem here is assuming that a 7.7x less expensive AWS bill is the same value as a 7.7x more expensive development time. Imagine an app that is maintained by one programmer costing $10k a month and running in AWS for $1k a month. It is not worth dividing that AWS cost by 10x if it means a 10% development time hit. Actual numbers may vary, but development often costs much more than running in AWS. (For startups it's even more of a difference, because you pay AWS as you get more traffic, but you pay developers before you have an MVP.)

[saurik]

FWIW, AWS is expensive... but mostly for networking and then second to that storage, with the cost for actual computation usually being a pretty small percentage of my overall spend. The only time I have seen computation itself be an interesting expense is when I am looking for some complicated hardware, such as their GPU or FPGA instances. That said, money is money... but it is much easier to figure out fun ways to save storage or bandwidth when the code is a bit more nimble, so I'm not sure I could justify larger teams or slower iteration times just to save on CPU.

[dilippkumar]

> but mostly for networking and then second to that storage, with the cost for actual computation usually being a pretty small percentage of my overall spend.

What portion of the bandwidth is end-user facing and what portion of it is connecting all the servers? Another way of asking this is if I need fewer servers because code runs faster, how much less bandwidth do I need?

[saurik]

AWS doesn't charge for internal server-to-server transfers, so the answer is precisely 0.

[caleblloyd]

That's only true for transfer in the same availability zone.

https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer_...

[ReflectedImage]

"AWS for $1k a month" hahaha. People spend $90k on AWS by accident.

[Ylmaz]

The speed of your web framework is, in reality, often irrelevant. Our slow nodejs app handles millions of customers with a few cheap and simple caching layers. Our salaries are a lot higher than the infrastructure costs.

[fweimer]

Except … for spewing out fortune responses, most of your cost by far will be in bandwidth charges. Those won't change with the implementation language. If anything, the C++ version will just be able to burn your dollars faster.

(Yes, I know, it's just a silly example, but compute costs are only one aspect, and the bandwidth pricing in the on-brand public cloud actually tilts overall costs towards being bandwidth-dominated for many applications.)

[apozem]

That's a great way of looking at it. Languages all have benefits and drawbacks, but you have to consider whether they help you for your problem.

One time, I met a guy who wrote firmware for Seagate hard drives. Any new feature he added had a budget measured in microseconds. Obviously he wrote nothing but C++.

[efficax]

in 2003 you hoofed your servers to a colocation center and plugged them into the internet yourself. Deploying was something you did over `scp`. Buy a big server and you're good to go. That can still be the case these days (see stackoverflow which at least until recently was not using cloud deployment). But for the most part people use cloud platforms that charge by fractions of a second of cpu time. It's never been more cost effective to use a compiled language than it is today. And that would also apply to bare metal bring-your-own-server deployments. Want to host a monster site on just a pair of beefy servers? The less resource intensive your backend, the more requests you can serve per second.