3 ms·
> Programmers who leverage Sequences/Streams, immutability and functional programming tend to hate Go. I dunno, applying the Reader/Writer pattern to other obj
by zeveb 7y ago
> Programmers who leverage Sequences/Streams, immutability and functional programming tend to hate Go.
I dunno, applying the Reader/Writer pattern to other objects in order to get sequences & streams works pretty well in Go.
> If Go the language, didn't come with its stdlib and wasn't pushed by Google, you wouldn't have so many Go fans.
I think the latter part is very true. Go had the very good fortune to be a Pike tool put out by Google back when, ‘hey, Google are producing this!’ was a good thing.
I like Go, but I also like Plan 9 — and it never took off. Neither did Newsqueak or Alef. But Go did, in large part, I think, due to Google’s positive reputation a decade ago.
- rakoo 7y agoThe Reader/Writer interfaces are beautiful in their simplicity, but they're only useful if you want to stream raw, non-Go data. If you want to iterate over a slice or a channel, basically as soon as your data is fit into Go datastructures you don't have a simple and beautiful pattern for working with them as a flow of data.
- zeveb 7y agoYou can always implement a FooReader, which iterates over a flow of Foo objects (which might, for example, be items in a slice or channel). We do this all the time. It is, as you note, quite simple and I think elegant too.
- lenkite 7y agoYes, I have done this, but I was talking more about streams that I can splice, filter, map, join, pair, slice, window, buffer, groupby, scan, skip, take, switch, zip, reduce, etc. Not really possible without generics, lambdas and a good core of functional routines. Once you get used to this and the speed, productivity and elegance with which problems can be solved, using Golang feels a bit primitive and painful. The same Go code is usually 5x-10x longer.