> > * 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.
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.
> 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.