Hacker News Reader

Comment by sergiotapia | Hacker News Reader

Makes you think, how much further we could stretch things if we were all using the Nims/C/C++ of the world instead of the Ruby's.

Please don't immediately flame, I'm just saying objectively, we could stretch hardware out much further. What do you guys think about this?

View on HN

This about network bandwidth capacity, not server hardware load. Netflix is going to send the same bytes over the network regardless of what language it's using for the server code.

I don't think C++ generates more efficient packets than Ruby.....

In fact they are more efficient, but not as elegant.

I strongly subscribe to this view. Opinions like this get dismissed by the usual premature optimisation argument and that engineer-time is expensive, but I think that if we built our stacks with performance and efficiency in mind a significant chunk of operating and indeed development costs would be eliminated from corporate expenditures and would outweigh the potential initial development costs (which I don't think is that much of an issue, especially when you have competent and skilled engineers building said software).

Networking stacks tend to be fairly optimized already.

I mean, there is always the productivity trade off. If hardware/bandwidth is cheaper than dev time... I guess that was the idea with Go, to be productive to write and more efficient to run than the dynamic languages.

I think incentives in commercial software are out of whack. It's often more profitable to make garbage software that is barely fit for purpose. But that same critique also applies to much of our economic system.

If we want a particular outcome, the incentives need to be aligned accordingly.

It's always been a trade-off of engineering time to improve performance vs shipping new features.

That said, I have been enjoying maxing out my Raspberry Pi to see what I can get it to do. (File server, PiHole so far, transcoding audio files so far...)

Looking forward to writing some node.js servers for it to see what it can support.

I have to imagine that this is to mitigate problems with bandwidth intensive low level networking equipment that is performance sensitive, not application level code. That equipment typically runs code in the languages you mentioned.

Sounds like an ISP bandwidth issue, the bottleneck is the network not the cpu.

Reply on news.ycombinator.com