3 ms·

Go is my favorite language but: > Go doesn't need a "handle_event/2" because it has channels, and you should use those Of what type? But most importantly, cha

by klabb3 2y ago

Go is my favorite language but: > Go doesn't need a "handle_event/2" because it has channels, and you should use those Of what type? But most importantly, channels are local to the process, so you need glue to make it networked. (I assume erlang has networked message handling abstracted away). In addition I’ve seen 3-4 different variations of your proposed pattern for long-running server like things. I agree fully that porting should make use of idiomatic constructs. But I also think languages can have hidden mechanics that loses the valuable essence while porting – a form of anti-relativism of PLs if you will. It’s entirely possible to me that this ”oh a channel? just wrap it in X” is much more detrimental to interop than what it sounds like. For instance take http.Handler in Go. Similarly simple but what are the real world implications of having it in std? An ecosystem of middleware that is largely compatible with one another, without pre-coordination (a non-std http server X can be used with auth middleware Y and logging middleware Z). Similar things can be said about io.Reader and friends. These extremely simply interfaces are arguably more valuable than the implementations. If, and I’m speculating here, Erlang got many of the interfaces for reliable distributed systems right, that can be what enables the whole.

jerf 2y ago
"Of what type?" Of the type of the messages you're sending. Which can either be an interface for multiple messages, or you can use multiple channels with one type each. I've done both. This is not an important question when actually programming in Go. "But most importantly, channels are local to the process, so you need glue to make it networked." This is an important consideration if you are using Go. Although I would observe that it isn't so much that "channels don't do network" as that "channels are a local tool"; e.g., we do not complain that OS mutexes are not "network capable", because they're intrinsically local. Network locking uses different solutions, and we don't really consider etcd a competitor to a local "lock" call. But there are dozens of message busses in the world now, and Erlang's isn't really all that competitive modulo its integration.

by klabb3 2y ago

jerf 2y ago

"Of what type?" Of the type of the messages you're sending. Which can either be an interface for multiple messages, or you can use multiple channels with one type each. I've done both. This is not an important question when actually programming in Go. "But most importantly, channels are local to the process, so you need glue to make it networked." This is an important consideration if you are using Go. Although I would observe that it isn't so much that "channels don't do network" as that "channels are a local tool"; e.g., we do not complain that OS mutexes are not "network capable", because they're intrinsically local. Network locking uses different solutions, and we don't really consider etcd a competitor to a local "lock" call. But there are dozens of message busses in the world now, and Erlang's isn't really all that competitive modulo its integration.