6 ms·

So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, dis

So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, distributed network applications. Which makes Go's rapid popularity as a language for solving the same problem even more peculiar. Especially since Go's surrounding tracing, debugging, and online code swapping facilities are so much worse. I'm sure some component of that is Ericsson's complete lack of interest in evangelism and Erlang Solution's apparent lack of capability to effectively evangelize, but it still seems like Go isn't so much filling a void as it is being better at attracting an ecosystem that delights in reinventing a particular set of wheels. Java was very much the same way for a very long time.

mahyarm 10y ago
Golang is simpler java, and that is it's target. It even has the same perf profile as java. Erlang does have a worse perf profile.
- im_down_w_otp 10y ago
  Yes Erlang does, strictly for execution throughput, but less so for concurrency handling. That is also a solveable problem. It just so happens to be a problem neither Ericsson nor ESL have been interested in solving.
  - bostik 10y ago
    Remember, Erlang was first and foremost developed as a programming language (and runtime) to run Ericsson's phone switches. Session establishment for PSTN can be relatively expensive (much in the way of TLS handshakes), so concurrency and shared-nothing memory model together allowed for real-time streaming to keep on working no matter what else happened. The three main features of a PSTN switch are, after all: 1. Reliable call switching 2. Reliable real-time throughput 3. Reliable billing and accounting data generation We don't think much of throughput these days, when any home office switch has gigabit ports and 40Gb+ backplane. As far as I know, maximising throughput bandwidth was not a primary consideration with Erlang. Reliable real-time streaming is much more about guaranteed latency - and incidentally, optimising between latency and throughput tends to be all about tradeoffs.
- fpoling 10y ago
  Golang performance profile is very different from Java. It's speed is closer to C++, garbage collection optimized for latency, not bandwidth, very low startup time comparable with typical native code.
  - Jweb_Guru 10y ago
    You can actually get a performance profile very much like Go's out of Java... * Inasmuch as you can make a blanket statement like this about a language, Go's speed is very much comparable to Java's. * Java has a huge number of garbage collectors available. You're just talking about the default, but there are extremely low-latency GCs. * Java has a bunch of ahead-of-time compilers; thanks to Android this might be the most common deployment of Java. Even green threads were tried (and sensibly abandoned) in Java before. I think people may not be aware of all the options available in the Java ecosystem, but other than sized types, which are theoretically coming to Java 10, there isn't much performance-wise that Go does and Java doesn't.
  - mahyarm 10y ago
    Just because a language is compiled doesn't mean it will approach C++ speeds. The GC itself is a hard limit on perf. What I've seen in practice: 1x time: C 1.5x time: C++ (with smart pointers) ~2x time: Objective-C (almost everything is a heap smart pointer) 3x time: Java, Golang (optimized GC languages)
doktrin 10y ago
> So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, distributed network applications. I'm probably outing myself as the lord regent of all impostor plebs, but Erlang is not IMO an approachable language regardless of its origins. Put differently : it looks completely nuts. I'm sure there's a method to the madness, but comparing it to Golang feels misguided (at least, from the perspective of awful programmers like myself)
- im_down_w_otp 10y ago
  Erlang is a very simple language. It doesn't look like C, but it has a very basic syntax and a narrow set of core constructs. Elixir by comparison is significantly more complicated, but the fact that it looks tacitly like Ruby is apparently very attractive. I suspect I could sit down with you for an hour and remove all the weirdest seeming bits which feel alien. Such that the rest of it would just feel like any other programming language, and you'd be able to immediately start dissecting and understanding other people's code. Part of the problem with Erlang (again an evangelism problem) is that there's not much in the way of attractive and we'll structured on-boarding documentation. It's mostly really simple. It's just that the Erlang docs seem to go to great lengths to obfuscate that fact. In large part because they don't do anything to intentionally build "background schema" with the reader by drawing comparisons to similar things they're probably already familiar with in other ecosystems.
  - sanderjd 10y ago
    I don't think looking like Ruby is at all what makes people like Elixir. Maybe it has attracted a bunch of people to look at it because of that, but I don't think that's why anyone stays (because anyone who cares about that quickly realizes that it isn't actually very much like Ruby at all). I agree that it's a more complex language (though I wouldn't say "significantly", but that's very subjective), but it doesn't really "feel" that way to me because its design choices seem more consistent. But on top of that, it has really good tooling, which I always found to be a major pain point in getting started with Erlang.
  - 10y ago

mahyarm 10y ago

Golang is simpler java, and that is it's target. It even has the same perf profile as java. Erlang does have a worse perf profile.

im_down_w_otp 10y ago
Yes Erlang does, strictly for execution throughput, but less so for concurrency handling. That is also a solveable problem. It just so happens to be a problem neither Ericsson nor ESL have been interested in solving.
- bostik 10y ago
  Remember, Erlang was first and foremost developed as a programming language (and runtime) to run Ericsson's phone switches. Session establishment for PSTN can be relatively expensive (much in the way of TLS handshakes), so concurrency and shared-nothing memory model together allowed for real-time streaming to keep on working no matter what else happened. The three main features of a PSTN switch are, after all: 1. Reliable call switching 2. Reliable real-time throughput 3. Reliable billing and accounting data generation We don't think much of throughput these days, when any home office switch has gigabit ports and 40Gb+ backplane. As far as I know, maximising throughput bandwidth was not a primary consideration with Erlang. Reliable real-time streaming is much more about guaranteed latency - and incidentally, optimising between latency and throughput tends to be all about tradeoffs.
fpoling 10y ago
Golang performance profile is very different from Java. It's speed is closer to C++, garbage collection optimized for latency, not bandwidth, very low startup time comparable with typical native code.
- Jweb_Guru 10y ago
  You can actually get a performance profile very much like Go's out of Java... * Inasmuch as you can make a blanket statement like this about a language, Go's speed is very much comparable to Java's. * Java has a huge number of garbage collectors available. You're just talking about the default, but there are extremely low-latency GCs. * Java has a bunch of ahead-of-time compilers; thanks to Android this might be the most common deployment of Java. Even green threads were tried (and sensibly abandoned) in Java before. I think people may not be aware of all the options available in the Java ecosystem, but other than sized types, which are theoretically coming to Java 10, there isn't much performance-wise that Go does and Java doesn't.
- mahyarm 10y ago
  Just because a language is compiled doesn't mean it will approach C++ speeds. The GC itself is a hard limit on perf. What I've seen in practice: 1x time: C 1.5x time: C++ (with smart pointers) ~2x time: Objective-C (almost everything is a heap smart pointer) 3x time: Java, Golang (optimized GC languages)

doktrin 10y ago

> So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, distributed network applications. I'm probably outing myself as the lord regent of all impostor plebs, but Erlang is not IMO an approachable language regardless of its origins. Put differently : it looks completely nuts. I'm sure there's a method to the madness, but comparing it to Golang feels misguided (at least, from the perspective of awful programmers like myself)

im_down_w_otp 10y ago
Erlang is a very simple language. It doesn't look like C, but it has a very basic syntax and a narrow set of core constructs. Elixir by comparison is significantly more complicated, but the fact that it looks tacitly like Ruby is apparently very attractive. I suspect I could sit down with you for an hour and remove all the weirdest seeming bits which feel alien. Such that the rest of it would just feel like any other programming language, and you'd be able to immediately start dissecting and understanding other people's code. Part of the problem with Erlang (again an evangelism problem) is that there's not much in the way of attractive and we'll structured on-boarding documentation. It's mostly really simple. It's just that the Erlang docs seem to go to great lengths to obfuscate that fact. In large part because they don't do anything to intentionally build "background schema" with the reader by drawing comparisons to similar things they're probably already familiar with in other ecosystems.
- sanderjd 10y ago
  I don't think looking like Ruby is at all what makes people like Elixir. Maybe it has attracted a bunch of people to look at it because of that, but I don't think that's why anyone stays (because anyone who cares about that quickly realizes that it isn't actually very much like Ruby at all). I agree that it's a more complex language (though I wouldn't say "significantly", but that's very subjective), but it doesn't really "feel" that way to me because its design choices seem more consistent. But on top of that, it has really good tooling, which I always found to be a major pain point in getting started with Erlang.
- 10y ago