4 ms·

> Golang has a more conventional, familiar, boring, "safe" language design than Erlang does. Do you mean "safe" as in "nobody got fired for buying IBM" or as i

> Golang has a more conventional, familiar, boring, "safe" language design than Erlang does. Do you mean "safe" as in "nobody got fired for buying IBM" or as in language making hard to start thermonuclear war by accident? Because Erlang, with it's immutability everywhere is as safe as, or safer than Go. > Golang has a more flexible concurrency offering than Erlang. Basically everything you wrote here Erlang has. And what they were porting was in Python + GEvent, which means no threads anyway. > a clearly delineated "just a bag of bytes" type designed from scratch for high-performance buffering Erlang's binaries and strings (two different types) are designed for the same thing. > but it might be tricky to argue that Erlang's process model is better than Golang's Well, Go did a nice job borrowing Erlang's solution here. As it origins from Erlang, it has to be good. ;) > Erlang requires an installed runtime and executes in a VM. Golang produces native binaries. Erlang is able to produce a single binary. That it contains a VM and libraries and user code is another matter, but rsyncing Erlang binaries is also possible. > Golang has modern, extremely high-quality tooling. Dialyzer, EDoc, various process viewers, debuggers and so on for Erlang are really mature. I think that familiarity of syntax, familiar programming paradigm and raw (single threaded, number crunching) speed were the reasons. Go has many benefits over Erlang in the realm of marketing, but I don't believe Erlang is much worse a language because of it.

tptacek 13y ago
I meant "safe" in the "nobody got fired for buying IBM" sense. My sense of it is that from now until the heat death of the universe, Golang developers will say that language is safer because of its type system, and Erland developers will say that language is safer because of share-nothing and immutability. I think both languages are safer than Python. But then, you cannot have it both ways. Either Erlang is "safer" because of share-nothing and immutability, or Golang is more flexible w/r/t concurrency. I can design a shared concurrent data structure in Golang that is protected by locks or atomic counters, and I can do that easily, using the native first-class facilities of the language. Can two Erlang processes cooperate using a single shared buffer with a custom-designed concurrency scheme? Is that a natural thing to express in Erlang? It's a natural thing to express in Golang. I feel like you didn't really engage with the string processing point I made. I feel like it doesn't help an Erlang advocate's point too much to observe that Golang stole the best parts of Erlang. I feel like every time it is ever pointed out in any language comparison that Golang can produce runnable native binaries, someone always has some rube-goldbergian alternative that nobody in the real world ever uses to get their own language bootstrapped onto some routine from a single file. I gave specific reasons why Golang's tooling is strong. I feel like I got a response that says "Erlang's tools are mature". Nobody is arguing that Erlang is immature. The argument is that it's geriatric. :) Ultimately, I agree that most of what I think is good about Golang is probably icing on the cake after "the language is boring enough to be familiar to Python programmers".

tptacek 13y ago

I meant "safe" in the "nobody got fired for buying IBM" sense. My sense of it is that from now until the heat death of the universe, Golang developers will say that language is safer because of its type system, and Erland developers will say that language is safer because of share-nothing and immutability. I think both languages are safer than Python. But then, you cannot have it both ways. Either Erlang is "safer" because of share-nothing and immutability, or Golang is more flexible w/r/t concurrency. I can design a shared concurrent data structure in Golang that is protected by locks or atomic counters, and I can do that easily, using the native first-class facilities of the language. Can two Erlang processes cooperate using a single shared buffer with a custom-designed concurrency scheme? Is that a natural thing to express in Erlang? It's a natural thing to express in Golang. I feel like you didn't really engage with the string processing point I made. I feel like it doesn't help an Erlang advocate's point too much to observe that Golang stole the best parts of Erlang. I feel like every time it is ever pointed out in any language comparison that Golang can produce runnable native binaries, someone always has some rube-goldbergian alternative that nobody in the real world ever uses to get their own language bootstrapped onto some routine from a single file. I gave specific reasons why Golang's tooling is strong. I feel like I got a response that says "Erlang's tools are mature". Nobody is arguing that Erlang is immature. The argument is that it's geriatric. :) Ultimately, I agree that most of what I think is good about Golang is probably icing on the cake after "the language is boring enough to be familiar to Python programmers".