3 ms·

What you lose in execution time you generally gain in development.

goldenkey 5y ago
> "What you lose in apples you gain in oranges" I didn't know different units could be compared as if they had an equivalence ratio...
- vorticalbox 5y ago
  languages like python usually have shorter time to market at the cost of it running slower. So sure they can't be directly compared but that doesn't mean that one cannot effect the other.
  - mioasndo 5y ago
    > languages like python usually have shorter time to market at the cost of it running slower. Let's see the data on that. Then let's see the cost of maintenance vs Java.
- michaelcampbell 5y ago
  This feels like it is said in bad faith because I suspect you know exactly what is meant. If you really want to be pedantic, 1_000_000 user operations are to be done. If you write something that does 1_000_000 user operations/second, and it takes 6 mos to write, it'll be done in 6 mos and 1 sec. If it only does 500 ops/sec but takes 1 day to write, it'll be done in ~3.3 days. Which one is faster?
  - sitkack 5y ago
    Whole system optimization is the key. One can't optimize in isolation. Will it run once? What are the inputs? How much memory will it take? How important is the result? Now we are in the regime where parallelism and memory bandwidth efficiency is more important than constant factors of speed increase. 1k, 10k or 100k cores will be commonplace, even with slow interpreted code, the code the scales to more cores faster will win, even against C++. We already have more cores than we know what to do with.
    - mioasndo 5y ago
      You're ignoring the cost of running the code, latency, and the many overheads and potholes of horizontal scaling. There's a reason large codebases are being rewritten from python, ruby, php to java, go, rust.
      - sitkack 5y ago
        Those large codebases are being rewritten in languages that support large dev teams and the tooling that static type systems can support. Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be. Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput.
        mioasndo 5y ago
        > Those large codebases are being rewritten in languages that support large dev teams and the tooling that static type systems can support. Of course that's one of the reasons, and that goes directly against the notion that python and ruby are somehow cheaper or more efficient to develop in. > Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be. The point is horizontal and vertical scaling don't automatically resolve the drawbacks of slow code. Using 10x the resources to make up for slow code is generally not a solution if performance actually matters. > Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput. Not sure what you're trying to argue here. Yes 'dynamic' languages are slower, yes you can vertically and horizontally scale both. I don't see how that's relevant for a comparison of languages.
mioasndo 5y ago
> ruby > doubt

> "What you lose in apples you gain in oranges" I didn't know different units could be compared as if they had an equivalence ratio...

vorticalbox 5y ago
languages like python usually have shorter time to market at the cost of it running slower. So sure they can't be directly compared but that doesn't mean that one cannot effect the other.
- mioasndo 5y ago
  > languages like python usually have shorter time to market at the cost of it running slower. Let's see the data on that. Then let's see the cost of maintenance vs Java.
michaelcampbell 5y ago
This feels like it is said in bad faith because I suspect you know exactly what is meant. If you really want to be pedantic, 1_000_000 user operations are to be done. If you write something that does 1_000_000 user operations/second, and it takes 6 mos to write, it'll be done in 6 mos and 1 sec. If it only does 500 ops/sec but takes 1 day to write, it'll be done in ~3.3 days. Which one is faster?
- sitkack 5y ago
  Whole system optimization is the key. One can't optimize in isolation. Will it run once? What are the inputs? How much memory will it take? How important is the result? Now we are in the regime where parallelism and memory bandwidth efficiency is more important than constant factors of speed increase. 1k, 10k or 100k cores will be commonplace, even with slow interpreted code, the code the scales to more cores faster will win, even against C++. We already have more cores than we know what to do with.
  - mioasndo 5y ago
    You're ignoring the cost of running the code, latency, and the many overheads and potholes of horizontal scaling. There's a reason large codebases are being rewritten from python, ruby, php to java, go, rust.
    - sitkack 5y ago
      Those large codebases are being rewritten in languages that support large dev teams and the tooling that static type systems can support. Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be. Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput.
      - mioasndo 5y ago
        > Those large codebases are being rewritten in languages that support large dev teams and the tooling that static type systems can support. Of course that's one of the reasons, and that goes directly against the notion that python and ruby are somehow cheaper or more efficient to develop in. > Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be. The point is horizontal and vertical scaling don't automatically resolve the drawbacks of slow code. Using 10x the resources to make up for slow code is generally not a solution if performance actually matters. > Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput. Not sure what you're trying to argue here. Yes 'dynamic' languages are slower, yes you can vertically and horizontally scale both. I don't see how that's relevant for a comparison of languages.

mioasndo 5y ago

> ruby > doubt