3 ms·
I picked Go not because it's my dream tool (not having 'map' is kind of sad) but because it's proof that you can have your cake and eat it too. Otherwise, peopl
by erjiang 12y ago
I picked Go not because it's my dream tool (not having 'map' is kind of sad) but because it's proof that you can have your cake and eat it too. Otherwise, people think that you have to choose between programming sanely and high-performance, but not both.
- hardwaresofton 12y agoYes, I agree -- but Go's got it's own warts. I think they picked up that (err,result) common function signature from node (or they just thought of it themselves, either way). However, I think once you start trying to manage go routines and all their channels, and all the messages that are flying around, go will start looking less utopian. Of course, a lot of that is subject to code architecture (well architected code will be easy to follow), but I feel like no one's found enough of the dark corners of go yet. Oh one thing I wanted to mention - Why didn't you include any samples of go routines in your code? Unless I am misunderstanding go immensely, a statement like "(task3(task2(task1()))" wouldn't actually be asynchronous, you would need to spawn dependent go routines right, and wait on completion on the channels?
- danudey 12y ago> a statement like "(task3(task2(task1()))" wouldn't actually be asynchronous Correct, because you're passing the result of task1() into task2(), and the result of that to task3(), afaik.