Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Channels Are Not Enough

gist.github.com

Post reply on HN
Print view View original

101–110 of 224 posts

Re: Channels Are Not Enough

#101

Post by pjmlp »

eloff wrote: post #17
spion wrote: 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…

Lack of generics != lack of abstractions. The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience. Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.ht…

> Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html

First of all that post was written by Russ Cox.

Second, it already has been discussed multiple times that it only focus on C++, C#, Java approaches while cleverly forgetting generics implementations exist in multiple forms since CLU (1974) introduced them.

But Go advocates take that page as dogma and toss it around every time a generics discussion comes up.

Re: Channels Are Not Enough

#102

Post by pjmlp »

apta wrote: post #97
echaozh wrote: post #94

Earlier quoted context omitted.

I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.

Or the fact that I actually saw someone on the mailing list also implement min() incorrectly due to copy-paste :) > I never thought people will actually come up and defend code duplication. Indeed. Some of the responses by some Go fans really leave me surprised to say the least.

It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D.

At least those communities embrace modern computing abstractions and code distribution practices.

Re: Channels Are Not Enough

#103

Post by pjmlp »

ufo wrote: post #72
zaphar wrote: post #45

Earlier quoted context omitted.

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…

> 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.

Go community lives in 1993, back when C++ compilers shipped with code generation tools (mostly macro based) and templates only existed in CFront.

Re: Channels Are Not Enough

#104

Post by nine_k »

eloff wrote: post #83
spion wrote: post #21

Earlier quoted context omitted.

That really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much. In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pret…

This comment wins the thread!

Sorry, I meant to say that the language's shortcomings, even if temporary, start to attract a wrong attitude, which is sad (and you, golang team, should feel sad).

Re: Channels Are Not Enough

#105

Post by nine_k »

StandardFuture wrote: post #100
echaozh wrote: post #94

Earlier quoted context omitted.

I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.

Now you are shifting to a editing dilemma. Code duplication is not machine code duplication which is what really matters at execution time. Reading is also easier (even for non-Go programmers at least familiar with C) without templating-like syntax.

Machine code duplication is spending a few extra megabytes on perfectly valid, if duplicate, machine code.

Source code duplication is a risk of spending an hour, or maybe a day, of developer's time to detect the duplication, change it in concert in several places, with an occasional need of detecting and fixing a subtle discrepancy between the copies.

RAM is $0.015 per megabyte. Developer time is $50 per hour.

Re: Channels Are Not Enough

#106

Post by pmontra »

apta wrote: post #98
eloff wrote: post #83

Earlier quoted context omitted.

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pret…

> I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pretty ugly Sometimes ugliness is a sign that something is designed incorrectly, especially if the language aids in making that more visually evident. > (although not as ugly as converting your ints to float64 and using the stdlib min/max.) Not to mention incorrect. > it's u…

Plus all those dynamically typed languages which are intrinsically built on the concept of generics (JavaScript, Perl, PHP, Python, Ruby). /sarcasm Nobody uses them because nobody needs generics.

Re: Channels Are Not Enough

#107

Post by pjmlp »

enneff wrote: post #84
kansface wrote: post #58

Earlier quoted context omitted.

The answer to the question "where should complexity go?" is always "as low as possible". Complexity at higher levels interacts with more code and begets more complexity. The lack of generics or macros is complexity that is forced on the end user which could be handled by the compiler (language devs).

Implementation complexity is not the issue. The issue is that a programmer needs to understand how the generics model works and how it interacts with every other feature of the language. That makes the language more complicated, which (as you say) leaks into the higher levels. Generics is just one of many features that Go could have, but does not because it makes the language bigger.

Simple languages shift complexity to the programmer's shoulders.

Re: Channels Are Not Enough

#108

Post by kmontrose »

pjmlp wrote: post #101
eloff wrote: post #17

Earlier quoted context omitted.

Lack of generics != lack of abstractions. The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience. Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.ht…

> Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html First of all that post was written by Russ Cox. Second, it already has been discussed multiple times that it only focus on C++, C#, Java approaches while cleverly forgetting generics implementations exist in multiple forms since CLU (1974) introduced them. But Go advocates take that page as dogma…

It doesn't even cover C#, just C++ and Java. C# has it's flaws certainly, but it's a baffling omission.

Re: Channels Are Not Enough

#109

Post by pjmlp »

latch wrote: post #68
sriku wrote: 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…

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.

Re: Channels Are Not Enough

#110

Post by pjmlp »

kmontrose wrote: post #108
pjmlp wrote: post #101

Earlier quoted context omitted.

> Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html First of all that post was written by Russ Cox. Second, it already has been discussed multiple times that it only focus on C++, C#, Java approaches while cleverly forgetting generics implementations exist in multiple forms since CLU (1974) introduced them. But Go advocates take that page as dogma…

It doesn't even cover C#, just C++ and Java. C# has it's flaws certainly, but it's a baffling omission.

In the comments, where the flaws about the document are pointed out.
Post reply on HN