4 ms·

> * Erlang is a much simpler language Go is widely considered to be a very simple language, often too simple, so I find this claim interesting. > * Despite la

> * Erlang is a much simpler language Go is widely considered to be a very simple language, often too simple, so I find this claim interesting. > * Despite lacking a static type system, Erlang's functional bend, immutability, SSA and pattern matching makes for a rather safe language This is fine stuff, but I would rather have a type system, so this is just making up for a deficiency with some other stuff, so it's really just a sidegrade, not so much an upgrade or a downgrade. > * Erlang has always been fully preempted, it didn't have to wait until 2020 for that to happen With extremely rare exceptions, Go has always been fully preempted from a developer experience point of view. The fact that the underlying implementation was using function calls as yield points simply didn't matter. The fact that it is fully preempted now means it's kind of weird to still hold it against Go that they are doing the same thing as BEAM now. It is done, this is no longer a bullet point. > * Erlang also builds distribution in, though it's "trusted distribution" so probably of fairly limited use at large Go has always "built distribution in" by offering to build single static binaries. If anything, BEAM languages are harder to deploy. > * Erlang uses shared-nothing concurrency, greatly limiting side-effects across processes, which again helps with reliability: there is no action at a distance in sequential erlang, no third-party can come in and mess with your state I agree that immutability is an advantage. In general, third parties can't come in and unexpectedly mess with your state in Go either, as long as you're either maintaining your state local to a function or keeping your global variables private to each package. Keep in mind that Go's package imports must form a tree with no loops. Third party packages literally cannot see your code or any of the exported global variables, since you are importing them, and not the other way around. Go does not offer any way for packages to reflect over the whole program's state in memory, so there's no way for third party packages to go hunting around in memory and playing with your values, which would be stupid, unless they use "unsafe" to start poking at random memory addresses, and I'm certain you can do something equally dumb in Erlang with a sufficient amount of effort. It's just as crazy to think of doing something useful that way in Go as it is in Erlang. > * Erlang builds reliability into the language and runtime through concepts of liking, supervision, … This is literally the only compelling talking point I've seen for Erlang/BEAM vs Go. However, I've written large Go applications with distinct services running within the same binary, and it is possible to make extremely reliable systems. Go's context package allows you to build trees of processes that you want to be able to cancel, including cancelling specific sub-trees without affecting adjacent trees or parent trees. The single biggest footgun with building reliable systems in Go is that it prefers to crash early. So, every Goroutine that you launch, you must make sure that the first thing it does is catch any panics to avoid taking down the entire program, including unrelated Goroutines. When correctly written, a human will be immediately alerted to the bug that caused this panic (which shouldn't ever happen anyways), and the program will continue operating normally in the mean time until a human gets a chance to push out an update to fix that bug. In practice, enforcing just one rule (Goroutines must catch panics) in code reviews is not that hard, and it isn't common in my experience for most code to arbitrarily launch Goroutines -- Goroutines should be managed. In return, Go offers much better performance than BEAM, as well as most of the practical benefits of BEAM that I've seen discussed online. I think Rust is a better language than either Go or any BEAM language, but the absence of a preemptive concurrency model like Go and Erlang offer just makes it hard for me to enjoy the prospect of using Rust for general purpose network services. Once Go adds generics in the next year-ish, that should solve my biggest real annoyances with the language. I really look forward to being able to package up a number of the concurrent patterns I write into reusable packages, which will largely eliminate once and for all the need for me manually spin up a new Goroutine in the code that I'm writing and potentially forget to catch any panics.

Jtsummers 6y ago
> > * Erlang also builds distribution in, though it's "trusted distribution" so probably of fairly limited use at large > Go has always "built distribution in" by offering to build single static binaries. If anything, BEAM languages are harder to deploy. I suspect GP meant distribution in the distributed computing sense, not the deployment sense. What, baked into Go not via a library, handles multiple Go programs communicating within the same physical node or across multiple physical nodes? Erlang gives you the same communication method whether distributed or within a single node, Go does not (that is, Go channels are internal to a specific program, they cannot be referenced from different programs or computers). If they did mean it in the deployment sense, I'd still argue it's a point in favor of Erlang. Two nodes communicating can execute code on the other.
- coder543 6y ago
  Yes, I definitely misunderstood the point being made there. > What, baked into Go not via a library, handles multiple Go programs communicating within the same physical node or across multiple physical nodes? Go does have an RPC package built into the standard library, for what it's worth, but I know it's not the same thing as the runtime transparently stitching distributed machines together under the hood.
masklinn 6y ago
> This is fine stuff, but I would rather have a type system, so this is just making up for a deficiency with some other stuff, so it's really just a sidegrade, not so much an upgrade or a downgrade. Sure, I'm just saying the lack of a type system in erlang is not quite as bad as, say, in javascript. > Go has always "built distribution in" by offering to build single static binaries. If anything, BEAM languages are harder to deploy. Distribution in the sense of distributed computing, not in the sense of giving somebody else binaries to run. That is not something erlang is good at. But you can rather easily join nodes together and not just have them communicate but have them leverage one another e.g. spawn processes on an other node in the cluster. > I agree that immutability is an advantage. Immutability and isolation are different things, though Erlang has both. > In general, third parties can't come in and unexpectedly mess with your state in Go either, as long as you're either maintaining your state local to a function or keeping your global variables private to each package. Go is a shared-memory concurrency language, with no restrictions on the sharing.

Jtsummers 6y ago

> > * Erlang also builds distribution in, though it's "trusted distribution" so probably of fairly limited use at large > Go has always "built distribution in" by offering to build single static binaries. If anything, BEAM languages are harder to deploy. I suspect GP meant distribution in the distributed computing sense, not the deployment sense. What, baked into Go not via a library, handles multiple Go programs communicating within the same physical node or across multiple physical nodes? Erlang gives you the same communication method whether distributed or within a single node, Go does not (that is, Go channels are internal to a specific program, they cannot be referenced from different programs or computers). If they did mean it in the deployment sense, I'd still argue it's a point in favor of Erlang. Two nodes communicating can execute code on the other.

coder543 6y ago
Yes, I definitely misunderstood the point being made there. > What, baked into Go not via a library, handles multiple Go programs communicating within the same physical node or across multiple physical nodes? Go does have an RPC package built into the standard library, for what it's worth, but I know it's not the same thing as the runtime transparently stitching distributed machines together under the hood.

masklinn 6y ago

> This is fine stuff, but I would rather have a type system, so this is just making up for a deficiency with some other stuff, so it's really just a sidegrade, not so much an upgrade or a downgrade. Sure, I'm just saying the lack of a type system in erlang is not quite as bad as, say, in javascript. > Go has always "built distribution in" by offering to build single static binaries. If anything, BEAM languages are harder to deploy. Distribution in the sense of distributed computing, not in the sense of giving somebody else binaries to run. That is not something erlang is good at. But you can rather easily join nodes together and not just have them communicate but have them leverage one another e.g. spawn processes on an other node in the cluster. > I agree that immutability is an advantage. Immutability and isolation are different things, though Erlang has both. > In general, third parties can't come in and unexpectedly mess with your state in Go either, as long as you're either maintaining your state local to a function or keeping your global variables private to each package. Go is a shared-memory concurrency language, with no restrictions on the sharing.