Benchmarks are interesting these days. Software can generally be made "fast enough," but there's no benchmark for maintainability or ease of coding.
What good is a Java program being 2x as fast as a Python program if the Java program requires 3,000 lines and two weeks to write while the Python program requires 300 lines and two days?
The idea for Go is "become the new Java but without that startup time penalty." The goal of Java was to be a "dumb enough" language where individual talent or skill or knowledge doesn't matter. So, you get a language not targeted at expressiveness or ease of thought or ease of programming, but at ease of using people as interchangeable cogs in a multi-billion dollar software development machine. Not really exciting to be a part of.
We've come full circle back to Averages (http://www.paulgraham.com/avg.html) — startups not using Go will fare much better than encumbered startups just due to the brain rot you're required to experience while using Go itself. (I mean, TABS? In 2015? Non-versioned web-placed dependencies? What is wrong with these people?)
>What good is a Java program being 2x as fast as a Python program if the Java program requires 3,000 lines and two weeks to write while the Python program requires 300 lines and two days?
I will stop you right there.
If there is a 2x difference it very well might be worth it to me if that means I only have to run half the machines I would with the slower solution. Run-time costs can dominate all other concerns for some problems.
Specifically, I am looking for Erlang vs. other (ie. C, Go, Node) performance commentary.
> If there is a 2x difference .. I only have to run half the machines
No, it doesn't work that way. CPU is almost never an issue, it's all about startup time, network latency -- that kind of stuff. So, unless you're mining bitcoins, 2x difference is negligible.
I guess I don't understand where Erlang would fit in your (my) stack.
If you want to handle millions->billions of external client connections, you may want to be able to pack as many on to a machine as possible to reduce costs (the difference between paying for 5,000 machines vs 10,000 machines). If you want these to be secure connections (which I do), there is significant CPU overhead in encrypting and decrypting all network traffic. Even if you aren't doing encryption work, there is still significant CPU work in managing large numbers of sockets. Implementations may also vary significantly in the amount of memory required to support the connection, affecting costs and machine count.
What good is a Java program being 2x as fast as a Python program if the Java program requires 3,000 lines and two weeks to write while the Python program requires 300 lines and two days?
The idea for Go is "become the new Java but without that startup time penalty." The goal of Java was to be a "dumb enough" language where individual talent or skill or knowledge doesn't matter. So, you get a language not targeted at expressiveness or ease of thought or ease of programming, but at ease of using people as interchangeable cogs in a multi-billion dollar software development machine. Not really exciting to be a part of.
We've come full circle back to Averages (http://www.paulgraham.com/avg.html) — startups not using Go will fare much better than encumbered startups just due to the brain rot you're required to experience while using Go itself. (I mean, TABS? In 2015? Non-versioned web-placed dependencies? What is wrong with these people?)