I wrote a bunch of go code this morning. It's definitely got a few really neat ideas in it.
I tend to write erlang or c++ mostly for my day job. I do really wish the designers had a bit more erlang experience. Just a touch. Just enough so that I had a way to propagate the death of a goroutine through a bunch of other goroutines without building all of that manually.
That infinite loop is really infinite. If the goroutine feeding the channel dies (e.g. if the connection is dropped), this thing will keep reading on the channel. In erlango, I'd do something like "go_link client.Feed(ch)" and the right thing would happen. Here, I really need to spin up a second channel to send out the death spurt, select across the channels in my loop and send my death message with defer.
defer is awesome, and I wish every language had it (C++ has something that looks like it if you write enough code and squint hard enough). Still, I've got a lot of code like the above and I imagine it's not an uncommon thing.
Every language has something that just feels unjustifiably wrong with it, though. go certainly isn't one I'd be pained to use if I had to every day.
(Edit: couldn't figure out code formatting, tossed it over to pastebin)
If you modify your for loop to range over ch, you can make the sending side close(ch) when an error occurs, and then the loop will end and the receiver can shut itself down.
Throwing in a "defer close(ch)" and that range thing did exactly the right thing. I'm not sure my API is right, but I know how to get it right now. Thanks a lot.
> I do really wish the designers had a bit more erlang experience.
I feel the same way. I had this hope that this would be what I would learn instead of Erlang. You know it has goroutines and channels -- kind of like processes and casts. Well except that it is not the same. Erlang's processes that have explicit pids and messages are cast to those processes by referring to their pid, make a lot more sense to me than a bunch of channels. Maybe it is just me, but I really just prefer the Erlang way. (Is the the "actor" vs "CSP" paradigms?).
Then it is what you mentioned, exit signals. Anyone who wants to promote concurrency as first order feature in the language and expects it to be useful in the real world, would have to have something like supervision trees & OTP. In other words when you have lots of little goroutines doing stuff concurrently, it is expected some will just crash and then you'd want to do something reasonable, which is not always to just crash the whole application (OS process).
I tend to write erlang or c++ mostly for my day job. I do really wish the designers had a bit more erlang experience. Just a touch. Just enough so that I had a way to propagate the death of a goroutine through a bunch of other goroutines without building all of that manually.
For example, code I wrote today:
http://pastebin.com/Zp6eqqTa
That infinite loop is really infinite. If the goroutine feeding the channel dies (e.g. if the connection is dropped), this thing will keep reading on the channel. In erlango, I'd do something like "go_link client.Feed(ch)" and the right thing would happen. Here, I really need to spin up a second channel to send out the death spurt, select across the channels in my loop and send my death message with defer.
defer is awesome, and I wish every language had it (C++ has something that looks like it if you write enough code and squint hard enough). Still, I've got a lot of code like the above and I imagine it's not an uncommon thing.
Every language has something that just feels unjustifiably wrong with it, though. go certainly isn't one I'd be pained to use if I had to every day.
(Edit: couldn't figure out code formatting, tossed it over to pastebin)