[rdtsc]

> but this article just shows that you don't even have to try hard to create a biased comparison.

So, let's see you detailed unbiased analysis...

> * Go is fast. Erlang isn't.

Hmm. Given that you accused the author of making biased comparisons, I would expect some more detailed information there. "Faster" doing what? Assembly is faster, Go isn't. Ok, let's use assembly then.

> * Go has a non-surprising, mainstream syntax. You can pick it up in hours. Erlang - not so much.

I think Erlang syntax is small and self consistent. If ; and . are the biggest stumbling blocks to learning a new system. Ok, maybe Erlang is not for you.

> Go is good at strings. Erlang - not so much

Erlang is very good at binaries. It can even do pattern matching on them. Decoding an IPv4 packet is 2 or 3 lines of code only.

> Go has the obvious data structures: structs and hash tables. Erlang - no.

Erlang has obvious data structures -- maps, lists and tuples?

> * Go has shared memory. Yes, that's a feature. It allows things to go fast. Purity of not sharing state between threads sounds good in theory until you need concurrency

Quite the opposite. You can get easy concurrency if you don't share thing between concurrency contexts. You also get low latency response and non-blocking behavior.

Erlang shares binary objects above a certain size behind the scenes as well so those don't get copied during message passing.

It also has Mnesia, a built-in distributed database. It is used heavily by WhatsApp to share data between primary and back-up instances of processes running on different machines.

> You just have to overlook ugly syntax, lack of string type, lack of structs, lack of hash tables, slow execution time. Other than those fundamental things, Erlang is great.

Ok it looks like we only have to overlook syntax. Sound good to me then, I can handle . instead of ; and I will also learn and use Go because both are very cool and interesting tools.

[shurcooL]

> Assembly is faster, Go isn't. Ok, let's use assembly then.

That's pretty flawed logic. It can be used to dismiss any valid statement. "B is better than A at property C." "Z is better than B at property C; let's ignore the valid A vs B comparison."

What matters is how much better something is at a given property, how valuable that property is (to you/your tasks), and what the cost that improvement is - in the context of the big picture.

I like and use Go not because of any single aspect, but because I enjoy the entire package. It has some good parts and some weak parts (e.g., I wish the `go build import/path` command would be consistent in generating/not generating output in cwd regardless whether the target package is a command or library - that way it could be reliably used to test if a package builds without potentially generating files in cwd).

[rdtsc]

> That's pretty flawed logic.

Exactly. I was replying to his message and mocking his way of conduction a conversation. That should be viewed with that in mind.

> "B is better than A at property C." "Z is better than B at property C; let's ignore the valid A vs B comparison."

Yes. I think you probably want to direct that at gp post, not my post ;-) You also probably want to use different capitalization for properties than to entities (or at least letters from the other end of the alphabet), like say B is better than A at property x

> I like and use Go not because of any single aspect, but because I enjoy the entire package

Yeah Go is great I like it too!

[coldtea]

>That's pretty flawed logic.

To show that it was "flawed logic" was the whole purpose of his remark.

[rvirding]

Yes, it is flawed logic, but you were using so I don't see why you should object to it. And his goal was to show that.

[chaotic-good]

> Hmm. Given that you accused the author of making biased comparisons, I would expect some more detailed information there. "Faster" doing what? Assembly is faster, Go isn't. Ok, let's use assembly then.

This makes big difference. With pure Go I can do computation heavy things, for example - I've implement some information retrieval methods in Go (indexes, stemmers, ranking and so on). I can't do the same in Erlang, because my map based inverted index, written in Erlang will be to inefficient. I can write it in C, but in my case - most of the application complexity is located in this information retrieval part. Because of that, efficiency is a big deal for me.

[seanmcdirmid]

> You can get easy concurrency if you don't share thing between concurrency contexts.

We typically don't call that concurrency. Some resource has to be under contention, otherwise its just plain-old parallelism. In Erlang, you have to ship everything to everyone, but the resources are still technically shared...just very inefficiently.

[rdtsc]

I say you do.

Concurrency is a property of algorithm. Parallelism is a property of the running environment. The hope is given that you have large amount of concurrency, that concurrency would be reasonably and easily distributed over parallel execution units (CPU, sockets+select loops, goroutines, tasks, processes, separate machines, VMs etc...).

So if you have concurrency in your problem domain/algorithm ( say web page requests for example ), and, your language has reasonable ways to handle it. Abstractions like processes, tasks, etc, you can make each request spawn an isolated, lightweight Erlang process (it takes just microseconds and only a few Ks of memory). Then finally at runtime, if you have a multi-core machine or started your Erlang VM with a good number of async IO threads, there is a good chance that you'll get good parallelism too! But if you only run that bytecode on a single core machine, you might not get parallelism but concurrency will still be there.

> Some resource has to be under contention,

Why? That is just resource contention. You don't want resource contention if you can avoid it. Think of concurrent as independent units of executions.

> In Erlang, you have to ship everything to everyone, but the resources are still technically shared...just very inefficiently.

Because it keeps things (including faults, but also logical decomposition) simple. Also it maps well to real life. You have to send messages to other people, emails, phone, image. You don't directly plug a shared network back-plane into their brain. So when that crashes the whole group dies. You want to send a message to them and then continue minding your own business.

[seanmcdirmid]

Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other (stolen from wiki). Here simultaneous could mean interleaved (multi-threading on a single core) or at the same time, but the interacting with each other part is key. They have to communicate, they have to communicate what they know about the world, what they know can change...they necessarily share state whether explicit or not.

Parallelism is is actually doing stuff at the same time, usually for a performance benefit, in which case, you aren't going to be using any of these slow FP languages anyways (but there is always Java + MapReduce, which is kind of functional). Your Erlang code will run "faster" relative to single core Erlang code, but if you honestly believe that you are being parallel fast...

> Because it keeps things (including faults, but also logical decomposition) simple. Also it maps well to real life. You have to send messages to other people, emails, phone, image. You don't directly plug a shared network back-plane into their brain. So when that crashes the whole group dies. You want to send a message to them and then continue minding your own business.

I get it: back in the old days before cell phones and screen sharing, we'd have to use carrier pigeons to send messages to each other, so we just sent messages out and minded our own business. But somewhere down the line, we gained the ability to interact in real time via language, looking at and modifying the same stuff even (I think this happened 50,000 years ago or so). We've never been able to recover from these impure interactions.

[stcredzero]

Parallelism is is actually doing stuff at the same time, usually for a performance benefit, in which case, you aren't going to be using any of these slow FP languages anyways (but there is always Java + MapReduce, which is kind of functional). Your Erlang code will run "faster" relative to single core Erlang code, but if you honestly believe that you are being parallel fast...

Erlang's shared nothing architecture is wonderful for avoiding cache misses. (False Sharing) That's a big stumbling block for good parallelism on today's multicore machines. Also, each process having it's own GC helps even more, and GC is an even bigger problem. Go also makes less use of GC than other langs.

[orbifold]

You are aware that Erlang was invented to route telephone calls, which maps very well to message passing concurrency? Erlang is after all not a pure functional programming language.

[rdtsc]

> and potentially interacting with each other (stolen from wiki). [...] but the interacting with each other part is key.

Sorry don't see it. It seems you took something that was optional and turned into "key". It is not key. potentially means they can interact but they don't have to.

It seems you conveniently misinterpreted the definition from wikipedia to fit your idea of what concurrency and parallelism is.

[orbifold]

Erlang does not specify how the message passing semantics is achieved, in principle it could be implemented with shared memory. But then it is hard to garbage collect processes independently, take Haskell as an example. It uses shared memory concurrency (STM) and the garbage collector thread has to stop the world to collect. Message passing also allows to transparently distribute the system over several nodes.