42 ms·

This is an operating system. Efficiency is a feature, and this project is a bunch of hooey.

rickycook 11y ago
the same argument could be had against languages like Python, ruby, and JavaScript. making things easier to develop against often means that complex things exist that make things faster. look at pypy for example: Python interpreter written in Python that's faster in many cases than cpython because they could build advanced features for optimising the underlying running code. writing an OS in C because efficiency seems like a load of hooey to me unless you have facts to back up your idea that for some reason the OS has to be the efficient thing. software development comes down to 1 thing: delivering features. who cares if you need twice the servers to run your product of the alternative is you run out of runway and your project gets canned. hardware is cheap, engineering time is not
- roddux 11y ago
  >who cares if you need twice the servers to run your product I couldn't help but wince at this. I feel like this isn't a healthy attitude with respect to programming.
  - erichocean 11y ago
    Okay, how about this hypothetical? Ask yourself if the service you're trying to create would have been valuable, say, 4 years ago. Yes? Okay, suppose you wrote it in C++ 4 years ago on four year old hardware? Is it still valuable? Yes? Okay, now write it today in Node and run it on modern hardware. The hardware cost is the same, the service exists, and it was presumably cheaper to write and maintain in Node. Is it still valuable? Yes? That's why it's reasonable to write apps in Node.js today: the performance and cost are the same as doing it in some "more efficient" language 4 years ago, except the cost to actually build the thing now in Node is (much?) lower. If you were okay with the hardware costs for the service 4 years ago written in C++, you should be okay with the hardware costs for the service today written in Node. You can use this argument to support "slow, inefficient" languages for many different kinds of projects (though not all, obviously). And I'm an efficiency nut.

the same argument could be had against languages like Python, ruby, and JavaScript. making things easier to develop against often means that complex things exist that make things faster. look at pypy for example: Python interpreter written in Python that's faster in many cases than cpython because they could build advanced features for optimising the underlying running code. writing an OS in C because efficiency seems like a load of hooey to me unless you have facts to back up your idea that for some reason the OS has to be the efficient thing. software development comes down to 1 thing: delivering features. who cares if you need twice the servers to run your product of the alternative is you run out of runway and your project gets canned. hardware is cheap, engineering time is not

roddux 11y ago
>who cares if you need twice the servers to run your product I couldn't help but wince at this. I feel like this isn't a healthy attitude with respect to programming.
- erichocean 11y ago
  Okay, how about this hypothetical? Ask yourself if the service you're trying to create would have been valuable, say, 4 years ago. Yes? Okay, suppose you wrote it in C++ 4 years ago on four year old hardware? Is it still valuable? Yes? Okay, now write it today in Node and run it on modern hardware. The hardware cost is the same, the service exists, and it was presumably cheaper to write and maintain in Node. Is it still valuable? Yes? That's why it's reasonable to write apps in Node.js today: the performance and cost are the same as doing it in some "more efficient" language 4 years ago, except the cost to actually build the thing now in Node is (much?) lower. If you were okay with the hardware costs for the service 4 years ago written in C++, you should be okay with the hardware costs for the service today written in Node. You can use this argument to support "slow, inefficient" languages for many different kinds of projects (though not all, obviously). And I'm an efficiency nut.