Live data from Hacker News

Channels Are Not Enough

gist.github.com

71–80 of 224 posts

Re: Channels Are Not Enough

#71
post #32
post #3

Earlier quoted context omitted.

The problem (which the article touches on) is that you have to resort to interface{} to make things reusable since Go doesn't have generics. So you have to pick between using a library (which will handle edge cases better) or compile time type checking.

You don't have to resort to an empty interface, in fact, mrust experiences go programmers cringe when they see anyone using empty interfaces. The fact of the matter that much code can reused without being "generic" and often your code never gets reused. YAGNI and all that.

It would be really useful if Go allowed you to define methods against types imported from other packages. That way, you could define whichever interface you needed against those types (using only its public API, of course) and then use those interfaces for collections, generic functions, and the like.

The closest I've gotten to that has been to create a single-member wrapper struct. Go provides a little bit of sugar for that, but it results in a decent amount of boilerplate and explicit wrapping/unwrapping.

Re: Channels Are Not Enough

#72
post #45

Earlier quoted context omitted.

> I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. For what it's worth, I have had a similar experience. One time I expressed a personal opinion on G+ about something I don't like about Go personally. A Go fan re-shared this in the Go community and it turned into a debate. https://plus.google.com/+RalphCorderoy/po…

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... https://github.com/clipperhouse/gen I'm sorry you got the impression of that there is a strong bias against admitting problems. I haven't seen that bias at all myself. Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.

TBH, neither of those solve the same problem generics / parametric polymorphism were created to solve: being able to abstract over types when writing a function or data structure.

The first link deals with automatically generating things like printers or comparison functions. Its orthogonal to type abstraction - for example, in Haskell you would use "deriving" or TemplateHaskell macros to do the same thing. This kind of code generation is useful for creating monomorphic functions that depend on the structure of a type (for example, a comparison function for that type) but it won't help you latter create polymorphic functions that work on any type (for example, a sorting function that receives that comparison function as a parameter).

The second link suffers from a similar problem. The only types that can be used generically are the ones defined together with a "//gen" comment and you also can't define your own generic functions (for example, a SumOfDistinct function that composes Sum and Distinct)

You are giving me the impression that people are trying to solve Go's generics problem with tooling when its actually a language design and type system problem.

Re: Channels Are Not Enough

#73
post #64

Earlier quoted context omitted.

I don't know what in my comment suggests that you can't love both Haskell and Go, but that's certainly not what I meant. Nothing I've said here is anything other than my own observation and opinion. Thank you for the advice. I'll keep it in mind.

> I don't know what in my comment suggests that you can't love both Haskell and Go I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false. You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more…

I wasn't making a statement about myself at all. The tradeoffs involved in Go's design are well-known, well-explained, and intentional. There is a great deal to admire and respect about Go and its community. Hell, my first comment in this thread was noting that Go's design makes it particularly easy to learn.

If it helps, substitute "it can be frustrating" for "it's frustrating".

Re: Channels Are Not Enough

#74

Earlier quoted context omitted.

I find your response condescending and hostile, actually. The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people. People de facto speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.

> I find your response condescending and hostile, actually. I don't follow. The rest of your comment posits an argument for why you think I was wrong . If you're going to accuse me of being condescending and hostile, then I think you at least owe me the courtesy of explaining why. > People de facto speak in the form of opinions I agree. > and if we are all to qualify our statements with "...in my opinion" for fear of…

You don't consider condescension and hostility to be "wrong"?

To be explicit, then, I think your comment's tone was inappropriate for HN. You're taking a generalization and expressing displeasure in the fact that the generalization seems to have inadvertedly included you, and then blaming the commenter for having done so.

You have to be deliberately obtuse to assume that the parent's statement was intended as absolute fact. It doesn't matter if we're discussing technology, this is a conversation, not a textbook; it's a normal part of discourse to give the other party a little slack and not treat every utterance literally and in absolute terms.

Re: Channels Are Not Enough

#75

Earlier quoted context omitted.

> I find your response condescending and hostile, actually. I don't follow. The rest of your comment posits an argument for why you think I was wrong . If you're going to accuse me of being condescending and hostile, then I think you at least owe me the courtesy of explaining why. > People de facto speak in the form of opinions I agree. > and if we are all to qualify our statements with "...in my opinion" for fear of…

You don't consider condescension and hostility to be "wrong"? To be explicit, then, I think your comment's tone was inappropriate for HN. You're taking a generalization and expressing displeasure in the fact that the generalization seems to have inadvertedly included you , and then blaming the commenter for having done so. You have to be deliberately obtuse to assume that the parent's statement was intended as absolu…

> You don't consider condescension and hostility to be "wrong"?

Huh? I used "wrong" in the sense, "your argument is incorrect," not, "you shouldn't do that," precisely because your comment explained how you disagreed with me (not why you thought I was being a jerk). In that way, "wrong" and condescension/hostility are orthogonal concepts.

> You have to be deliberately obtuse to assume that the parent's statement was intended as absolute fact. It doesn't matter if we're discussing technology, this is a conversation, not a textbook; it's a normal part of discourse to give the other party a little slack and not treat every utterance literally and in absolute terms.

I stand by what I said. I don't know what textbooks have to do this. I'm not asking for rigorous debate here. I'm asking for a modicum of clarity in a type of conversation where clarity is important.

I agree that we should give each other a little slack. But I also think we should encourage clarity where we think it is necessary. I think it is necessary in this context.

> You have to be deliberately obtuse

But thanks for the insult all the same. Do you think that is appropriate for HN?

Re: Channels Are Not Enough

#76
post #68
post #57

Earlier quoted context omitted.

That's a weird stance. If there are complexities that programmers face that can be absorbed by a compiler, it must be, because that would pay off for every programmer , in every project, in every bug prevented.

In the Go FAQ [1], when they list the purpose of the project, the first answer they give isn't about concurrency (as some might suspect), it's: "It is possible to compile a large Go program in a few seconds on a single computer." They've been consistent about this. It's a major design goal and, for some, compilation speed is worth more than support for Generics. [1] http://golang.org/doc/faq#What_is_the_purpose_of_th…

And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.

Re: Channels Are Not Enough

#77
post #53

Earlier quoted context omitted.

With the right implementation debugging generics wont be hard. It doesn't have to be C++'s version of generics. And I'm not buying the poor programmer understanding argument. Generics aren't that complex, they're just parameterized types. The fact that basic language libraries such as maps and slices cannot be implemented without them speak volumes about how fundamental they are when building abstractions. My point i…

> But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable. Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) Because if not, then you admit there are trade offs. If there are trade offs, then it is conceivable that some circumstances (including programmer tas…

D's dmd supports templates and is faster than gc.

Re: Channels Are Not Enough

#78
post #73

Earlier quoted context omitted.

> I don't know what in my comment suggests that you can't love both Haskell and Go I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false. You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more…

I wasn't making a statement about myself at all. The tradeoffs involved in Go's design are well-known, well-explained, and intentional. There is a great deal to admire and respect about Go and its community. Hell, my first comment in this thread was noting that Go's design makes it particularly easy to learn. If it helps, substitute "it can be frustrating" for "it's frustrating".

> If it helps, substitute "it can be frustrating" for "it's frustrating".

Yes, OK, that is an entirely different claim altogether. Agreed.

Re: Channels Are Not Enough

#79

Earlier quoted context omitted.

> But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable. Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) Because if not, then you admit there are trade offs. If there are trade offs, then it is conceivable that some circumstances (including programmer tas…

D's dmd supports templates and is faster than gc.

Is there any evidence for this claim? After a quick Google session, the best I could find was a forum thread 4 years ago claiming that `dmd` was faster than `gc`. Is that still true today?

Re: Channels Are Not Enough

#80

Earlier quoted context omitted.

You don't consider condescension and hostility to be "wrong"? To be explicit, then, I think your comment's tone was inappropriate for HN. You're taking a generalization and expressing displeasure in the fact that the generalization seems to have inadvertedly included you , and then blaming the commenter for having done so. You have to be deliberately obtuse to assume that the parent's statement was intended as absolu…

> You don't consider condescension and hostility to be "wrong"? Huh? I used "wrong" in the sense, "your argument is incorrect," not, "you shouldn't do that," precisely because your comment explained how you disagreed with me (not why you thought I was being a jerk). In that way, "wrong" and condescension/hostility are orthogonal concepts. > You have to be deliberately obtuse to assume that the parent's statement was…

I was commenting about tone, not whether your argument was incorrect. As you say, orthogonal concepts.

The "deliberately obtuse" bit was not directed at you specifically, but then if the shoe fits, etc.

Post reply on HN