Live data from Hacker News

Channels Are Not Enough

gist.github.com

201–210 of 224 posts

Re: Channels Are Not Enough

#201

Earlier quoted context omitted.

> That link has been debunked over and over and over. The only point that post is making is that generics have a cost . Are you saying that is false? > Being dishonest will just alienate even more people. What are you hoping to achieve by insulting a large group of people? If your goal is to alienate them, then surely that is an effective tactic.

> The only point that post is making is that generics have a cost. Are you saying that is false? Did you actually read the article? > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Wrong. Additionally, not having Generics has a cost, too. People might disagree which cost is higher (Generics vs. no Generics), but acting as if there was a lower c…

> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome.

Sure there are, including the following possibilities: 1) There are situations in which generics are a net benefit and situations in which generics are a net cost, and currently Go's target are is the latter, but because of drift in what people what in given domains, it evolves toward the former, 2) New advances in understanding of language design and implementation change the tradeoffs of generics such that they are a net benefit in places where currently they are a net cost, 3) The reason generics are a net cost in the current situation of Go isn't fundamental as a featre, but a matter of opportunity cost given other things that were and are being implemented in Go that implementing generics would tradeoff. A future implementation that doesn't disrupt non-generic-using code once other higher-priority features are implemented wouldn't be a net cost. But that's farther out than Go's current roadmap.

> Why not just be honest and tell your users that Generics will never arrive?

Because its not honest to state a decision that hasn't actually been made.

Re: Channels Are Not Enough

#202

Earlier quoted context omitted.

> The only point that post is making is that generics have a cost. Are you saying that is false? Did you actually read the article? > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Wrong. Additionally, not having Generics has a cost, too. People might disagree which cost is higher (Generics vs. no Generics), but acting as if there was a lower c…

> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Sure there are, including the following possibilities: 1) There are situations in which generics are a net benefit and situations in which generics are a net cost, and currently Go's target are is the latter, but because of drift in what people what in given…

> New advances in understanding of language design and implementation [...]

"New advances" as in "the last 50 years of progress in language design which we have conveniently ignored"?

There are languages from the 60ies which are better than Go (but lacked Go's distinguishing feature, the Google brand).

> Because its not honest to state a decision that hasn't actually been made.

Given the constraints they have already made a decision.

Re: Channels Are Not Enough

#203

Earlier quoted context omitted.

> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Sure there are, including the following possibilities: 1) There are situations in which generics are a net benefit and situations in which generics are a net cost, and currently Go's target are is the latter, but because of drift in what people what in given…

> New advances in understanding of language design and implementation [...] "New advances" as in "the last 50 years of progress in language design which we have conveniently ignored"? There are languages from the 60ies which are better than Go (but lacked Go's distinguishing feature, the Google brand). > Because its not honest to state a decision that hasn't actually been made. Given the constraints they have already…

> "New advances" as in "the last 50 years of progress in language design which we have conveniently ignored"?

No, new advances as in, "new advances". The universe changes, and the context in which the decision not to prioritize generics now was made is not fixed.

> There are languages from the 60ies which are better than Go

"Better" is both subjective and use dependent, and, in any case, that claim is irrelevant to the point under discussion, which is whether or not it is logically possible for the cost tradeoffs to disfavor generics in Go now but favor them in the future.

> Given the constraints they have already made a decision.

Given the current constraints they have already made a decision not to develop generics now.

They have not made the decision you claim that they would be "honest" to announce, to wit, that Go will never have generics.

It may be that it won't, but that's a not a decision that they have made (nor is it a decision that it would likely ever make sense to make. Why ever say "never"?)

Re: Channels Are Not Enough

#204

Earlier quoted context omitted.

> That link has been debunked over and over and over. The only point that post is making is that generics have a cost . Are you saying that is false? > Being dishonest will just alienate even more people. What are you hoping to achieve by insulting a large group of people? If your goal is to alienate them, then surely that is an effective tactic.

> The only point that post is making is that generics have a cost. Are you saying that is false? Did you actually read the article? > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Wrong. Additionally, not having Generics has a cost, too. People might disagree which cost is higher (Generics vs. no Generics), but acting as if there was a lower c…

> Additionally, not having Generics has a cost, too.

The article says it: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times." The first "slow programmers" cost is addressing the absence of generics in the language. Thus, it admits a cost.

> but acting as if there was a lower cost solution of "no Generics now, but retroactively add them later" hiding somewhere is just incredibly disingenuous and delusional.

... Nobody is acting that way. I've said nothing about the relative weight of any cost, nor have I claimed that a lack of generics has no cost. I mean, the link I gave you admits that a lack of generics has a cost right there. You even quoted the relevant portion.

> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Why not just be honest and tell your users that Generics will never arrive?

I don't understand what point you're trying to make. Are you saying that the Go language maintainers are purposefully lying to everyone? Do you have evidence of this claim?

> It's a fascinating pattern which happens as soon as you run out of on-topic arguments.

And insulting people doesn't fit that pattern? Yikes.

Re: Channels Are Not Enough

#205
post #177

Earlier quoted context omitted.

I also find Go pragmatic but lacking abstraction power. The other day I needed a stack, and the best solution I could find was this: https://groups.google.com/d/msg/golang-nuts/iwlzqNa4h3g/xCy3... to be honest, if i need a stack, i usually implement it for the type in question, or inline, as it's only a very small number of lines: type stack []T func (s *stack) push(t T) { *s = append(*s, t) } func (s *stack) pop() T…

It's 10 lines of very obvious code. Isn't that a good thing? Do you really need stack.New ()?

Yes, I do think so. Then I could keep thinking about the "business problem" instead of googling for half an hour because I can't believe there is no one reuses a stack in Go.

Also, it could be something much more complicated than a stack, like the data structures in the STL... but that point has already been made elsewhere.

Re: Channels Are Not Enough

#206
post #109
post #68

Earlier quoted context omitted.

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…

Any language with modules and generics and production quality native code compiler, does enjoy fast compilation speed. It is a good sell when the audience only knows about C++ compilation issues.

Last time people were ecstatic about go compilation speed, the speeds cited didn't even hold up well against gcc.. The go compiler is not very fast, but as you point out the features of the Go language makes it amenable to fast compilation.

What kills compilation performance for larger C/C++ projects is include hell and managing build dependencies, which as you point out is mitigated in language with modules.

Re: Channels Are Not Enough

#207

Earlier quoted context omitted.

My understanding is that the Go team says they can't figure out how to make generics work nicely, that's why they haven't added them. Also, type casts don't cause runtime panics. You can use type-based switch/case or check the "ok" return value from the cast to see if it worked.

That's basically what Java said in 1995. There is a reason why Java completely abandoned that position.

Did Java make generics work nicely, or did they just bolt them on?

Re: Channels Are Not Enough

#208
post #11

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. 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. A similar problem wit…

You sound confused. Denying the existence of a problem and not wanting a particular proposed solution are not the same thing.

Re: Channels Are Not Enough

#209

Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics, which completely drowns the discussions about Go. As a result, the material on the web about Go has a very high noise/signal ratio, which is unfortunate. Hopefully, the Go team will see this as one more reason to add generics to their language, but until they do that, Go will remain a niche language w…

I have to credit this as being one of the more original arguments for adding generics to Go: we should do it because it will increase the signal/noise ratio in discussions about Go. (Personally, I don't mind the ongoing discussions about generics in Go, I just wish they were less repetitive. It's very easy to say "add generics to Go!" It's a little bit harder to actually do it well.)

Yeah I was trying to insufflate new life in this tired debate, glad someone noticed :)

Re: Channels Are Not Enough

#210
post #206
post #109

Earlier quoted context omitted.

Any language with modules and generics and production quality native code compiler, does enjoy fast compilation speed. It is a good sell when the audience only knows about C++ compilation issues.

Last time people were ecstatic about go compilation speed, the speeds cited didn't even hold up well against gcc.. The go compiler is not very fast, but as you point out the features of the Go language makes it amenable to fast compilation. What kills compilation performance for larger C/C++ projects is include hell and managing build dependencies, which as you point out is mitigated in language with modules.

And with luck, even C++ will finally have modules. Still need to wait a few more years, though.
Post reply on HN