4 ms·

Moore's law has continued, but this increase in transistors stopped translating into commensurate increases in performance at every level. I would argue that w

Moore's law has continued, but this increase in transistors stopped translating into commensurate increases in performance at every level. I would argue that wherever performance really matters, that is, where it is measured and where the improvement is estimated to reduce cost or increase revenue to the point where the programming effort is justified, we're already near the optimum. I don't see many fields where this is the case today but won't be tomorrow. In the past, software needed to be optimized just to run at all, but that constraint is gone forever. Consumers generally accept software that is kinda clunky and slower than it needs to be, peak performance rarely becomes the differentiator that it needs to be to justify optimization on modern hardware. Language benchmarks only give you the theoretical lower bound of runtime, but software in practice is usually much slower than that, regardless of language. For instance, it's not unusual to see some C code with unfavorable complexity, just because someone didn't bother to bring in a data structure that would've been part of the standard library of a slower language.

lumost 6y ago
I think the optimal point is more ambiguous in the industry than we normally think. In the earlier part of the teens SaaS businesses in high throughput (>1k TPS) fields such as ad-tech were often created with ruby/python and related languages. From my observation these businesses hit significant friction managing costs as they scaled relative to peer companies using Java/C stacks. While it was possible to build a competing product on latency, it wasn't generally feasible to build a competing product on latency and cost given the throughput constraints. Particularly while maintaining adequate feature velocity. When I worked in such shops cost was a constant conversation during development ( for good reason ) and that conversation didn't come up nearly as often in the statically typed shops. Everyone thought they were more productive in Ruby/Python at the time. The gap between python and java is a lot bigger than java and C though, and I wouldn't be surprised if the latter optimization doesn't become worth it for a while longer.

lumost 6y ago

I think the optimal point is more ambiguous in the industry than we normally think. In the earlier part of the teens SaaS businesses in high throughput (>1k TPS) fields such as ad-tech were often created with ruby/python and related languages. From my observation these businesses hit significant friction managing costs as they scaled relative to peer companies using Java/C stacks. While it was possible to build a competing product on latency, it wasn't generally feasible to build a competing product on latency and cost given the throughput constraints. Particularly while maintaining adequate feature velocity. When I worked in such shops cost was a constant conversation during development ( for good reason ) and that conversation didn't come up nearly as often in the statically typed shops. Everyone thought they were more productive in Ruby/Python at the time. The gap between python and java is a lot bigger than java and C though, and I wouldn't be surprised if the latter optimization doesn't become worth it for a while longer.