3 ms·

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 flam

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?

bradstewart 7y ago
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.
NegativeLatency 7y ago
Sounds like an ISP bandwidth issue, the bottleneck is the network not the cpu.
deleted 7y ago
[deleted]
NortySpock 7y ago
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.
Qasaur 7y ago
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).
- saagarjha 7y ago
  Networking stacks tend to be fairly optimized already.
cortesoft 7y ago
I don't think C++ generates more efficient packets than Ruby.....
- jjgreen 7y ago
  In fact they are more efficient, but not as elegant.
DontGiveTwoFlux 7y ago
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.
ficklepickle 7y ago
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.

bradstewart 7y ago

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.

NegativeLatency 7y ago

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

deleted 7y ago

[deleted]

NortySpock 7y ago

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.

Qasaur 7y ago

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).

saagarjha 7y ago
Networking stacks tend to be fairly optimized already.

cortesoft 7y ago

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

jjgreen 7y ago
In fact they are more efficient, but not as elegant.

DontGiveTwoFlux 7y ago

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.

ficklepickle 7y ago

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.