4 ms·
I stopped after reading "reason for panic?" paragraph. Basically, if you don't like the tool or you are not too comfortable with it, don't use it. If you want t
by elcct 11y ago
I stopped after reading "reason for panic?" paragraph. Basically, if you don't like the tool or you are not too comfortable with it, don't use it. If you want to pass arbitrary stuff through a channel you can for example serialize to JSON or even use things like protobuf if you are religious about memory. If you really want to send something random, then there is something wrong with your project.
- drdaeman 11y agoIsn't very similar attitude "oh, why bother with checks, I'll never do anything wrong with those" is a case of most segfaults in C programs?
- mikelward 11y agoDid you not understand the func merge[T](cs ...<-chan T) <-chan T reference? The author doesn't want to send something random, they want to send things of a single type, where the type is defined at compile time, without re-writing functions like 'merge'.
- elcct 11y agoI think I was not clear - I mean essentially what you replied. I think this is still a try to apply mindset of one thing to another. You can't do generics in Go (well, you can use template system if you really want), so why would you try to solve the problems with generics in mind? It is like you were really upset that getting family in an industrial truck to Disneyland is not comfortable. If you have a problem that requires generics, use something else than Go.
- arnarbi 11y agoThe kind of channels* the article talks about are not delivery mechanisms, but primarily a synchronization primitive. They have little to do with serialization, and indeed "sending" references to data without having to encode them is critical in many cases. Besides, serializing data throws away type safety just as much as a catch-all type (in go, interface{}) does. * The naming "channel" is old: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce...