Hacker News Reader

Comment by zeeboo | Hacker News Reader

You can abstract the channel operations behind interfaces and regain type safety. Inspired by the sort package, I wrote http://thegoods.biz/broadcast for doing broadcast type patterns safely. To use it you implement two trivial methods on a channel type and away you go, single producer multiple consumer channels.

I think there are clever solutions to these types of problems that have yet to be explored because most of the focus is on what Go lacks from other languages.

View on HN

It concerns me that Go has apparently built up such a community of people who insist that there aren't any problems here and you just need to learn the Go way to do it, which nobody quite knows yet, and doesn't quite meet the bill when demonstrated, and seems to require an awful lot of copy & paste boilerplate even so. I don't think that solution addresses my concern, which is that I want to be able to take a channel, and return a modified channel. You can't do that by "wrapping behind an interface", because once you return anything other than another channel you've lost, because you can't "select" on anything other than a channel. You can't say "Oh, I'll wrap the select behind something", because there's no way to compose two selects together; if I want to select on this channel and that channel I must have them both in hand, as channels. So if I want to factor out a particular strategy for managing input on channels, it's just impossible as it stands now; the type system is sufficiently limiting that we can see that that is impossible to write such functionality.

(I haven't gotten around to coding this yet, since I've been taking a break, but the actual solution I'm planning is like this:

    in the library;
        func DoSomethingGeneric (interface{}) (interface{}) {
            blah blah blah lots of reflect probably
            return newThingy
        }

    in the module using the code:
        func DoSomethingSpecific (Thing) (Thing) {
            return DoSomethingGeneric(Thing).(Thing)
        }
    }

I'd make it correct by construction, but that's annoying. Annoying is bad at scale, it means people do the lazy thing instead of the right thing.)

Further, I don't see any way to abstract out the pattern that you do have in hand; you wrote it, and if you want to stick a new type into it, you'll have to write quite a bit of code again.

It's too soon for the community to be this dogmatic about how Go has an answer to everything, when it plainly doesn't. And let me underline this: I'm not complaining that it doesn't have an answer to everything; it's young. I'm complaining that it's too early to be so dogmatic. This is the biggest turn off to me about the developing community.

I keep thinking maybe I'm just spoiled by Haskell or something, then I remember; I can do this in every other language I know in one way or another. In the dynamic languages, it's not any more type safe than anything else, but it works. In the stronger languages, I can get this done. Only Go has has a type system that is strongly typed, but forces me to bypass the system to get it done. (Perhaps C, though that's contingent on so many things it's hard to construct a fair comparison. One must first build a fair amount of structure to even approximate the problem I'm having with Go here.) And it's not like I'm a stranger to programming under very strong restrictions. I like Haskell.

(Also, I am aware that "the community" who is saying this is not everybody; those who are not should probably work on telling those people to tone it down a bit. And broadly speaking, I actually do like Go; this conversation is focusing on my two biggest pain points and is not representative of my full opinion.)

Others just move to D or Rust.

Look, with Go's interface{} system and its out-of-box "pseudo-generic" typed arrays, slices, maps and channels -- there really isn't an awful lot missing in day-to-day pragmatic programming. Pragmatic as in "old-school imperative line-by-line programming with a few modern ideas mixed in as feasible" -- not necessarily software engineering concoctions of patterns of factories etc.

Again -- the interface{}s and boxing/unboxing, typed maps/slices/arrays/channels -- they all represent stuff where (A) the compiler can infer type knowledge safely and (B) very fast compile-and-link times are not compromised.

Like any language, Go isn't designed to cater to every use-case or programming style. You wouldn't even consider C for your above issues -- right? -- well the safe bet is to always view Go more in the realm of a modern, saner C rather than comparing it to Haskell, or Python, or Scala, or ......

The topic of generics comes up about 2x a week on the golang mailing list / Google Group, often (well sometimes) discussed in-depth with good arguments and quality of discourse. So... either the core gophers are just too clueless and dogmatic to be adding them to the language, or their reasons are still as valid as last month or year with regard to Go's primary design goals and focus.

Reply on news.ycombinator.com