3 ms·
Never say "shared state" and "threading" in the same sentence. If anything, all languages need to move to an Erlang shared-nothing model. But, Erlang was doin
by seiji 11y ago
Never say "shared state" and "threading" in the same sentence.
If anything, all languages need to move to an Erlang shared-nothing model. But, Erlang was doing all this back in the 80s, so people have to re-invent it worse in the 2010s to feel special. You can't just go around using things other people made (OPC—other people's code) that just work, you have to make it your own and start your own conferences and books and webinars and vine instaslacks.
Erlang is also preemptive (bumping reductions) so your "long running computation spinning on a thread" problem goes away too. Though, we can't say "goes away"—sounds too much like Go—how about it "erlangs away" the problem?
Decent write up on erlang scheduling at http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html?view=classic http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...
Also see decent writeup about shared-nothing at http://jlouisramblings.blogspot.com/2013/10/embrace-copying.html?view=classic http://jlouisramblings.blogspot.com/2013/10/embrace-copying....
Erlang also has per-process (green thread) heap/GC (i.e. no 'stop the world' required), full load balancing over your CPUs, unbelievably useful pattern matching, atoms/symbols, full serialization of all native data types, built with network distribution in mind from the ground up, plus a syntax that doesn't look like somebody woke up from the 70s in 2010 and decided to write a new language just like their old favorite language. Any knocks against Erlang syntax is because it stands on the shoulders of giants, not because somebody made it in 2010 and ignored all programming language and usability research from the past 40 years.
- jsprogrammer 11y agoAny benchmarks comparing Erlang, Go, C, Node performance for network applications (eg. max # connections, max requests/s, request latency, etc) that you can point to?
- seiji 11y agoBenchmarks 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 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?)
- jsprogrammer 11y ago>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.
- mike_ivanov 11y ago> 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.
- jsprogrammer 11y agoI 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.