Re: [go-nuts] Re: Generics are overrated.

[David Collier-Brown]

On 10/08/17 09:09 AM, roger peppe wrote:

On 10 August 2017 at 13:39, David Collier-Brown  wrote:

On 10/08/17 02:47 AM, Henrik Johansson wrote:

I beg to differ. Most Java apps I have seen over many years almost
unanimously suffer from over-modeling.


A former customer did a deep, thoughtful, *thorough* model of bracket
tournaments, without any attempt to abstract the salient features. Java
represented it beautifully, in complete detail...

So it's now impossible for a single person to keep it in their brain, and
every attempt to change it introduces new, surprising "features".

In effect, the ability to represent anything easily led to our error: we
represented _everything_.

I remember something similar happening with some Haskell I wrote.
Because the type system was so powerful, it felt wrong not use it to
represent everything, which ended up problematic. Frivolous thought:
I wonder if there's an (far-fetched) analogy to be made between this
and dropout techniques in neural networks - if our type system is really
powerful, it's easy for our type structures to "overfit" to the current
problem being solved, making it less adaptable and maintainable when
the problem changes.

I quite agree: I suspect it a tradeoff, in which the more you can easily 
represent, the more you need to carefully architect exactly *what* you 
represent.


--dave

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[roger peppe]

On 10 August 2017 at 13:39, David Collier-Brown  wrote:
> On 10/08/17 02:47 AM, Henrik Johansson wrote:
>>
>> I beg to differ. Most Java apps I have seen over many years almost
>> unanimously suffer from over-modeling.
>
>
> A former customer did a deep, thoughtful, *thorough* model of bracket
> tournaments, without any attempt to abstract the salient features. Java
> represented it beautifully, in complete detail...
>
> So it's now impossible for a single person to keep it in their brain, and
> every attempt to change it introduces new, surprising "features".
>
> In effect, the ability to represent anything easily led to our error: we
> represented _everything_.

I remember something similar happening with some Haskell I wrote.
Because the type system was so powerful, it felt wrong not use it to
represent everything, which ended up problematic. Frivolous thought:
I wonder if there's an (far-fetched) analogy to be made between this
and dropout techniques in neural networks - if our type system is really
powerful, it's easy for our type structures to "overfit" to the current
problem being solved, making it less adaptable and maintainable when
the problem changes.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[David Collier-Brown]

On 10/08/17 02:47 AM, Henrik Johansson wrote:
I beg to differ. Most Java apps I have seen over many years almost 
unanimously suffer from over-modeling. 


A former customer did a deep, thoughtful, *thorough* model of bracket 
tournaments, without any attempt to abstract the salient features. Java 
represented it beautifully, in complete detail...


So it's now impossible for a single person to keep it in their brain, 
and every attempt to change it introduces new, surprising "features".


In effect, the ability to represent anything easily led to our error: we 
represented _everything_.


Go (or C) doesn't actually address over-modeling: it's merely harder to 
do, and we're less likely to make that error, just as a side-effect (;-))


--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Henrik Johansson]

I beg to differ. Most Java apps I have seen over many years almost
unanimously suffer from over-modeling. That Go encourages another style of
modeling does not make it too simple. It only makes it different which may
be good or bad according to taste.

That said, I personally think that generics would be a net win if it was
somehow possible to design a version of it that still encourages simple
abstractions rather than the complicated mess so often seen.

On Thu, 10 Aug 2017, 08:37 Haddock,  wrote:

>
>
> Am Mittwoch, 9. August 2017 23:29:13 UTC+2 schrieb DV:
>>
>>
>>
>> On Tuesday, August 8, 2017 at 5:37:42 AM UTC-6, Haddock wrote:
>>>
>>> In my opinion generics added to Go would make Go really take off.
>>> Currently Java developers would not change to Go. With Go having generics
>>> this would change and more people would consider Go also when not coming
>>> from Java/C#/etc.
>>>
>>
>> There's no way that any serious Java dev would ever consider Go, generics
>> or not. Why, in Go, you justwrite code! In functions! Not a single
>> AbstractSingletonFactoryImpl in sight! 
>>
>> I used to do C# for a living, and Java before that. What drew me to Go
>> was that it was *not* C# nor Java. That's actually the beautiful thing
>> about it.
>>
>
> Go does not have the modeling power of Java, C#, Python, etc. The language
> is too simple for that. So Go is not really the real thing for application
> development. But generics would make it possible to drag many things up.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jan Mercl]

On Tue, Aug 8, 2017 at 1:37 PM Haddock  wrote:

> Currently Java developers would not change to Go.

Never enough of good news.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Haddock]

In my opinion generics added to Go would make Go really take off. Currently 
Java developers would not change to Go. With Go having generics this would 
change and more people would consider Go also when not coming from 
Java/C#/etc.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Lucio]

Got it. In the same document:

"Halfway the functional design of the X1, I guess early 1957, Bram and 
Carel confronted me with the idea of the interrupt, and I remember that I 
panicked, being used to machines with reproducible behaviour. How was I 
going to identify a bug if I had introduced one? After I had delayed the 
decision to include the interrupt for 3 months, Bram and Carel flattered me 
out of my resistance, it was decided that an interrupt would be included 
and I began to study the problem. To start with I tried to convince myself 
that it was possible to save and restore enough of the machine state so 
that, after the servicing of the interrupt, under all circumstances the 
interrupted computation could be resumed correctly."

Thank you again, Peter.

Lucio.


On Sunday, 6 August 2017 12:03:07 UTC+2, Lucio wrote:
>
> Thank you, Peter.
>
> Maybe someone else can corroborate my impression that Dijkstra did not 
> immediately accept the idea of interrupts and felt it would make 
> programming too difficult?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Lucio]

Thank you, Peter.

Maybe someone else can corroborate my impression that Dijkstra did not 
immediately accept the idea of interrupts and felt it would make 
programming too difficult?

Lucio.

On Saturday, 5 August 2017 19:44:26 UTC+2, peterGo wrote:
>
> Lucio,
>
> "It took Dijkstra quite some effort to accept the concept of "interrupts" 
> (quotation anyone?), but eventually he went with it."
>
> E.W. Dijkstra Archive: My recollections of operating system design 
> (EWD1303)
>
> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html
>
> "The third arrangement, known as "the interrupt", circumvents all these 
> dilemmas. While the computer calculates at full speed, a piece of dedicated 
> hardware monitors the outside world for completion signals from 
> communication devices. When a completion is detected, the program under 
> execution is interrupted after the current instruction and in such a 
> fashion that it can be resumed at a later moment as if nothing had 
> happened, thus instantaneously freeing the central processor for a suddenly 
> more urgent task. After the interrupt the processor would execute a 
> standard program establishing the source of the interruption and taking 
> appropriate action."
>
> Peter
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[David Collier-Brown]

Ah well, one can always go back to

COPY PAYLIB REPLACING A BY PAYROLL
  B BY PAY-CODE
  C BY GROSS-PAY
  D BY HOURS.


(Courtesy of 
https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_9.1.1/com.ibm.etools.cbl.win.doc/topics/rlcdscop.htm)

--dave (:-)) c-b

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[judsonwilson via golang-nuts]

I program using Go every day at Google, and I enjoy the language, but I 
feel that the lack of generics is a downer. I also find the language to be 
like Unix in that it is so simple it takes a genius to understand it. 

On Saturday, July 29, 2017 at 3:59:55 PM UTC-7, Shawn Milochik wrote:
>
> As with every community, there's the silent majority and the vocal 
> minority. 
>
> It's easy to be confused, and think that the lack generics is a major 
> issue in the Go community. It is *not*.
>
> The number 500,000 Go developers worldwide has been thrown around a lot 
> this month. (https://research.swtch.com/gophercount)
>
> Evidently most of them are using Go just fine -- as individuals, at 
> startups, and at huge companies.
>
> At every scale, Go's adoption is amazing and the the projects they're 
> building are changing the world:
>
>- You don't need generics to write Docker.
>- You don't need generics to write Kubernetes.
>- We could add so much more to this list, but you get my point.
>
> So, let's stop feeding the trolls. The far fewer than 1% of the people who 
> have not yet taken the time to appreciate Go for what it is, and therefore 
> find it lacking in comparison to something they have taken the time to 
> appreciate. I don't mean to belittle those people by calling them trolls, 
> but they are trolling. I'm sure most of them who give the language an 
> honest, unbiased try will come around.
>
> Imagine if Go programmers went to other language mailing lists and 
> complained about the lack of goroutines and channels, which clearly make 
> those other language "unfit for concurrent programming." That would be 
> equally unhelpful.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Lucio]

(Some unjustifiable opinionated ramblings from a faraway place, read at 
your peril.)

It took Dijkstra quite some effort to accept the concept of "interrupts" 
(quotation anyone?), but eventually he went with it.

Resistance to operator overloading is as admirable as it is futile. 
Ultimately, the range of base types in a programming language is an 
arbitrary decision and the operators applied to them is equally an 
artifact, not divine inspiration. Go slipped badly when it added "+" as the 
string concatenation operator and I don't remember much resistance to that.

In fact, I have adopted the expression x += 1 in lieu of x++ in all my 
coding specifically because I don't think the increment operator is 
necessary at all; a circular shift operator has more merit, but no one asks 
for that. Nor has anyone, including Rob Pike, suggested that we head the 
APL route and add any available special symbols as operators. I can see 
why, of course!

I would expect programming languages one or two generations from now to 
resemble nature more closely and allow programs to evolve rather than be 
"written" or coded. For that, the basic building blocks have to change 
dramatically. But our guidance may well come from the DNA double helix and 
its very small range of components.

I find generics inelegant, they lack any aesthetic appeal and that was 
enough for templates to turn me off C++ 2.0, I hope that Go will not adopt 
similar ugliness. That said, if one could treat types as mutable properties 
of the language objects (variables that can be transformed between 
"compatible" types - a lot like interfaces allow presently, but much more 
visibly, perhaps, I haven't thought that hard about it), then "generic 
functions" would span such "types" intrinsically and still protect the 
program from mistakes at compile time. Hmm, if the type assertion was 
intrinsic rather than explicit, perhaps? We're trying to avoid that, so we 
need a concept as fresh as "type interface", but more amenable to 
enumeration, an explicit "type set" perhaps? I seem to remember something 
like that from "kencc"?

Ultimately, to return to the topic of operator overloading, with C++ they 
came before templates and templates were the inevitable progression. 
Interfaces are a different starting point and there is no immediately 
obvious progression from there, but maybe the Go "leading minds" haven't 
been looking. Maybe all we lack is the type of theory that went into 
describing SQL as a mathematical concept, applied to interfaces, just 
maybe...

A final thought: the Go.1 promise is a wonderful idea, since it encouraged 
a whole cultural group to look for every conceivable improvement that could 
be made to a very stable core. But of course it had to apply blinkers. 
Eventually, someone will peek over the edge of such blinkers and figure 
what we've all been missing. It is not a critical component, but once it or 
they are identified, it will be hard to imagine how they could have been 
missed for so long.

Lucio.

On Saturday, 5 August 2017 03:52:28 UTC+2, as@gmail.com wrote:
>
> I'm hesitant to accept generics due to the fear of *overloaded operators 
> *being 
> the next big deal*. *C# even has *properties (user-defined methods 
> dispatched upon an assignment operation)*. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[as . utf8]

I'm hesitant to accept generics due to the fear of *overloaded operators *being 
the next big deal*. *C# even has *properties (user-defined methods 
dispatched upon an assignment operation)*. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Dorival Pedroso]

Agreed!

And I was a "heavy" user of templates (see e.g. http://mechsys.nongnu.org/, 
including extensive use of "expression templates") ~5 years ago before the 
"wonders of Go".

Let's focus on making Go faster instead!

Cheers.
Dorival

On Friday, July 28, 2017 at 10:41:10 PM UTC+10, dogan...@dodobyte.com wrote:
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely different programming 
> styles.
>
> Dear Go experts;
>
> Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> Let's end this debate and help keeping Go small and simple. It's the real 
> virtue of Go. 
>
> Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Doğan Kurt]

>
>  it's amazing to see what people were able to accomplish with 2KB RAM, 
> *one* general-purpose register, no hardware multiply/divide,
>
 
Constraints boost creativity and discipline programmer. You may like this 
.

Today's mainstream programmers of mainstream languages just don't give a 
damn about simplicity or smallness. They don't spend any time for thinking 
a small and elegant design, they just start writing and writing as it's how 
they are taught.

This is 
grep from unix v7. It's still compiles* and runs perfectly and it's only 
478 sloc. Also see this. 

Go to me is an awesome little house on a beach. I love going to it in the 
> summer. Everything is great about it. Almost. It just doesn't have hot 
> water. I have to heat water myself and carry it for a 1/4 mile every time I 
> want to shower. It's kind of annoying, but not a big deal in itself to make 
> me stop going to the awesome super fun summer house. 
>

You are not only overestimating generics here, you are also underestimating 
programmers who code in languages without generics, such as C.

**i just needed to replace BSIZE with LBSIZE, it might be a typo.*

On Thursday, August 3, 2017 at 6:10:24 PM UTC+2, DV wrote:
>
> I think "need" is indeed one of those special words that means different 
> things for different people.
> Go doesn't "need" generics and you technically don't "need" anything 
> except air, water, food, a sharp spear, and shelter, to survive.
>
> I recently started toying with writing quick-n-dirty programs for the 
> original NES and it's amazing to see what people were able to accomplish 
> with 2KB RAM, *one* general-purpose register, no hardware multiply/divide, 
> etc Heck, it's even *fun* to do some of those things using 6502 assembly 
> from scratch! Doesn't mean I sometimes don't wish for certain 
> quality-of-life improvements with that experience, even though I can 
> definitely do it all from scratch, given infinite free time. 
>
> Does Go "need" (in the hunter-gatherer sense) generics? Absolutely not! 
>
> Go to me is an awesome little house on a beach. I love going to it in the 
> summer. Everything is great about it. Almost. It just doesn't have hot 
> water. I have to heat water myself and carry it for a 1/4 mile every time I 
> want to shower. It's kind of annoying, but not a big deal in itself to make 
> me stop going to the awesome super fun summer house. 
>
> I really like functional programming paradigms for data transformation 
> tasks. I like chaining 
> map(...).reduce().filter(.).skip(.).drop().select() 
> etc. and building a nice pipeline through which my data can flow. I *can* 
> do it all with loops, of course. Just like I can carry hot water for a 1/4 
> mile every day. 
>
> I'd love to be able to write generic compile-time type-safe functions but 
> I can live without them. 
>
>
> On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>>
>> As with every community, there's the silent majority and the vocal 
>> minority. 
>>
>> It's easy to be confused, and think that the lack generics is a major 
>> issue in the Go community. It is *not*.
>>
>> The number 500,000 Go developers worldwide has been thrown around a lot 
>> this month. (https://research.swtch.com/gophercount)
>>
>> Evidently most of them are using Go just fine -- as individuals, at 
>> startups, and at huge companies.
>>
>> At every scale, Go's adoption is amazing and the the projects they're 
>> building are changing the world:
>>
>>- You don't need generics to write Docker.
>>- You don't need generics to write Kubernetes.
>>- We could add so much more to this list, but you get my point.
>>
>> So, let's stop feeding the trolls. The far fewer than 1% of the people 
>> who have not yet taken the time to appreciate Go for what it is, and 
>> therefore find it lacking in comparison to something they have taken the 
>> time to appreciate. I don't mean to belittle those people by calling them 
>> trolls, but they are trolling. I'm sure most of them who give the language 
>> an honest, unbiased try will come around.
>>
>> Imagine if Go programmers went to other language mailing lists and 
>> complained about the lack of goroutines and channels, which clearly make 
>> those other language "unfit for concurrent programming." That would be 
>> equally unhelpful.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[DV]

I think "need" is indeed one of those special words that means different 
things for different people.
Go doesn't "need" generics and you technically don't "need" anything except 
air, water, food, a sharp spear, and shelter, to survive.

I recently started toying with writing quick-n-dirty programs for the 
original NES and it's amazing to see what people were able to accomplish 
with 2KB RAM, *one* general-purpose register, no hardware multiply/divide, 
etc Heck, it's even *fun* to do some of those things using 6502 assembly 
from scratch! Doesn't mean I sometimes don't wish for certain 
quality-of-life improvements with that experience, even though I can 
definitely do it all from scratch, given infinite free time. 

Does Go "need" (in the hunter-gatherer sense) generics? Absolutely not! 

Go to me is an awesome little house on a beach. I love going to it in the 
summer. Everything is great about it. Almost. It just doesn't have hot 
water. I have to heat water myself and carry it for a 1/4 mile every time I 
want to shower. It's kind of annoying, but not a big deal in itself to make 
me stop going to the awesome super fun summer house. 

I really like functional programming paradigms for data transformation 
tasks. I like chaining 
map(...).reduce().filter(.).skip(.).drop().select() 
etc. and building a nice pipeline through which my data can flow. I *can* 
do it all with loops, of course. Just like I can carry hot water for a 1/4 
mile every day. 

I'd love to be able to write generic compile-time type-safe functions but I 
can live without them. 


On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>
> As with every community, there's the silent majority and the vocal 
> minority. 
>
> It's easy to be confused, and think that the lack generics is a major 
> issue in the Go community. It is *not*.
>
> The number 500,000 Go developers worldwide has been thrown around a lot 
> this month. (https://research.swtch.com/gophercount)
>
> Evidently most of them are using Go just fine -- as individuals, at 
> startups, and at huge companies.
>
> At every scale, Go's adoption is amazing and the the projects they're 
> building are changing the world:
>
>- You don't need generics to write Docker.
>- You don't need generics to write Kubernetes.
>- We could add so much more to this list, but you get my point.
>
> So, let's stop feeding the trolls. The far fewer than 1% of the people who 
> have not yet taken the time to appreciate Go for what it is, and therefore 
> find it lacking in comparison to something they have taken the time to 
> appreciate. I don't mean to belittle those people by calling them trolls, 
> but they are trolling. I'm sure most of them who give the language an 
> honest, unbiased try will come around.
>
> Imagine if Go programmers went to other language mailing lists and 
> complained about the lack of goroutines and channels, which clearly make 
> those other language "unfit for concurrent programming." That would be 
> equally unhelpful.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Dan Kortschak]

On Tue, 2017-08-01 at 09:21 +0200, Sebastien Binet wrote:
> the other place I had (very recently) felt they could have been
> useful:
>  - having a mat.Dense of math/big.Rat (in lieu of a mat.Dense of
> float64)


I think that would be very hard. The reasons behind this claim are that
there is lot of non-generic code behind the mat.Dense user-facing
implementation; we would need generic BLAS and generic LAPACK, with
appropriate testing.
Having said that, there is no reason not to implement a big.Rat-based
implementation of mat.Matrix for the methods that you need. It would
return reduced precision float64 values from the At method, but have a
RatAt method returning the exact value.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[roger peppe]

On 31 July 2017 at 19:35, Tristan Colgate  wrote:
>
>
> On Mon, 31 Jul 2017, 18:21 roger peppe,  wrote:
>>
>>
>> > import hpaInformer informer
>> >
>> > myInformer := hpaInformer.New(sharedUnderlyingCacheThing)
>>
>> So... to me, the implementation of NewHorizontalPodAutoscalerInformer
>> looks
>> pretty much exactly like what you've got there, where
>> sharedUnderlyingCacheThing
>> is the result of cache.NewSharedIndexInformer as called currently in the
>> code. That is, that constructor inside the call to NewSharedIndexInformer
>> seems a lot like a constructor for sharedUnderlyingCacheThing to me.
>> I'm not entirely convinced that generics would make the code much
>> cleaner in this case.
>
>
> The duplication I'm thinking about is more the multiple packages, one for
> each type being informed on. If the top level informers package, or
> function, were templatable by the type being informed on, there would be no
> need for the per-type packages. As it stands there is little benefit from
> the godocs for each individual informer. The current docs are verbose well
> beyond the value they add.
>
>>
>>
>> You might want to experiment by refactoring some of that k8s code to use
>> generics (using whatever your preferred formulation might be) and see
>> what it might look like, and whether it looks significantly
>> nicer/simpler/cleaner
>> as a result
>
>
> I might look at something for the informers case, but it's worth pointing
> out that I was thinking generics could provide a difference API, rather than
> a cleaner implementation of the existing one.

It's that different API that I'd be interested in exploring - if you
had generics,
how would you redesign the API so that it's cleaner, simpler and smaller
than the existing API?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Sebastien Binet]

On Tue, Aug 1, 2017 at 2:06 AM, Dan Kortschak  wrote:

> We use sets in the graph packages, but the number of set types is
> pretty limited (sets of nodes and sets of either int or int64) and
> map[T] works for that level of use.
>
> The only other place where it might be useful for us is in in place of
> generating float32 versions of float64 blas and lapack implementations.
>

the other place I had (very recently) felt they could have been useful:
 - having a mat.Dense of math/big.Rat (in lieu of a mat.Dense of float64)


>
> Honestly, I've never really felt a lack.
>
the other time I felt an urge to reach for generics was when implementing
code for reading/writing various scientific data file formats (astro, HEP).
but I was surprised to realize generics weren't *that* necessary after some
aclimatation time. (I am coming from C++/python.)

-s


> On Mon, 2017-07-31 at 05:50 -0700, Mandolyte wrote:
> > It's been many years since I was involved in developing complex
> > systems
> > (C++ and Java). But I agree, it was mostly lists and sets with
> > searching
> > and sorting. But I also used them for algorithms a good bit. Thus I
> > would
> > guess that the maintainers of GONUM libraries might benefit (anyone
> > confirm?).
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Dan Kortschak]

We use sets in the graph packages, but the number of set types is
pretty limited (sets of nodes and sets of either int or int64) and
map[T] works for that level of use.

The only other place where it might be useful for us is in in place of
generating float32 versions of float64 blas and lapack implementations.

Honestly, I've never really felt a lack.

On Mon, 2017-07-31 at 05:50 -0700, Mandolyte wrote:
> It's been many years since I was involved in developing complex
> systems 
> (C++ and Java). But I agree, it was mostly lists and sets with
> searching 
> and sorting. But I also used them for algorithms a good bit. Thus I
> would 
> guess that the maintainers of GONUM libraries might benefit (anyone 
> confirm?).

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Tristan Colgate]

On Mon, 31 Jul 2017, 18:21 roger peppe,  wrote:

>
> > import hpaInformer informer
> >
> > myInformer := hpaInformer.New(sharedUnderlyingCacheThing)
>
> So... to me, the implementation of NewHorizontalPodAutoscalerInformer looks
> pretty much exactly like what you've got there, where
> sharedUnderlyingCacheThing
> is the result of cache.NewSharedIndexInformer as called currently in the
> code. That is, that constructor inside the call to NewSharedIndexInformer
> seems a lot like a constructor for sharedUnderlyingCacheThing to me.
> I'm not entirely convinced that generics would make the code much
> cleaner in this case.
>

The duplication I'm thinking about is more the multiple packages, one for
each type being informed on. If the top level informers package, or
function, were templatable by the type being informed on, there would be no
need for the per-type packages. As it stands there is little benefit from
the godocs for each individual informer. The current docs are verbose well
beyond the value they add.


>
> You might want to experiment by refactoring some of that k8s code to use
> generics (using whatever your preferred formulation might be) and see
> what it might look like, and whether it looks significantly
> nicer/simpler/cleaner
> as a result
>

I might look at something for the informers case, but it's worth pointing
out that I was thinking generics could provide a difference API, rather
than a cleaner implementation of the existing one.


> I suspect that it might not look that much different - whether you're using
> type-parametric polymorphism or interfaces, somehow you've got to
> plug the specific code into the generic code, and that existing k8s code
> doesn't look like it has that much redundant boilerplate to it.
>
>   cheers,
> rog.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Tristan Colgate]

Re-posting to the list.

On Mon, 31 Jul 2017, 14:15 roger peppe,  wrote:

> On 30 July 2017 at 08:22, Tristan Colgate  wrote:
>
>>
>>
>> On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:
>>
>>>
>>>- You don't need generics to write Kubernetes.
>>>
>>> I've had no personal need for generics, but k8s client-go is the one
>> case I've seen where I thought they would help, the informers packages in
>> particular.
>>
>> https://godoc.org/k8s.io/client-go
>>
>
> It's always nice to have experience reports of real world cases, so
> could you expand on this, please? What specific code are you referring to
> here,
> and how would it be improved if Go had generics?
>


I should start by saying that I'm not a contributor to client-go, just a
user,
so can't speak for their actual experience of developing that package.
As I understand it, much of client-go is generated by tools already, so
they have
the particular problem solved, and may well be far happier with what they
have than
a generics solution.

The particular package that triggered the "generics" sensation is
http://godoc.org/k8s.io/client-go/informers and
http://godoc.org/k8s.io/client-go/listers.
These generate code for efficiently watchig and listing resources on kube
cluster using
a nice cacheing mechanism.

All of the individual type specific informers packages have a

func New(f internalinterfaces.SharedInformerFactory) Interface

Interface here is a type in the package such as

type Interface interface {
// HorizontalPodAutoscalers returns a HorizontalPodAutoscalerInformer.
HorizontalPodAutoscalers() HorizontalPodAutoscalerInformer
}

which provides a type-safe way of getting at a the thing being informed on.

Part of me imagines someting like..

import hpaInformer informer

myInformer := hpaInformer.New(sharedUnderlyingCacheThing)

My hunch is that client-go has quite a few of these situations (the listers
package is one,
and general experience with the package suggests there would be others).

Clearly everything is already working pretty well, so there's nothing
"impossible" without generics here. The
client-go package is still reasonably pleasant to use (though, as a
consequence of all the genration the docs
are very verbose, but low content, it took me a long time to actually work
out how to use the shared informers
stuff because I kept start with the voluminous sub packages, rather than
the informers package that got lost in the noise).

And, once again, I'm heavily unqualified to comment on this from the
package maintainers
PoV, if they felt strongly about this, I'm sure they'd be speaking up
already.




>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[roger peppe]

On 30 July 2017 at 08:22, Tristan Colgate  wrote:

>
>
> On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:
>
>>
>>- You don't need generics to write Kubernetes.
>>
>> I've had no personal need for generics, but k8s client-go is the one case
> I've seen where I thought they would help, the informers packages in
> particular.
>
> https://godoc.org/k8s.io/client-go
>

It's always nice to have experience reports of real world cases, so
could you expand on this, please? What specific code are you referring to
here,
and how would it be improved if Go had generics?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Mandolyte]

It's been many years since I was involved in developing complex systems 
(C++ and Java). But I agree, it was mostly lists and sets with searching 
and sorting. But I also used them for algorithms a good bit. Thus I would 
guess that the maintainers of GONUM libraries might benefit (anyone 
confirm?).

I haven't seen many libraries developed in Go yet, but I think it likely 
many would benefit from generics. And I think it could simple and readable. 
I tend to think of it as an analogue to `go generate`. The latter is for 
package *authors*... a similar feature for package *users *is all that is 
needed.

On Sunday, July 30, 2017 at 5:08:46 PM UTC-4, David Collier-Brown wrote:
>
> I came to Go from languages that had generics, but in practice I find that 
> I predominantly used list-of and  set-of.  And I spent a dispropriate 
> amount of time with valgrind making sure my C++ list didn't have leaks (:-()
>
> A question to people who use Java/C++ and friends: what generics do you 
> find you use in *production* programs?
>
> --dave
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[David Collier-Brown]

I came to Go from languages that had generics, but in practice I find that 
I predominantly used list-of and  set-of.  And I spent a dispropriate 
amount of time with valgrind making sure my C++ list didn't have leaks (:-()

A question to people who use Java/C++ and friends: what generics do you 
find you use in *production* programs?

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Mandolyte]

Just a reminder that Egon Elbre's documentation of all the discussions on 
this topic is here:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[mhhcbon]

"This thread was about concerns that generics would divide Go community"

that d would dismiss any attempt to propose generics *because* it s 
generics,
instead of the observation that the proposal does breaks everything 
including the community.

maybe the first thing to do is to ban this word "generics", so we can start 
thinking about facts,
rather than trying to pull a model and put it into go ?


On Sunday, July 30, 2017 at 3:14:27 PM UTC+2, dogan...@dodobyte.com wrote:
>
> Daily reminder: This thread was about concerns that generics would divide 
> Go community. Not about necessity of generics in general.
>
> Two possible scenarios:
>
> 1) Go have programmers from very different backgrounds, some used generics 
> often while others never used it. (e.g. Java and C). So different people 
> will use different features of Go with different style and practices. This 
> is the C++ mistake.
>
> 2) Go 2 will have such a fundamental new feature and Go 1 programmers will 
> avoid Go 2. To use old code base with Go 2, you have two options;
>  a- Mix Go 1 code with Go 2 code, new code uses generics while old code 
> does not.
>  b- Update Go 1 code to utilize generics.
>
> Personally i would rather stay with Go 1. This is the Python mistake.
>
> I may be wrong, this is only my concerns. 
>
> Thanks.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[dogan . kurt]

Daily reminder: This thread was about concerns that generics would divide 
Go community. Not about necessity of generics in general.

Two possible scenarios:

1) Go have programmers from very different backgrounds, some used generics 
often while others never used it. (e.g. Java and C). So different people 
will use different features of Go with different style and practices. This 
is the C++ mistake.

2) Go 2 will have such a fundamental new feature and Go 1 programmers will 
avoid Go 2. To use old code base with Go 2, you have two options;
 a- Mix Go 1 code with Go 2 code, new code uses generics while old code 
does not.
 b- Update Go 1 code to utilize generics.

Personally i would rather stay with Go 1. This is the Python mistake.

I may be wrong, this is only my concerns. 

Thanks.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[mhhcbon]

i have not read this,

1. i do go because the type system is helping me,
if i do js, i have no type system, so i have to figure this out by myself, 
its hard
if i d be doing java, i d end up with complex giant scaled type hierarchy, 

both cases, it d more a difficulty than an helper to my attempt to solve a 
real problem.

2. generics / not generics ?
i d rather think in terms of *capability*.
- i can t declare a func which returns the type it received, i feel like 
its a lack of basic capability.
- i can t generalize easily / elegantly some algo, again this looks likes a 
basic functionality.

should any of this be necessarily over complex, *i hope not*.

should any existing implementation is the right one, i believe not, for as 
much as i know (not that much, true :),
because they thought generics as a piece of software to integrate in a 
complex hierarchy of types (so they needed to parametrized their generics),
they made generics in their ways of thinking.

The day GO has found its way around those two difficulties *using **its way 
of thinking*,
- how to let the runtime leaks into the static type system (dont pre 
emptively define the world, locally solves problems)
- elegantly provide re usable algo (be DRY)
it d be an awesome language to write.

As a comparison, quickly i want to talk about php, before php4, there was 
not a type system,
since php5 they implemented a type system with class hierarchy based on 
Java and co (so called "leaders"),
IMHO, a total failure, php is no more php, its not java and co either, it 
became a bloat,
years later, i think about it and wish they took their inspiration from the 
go language,
they did not.

Do i want GO to become java because "its a leader", really not please, i d 
rather keep go 1.

3. compile time worries
I found it inadequate to worries yet about the compiler speed without a 
clear and meaningful change proposal.
Also, i wonder if we are worrying about a compilation time with no-cache, 
or with a hot cache.
Said as a question, is it a worry about 1% use case, or the 99% use cases ?
The consequence would be, how to re think this worry with new metrics, 
thresholds, explanations ?


On Friday, July 28, 2017 at 2:41:10 PM UTC+2, dogan...@dodobyte.com wrote:
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely 

Re: [go-nuts] Re: Generics are overrated.

[Russel Winder]

On Sat, 2017-07-29 at 18:59 -0400, Shawn Milochik wrote:
> […]
> 
> Imagine if Go programmers went to other language mailing lists and
> complained about the lack of goroutines and channels, which clearly
> make
> those other language "unfit for concurrent programming." That would
> be
> equally unhelpful.

Some of us have been going round various programming language mailing
lists complaining about the lack of dataflow, CSP, etc. support in
languages and their libraries for 30+ years. 

Fortunately, over the last 10 years, we have been getting programming
language and libraries doing actors, dataflow, and CSP (or rough
equivalent) properly, and most importantly – getting traction amongst
programmers.

So now we have a number of programming language becoming fit for
concurrent and parallel programming, what is the next evolution? What
comes after Go, Rust, Pony, Nim, D, C++20, etc.?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part

Re: [go-nuts] Re: Generics are overrated.

[Tristan Colgate]

On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:

>
>- You don't need generics to write Kubernetes.
>
> I've had no personal need for generics, but k8s client-go is the one case
I've seen where I thought they would help, the informers packages in
particular.

https://godoc.org/k8s.io/client-go

(FWIW, I'd rather there was an effort, like the one for dep, to take
learnings from the existing generics/templating tools, and see what's
needed in the language and tooling to give us one tool in the standard tool
chain)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jérôme LAFORGE]

> As with every community, there's the silent majority and the vocal minority.
But when we let the community to manifeste it choice (even if little part of 
this community that reply to survey) in regarding the 2016 golang survey:

What changes would improve Go most?
1 generics

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Shawn Milochik]

As with every community, there's the silent majority and the vocal
minority.

It's easy to be confused, and think that the lack generics is a major issue
in the Go community. It is *not*.

The number 500,000 Go developers worldwide has been thrown around a lot
this month. (https://research.swtch.com/gophercount)

Evidently most of them are using Go just fine -- as individuals, at
startups, and at huge companies.

At every scale, Go's adoption is amazing and the the projects they're
building are changing the world:

   - You don't need generics to write Docker.
   - You don't need generics to write Kubernetes.
   - We could add so much more to this list, but you get my point.

So, let's stop feeding the trolls. The far fewer than 1% of the people who
have not yet taken the time to appreciate Go for what it is, and therefore
find it lacking in comparison to something they have taken the time to
appreciate. I don't mean to belittle those people by calling them trolls,
but they are trolling. I'm sure most of them who give the language an
honest, unbiased try will come around.

Imagine if Go programmers went to other language mailing lists and
complained about the lack of goroutines and channels, which clearly make
those other language "unfit for concurrent programming." That would be
equally unhelpful.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jesper Louis Andersen]

On Sat, Jul 29, 2017 at 6:36 PM  wrote:

> I just want to know sincerely, if people REALLY need generics so much, or
> they are just complaining because they are used to it and it's in their
> favorite programming language.
>
>
Generics tend to serve at least two purposes in a programming langauge.

What you are doing is that you are essentially extending functions such
that they have two types of parameters: term parameters (which is what Go
has now) and type parameters which instantiate the given function for those
types. The output type is always a term[*]. Most generics can be boiled
down to this very idea in the end and most of the notation can be reified
by expansion.

One reason to want this is simply that it avoids typing. Your example of
expanding a Max function for each possible type is a common one.

The other primary reason as to why people want something like this is
precision: you can describe the intent of a program more precisely which
means that the compiler is able to catch more programming mistakes up
front. The obvious benefit here should be when programming in the large
with many people working on the same code base. If we can capture more bugs
at compile time, they don't end up occurring when running programs.

As secondary reason is that once you start combining generic features, you
really need to start relying on the compiler telling and hinting you about
where you are mistaken in your use-case. If you had tried a variant based
on interface{} and reflect, you are likely to mess it up.

In principle, maps or arrays could have been implemented such that they
would require the use of an interface{}. But this would make more brittle
programs. Hence, the language defines maps and arrays as generic
constructions. If you look at package builtin, it defines (for
documentation purposes) builtin.Type and builtin.Type1. These are
subsequently used in different invocations where you need the invocation to
be generic: copy(), close(), append(), cap(), len(), ...

What proponents of generics are saying is that they want access to the same
kind of functionality at the language level so they can define their own
functions to work like the ones above. Clearly, the compiler must
understand the notion of generic type(!), but it doesn't give that power to
the programmer.

You can argue that Turing completeness means you can implement anything
with anything as long as it is Turing complete. But by that argument, we
could as well be writing assembly still because, after all, you can
implement anything in assembly. Programming languages are about applying
select restriction in order to achieve more. For instance by building a
programming language which doesn't make use of a goto construction, even
though assembly is all jumps and program counter manipulation.

On the other hand, it should be mentioned that Go already has an
abstraction feature in the interface construction. And some uses of
generics can be resolved simply by rephrasing them in an interface. Yet
there are certain things which cannot be expressed if you don't have a
type-level variable.

(Aside: I don't write enough Go to have an opinion on whether or not it
would be right to add generics to Go. But based on my experience with other
languages, I enjoy programming with them there. )

[*] You can explore what it means to have the output be either a term or a
type. See e.g., F* or Idris.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Robert Melton]

On Sat, Jul 29, 2017, at 13:33, dogan.k...@dodobyte.com wrote:
>> Also, building a basic one yourself if you don't want to use those tends to 
>> be exceptionally straightforward. > 
> Thanks for examples, i can't tell if they are experimental or viable for 
> production use. 
I am not sure the case where a code generation tool would be "experimental", as 
they aren't in most cases that clever, they are mostly just saving typing time. 
 Some of the ones listed are more clever than others -- but I would consider 
them all "production" ready in so much that they can output code you can use in 
production.

> But if it's that straightforward, why people complain about it too much.
I believe a part of it is tool anxiety.  You have to pick a tool, learn it, 
vendor it, and train others on it and hope it is maintained / improved going 
forward.  When this tool is not a blessed part of the language it often causes 
stress for people.  That said, I use a lot of console tools with Go in my day 
to day development (over a dozen no less) -- so I feel a tool for generating 
variations fits very well with the Go ethos.

-- 

  Robert Melton | rmel...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Daniel]

I'm curious: are there use-cases where template generation with
gengen/genny/etc are not enough? seems to me that calling "go generate" a
few times (when you need to generate generic containers for certain types)
is a very fair tradeoff to have generic containers without having to change
the language core (or possibly affecting build times for all the other
cases that don't need them).



On Sat, Jul 29, 2017 at 1:04 PM, Robert Melton  wrote:

>
> On Sat, Jul 29, 2017, at 12:36, dogan.k...@dodobyte.com wrote:
>
> I was watching rus cox's last talk
>  and he mentioned that not
> every problem should be solved by language change. Some can be solved by
> tooling or library change.
>
> I am curious has any of the generics lovers written a tool that helps for
> generic behavior. Something like,*
>
>
> There are a bunch https://github.com/taylorchu/generic, https://
> github.com/cheekybits/genny, https://github.com/joeshaw/gengen, and
> https://github.com/clipperhouse/gen and I am sure many more that I don't
> have sitting in my bookmarks.
>
> Also, building a basic one yourself if you don't want to use those tends
> to be exceptionally straightforward.
>
> --
> Robert Melton | rmel...@gmail.com
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"Worse things happen at sea, you know!"

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[dogan . kurt]

>
> Also, building a basic one yourself if you don't want to use those tends 
> to be exceptionally straightforward.  
>

Thanks for examples, i can't tell if they are experimental or viable for 
production use. But if it's that straightforward, why people complain about 
it too much.

I implemented hash tables a billion times in C but i never complained about 
C's lack of map type. Because i understood the design choices and 
philosophy of C. 

I always dreamed a Ken Thompson version of C++, not necessarily an object 
oriented version of C but a more modern C. C with automatic memory 
management, better string handling etc, and still small and simple. 

Now we have it, and it's called Go (Thanks to Pike, Griesemer, Cox, Taylor 
and everyone). I love it because it's small, simple, modern and it 
maintains unix's and C's philosophy. 

It just hurts me to see people try to do it what they did to C++, add 
favorite feature of everyone. I know Go team is much smarter than me and 
Thompson is the creator of unix philosophy, i am confident that Go will 
stay as it is, a small simple, pragmatic and powerful language.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[dogan . kurt]

I was watching rus cox's last talk 
 and he mentioned that not 
every problem should be solved by language change. Some can be solved by 
tooling or library change. 

I am curious has any of the generics lovers written a tool that helps for 
generic behavior. Something like,*

//@generic
func Max(x, y T) T {
if x > y {
return x
}
return y
}

When the tool sees generic comment, it rewrites the function for each type 
as called, like Maxi(x, y int) int, Maxf64(x, y float64) float64 etc..

** I know there are many issues with this example but it's just to show my 
point*

I know people wrote tools like goimports, gocode out of real needs, and 
they are everywhere. 
I just want to know sincerely, if people REALLY need generics so much, or 
they are just complaining because they are used to it and it's in their 
favorite programming language.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jan Mercl]

On Sat, Jul 29, 2017 at 5:18 PM  wrote:

> write a compile time type safe generic reduce function with the following
signature which works for all slices of any element type :
>
> func reduce(array []A,out B,in A)B {}
> you can't do that in Go .

You've nonchalantly changed topic, even though no one said you can do
everything without generics. (BTW: You can, ask Mr. Turing for details.)

> Interfaces won't help either when you're basically using them as C
(*void) .

Are you really telling me you consider void*, carrying no type information
whatsoever, equal to interface{} which carries full type information? If
so, I can't help you, sorry.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[prades . marq]

I love playing with package reflect, which is much more powerful than 
generics by the way (you can't implement gob or json with generics).

You could absolutely do that without runtime reflection. It is called 
compile time type safe macros ... Oh wait, Rust has them, and generics and 
a correct implementation of method polymorphism... 

Le samedi 29 juillet 2017 15:44:26 UTC+2, Roberto Zanotto a écrit :
>
> I love playing with package reflect, which is much more powerful than 
> generics by the way (you can't implement gob or json with generics).
>
> On Saturday, July 29, 2017 at 3:28:56 PM UTC+2, M P r a d e s wrote:
>>
>> What is overrated is the use of "interface { }" and reflection AKA 
>> runtime magics which has no place in a modern statically typed language. 
>> It's a cop-out, it's dirty and a direct consequence of the absence of 
>> generics in Go.
>>
>> > Please provide some best practices to achieve generic behavior for the 
>> most common cases, instead of implementing Generics in Go.
>>
>> You cannot achieve generic behavior without some form of generics. Look 
>> at sync.Map it's not compile time type safe. With generics it would be. 
>>
>>
>>
>> Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a 
>> écrit :
>>>
>>> *Everything in this thread is my personal opinions, they are not 
>>> necessarily the truth.*
>>>
>>> My main language was C for a decade. I also liked Python. When i started 
>>> learning Go, it almost felt like i knew the language in another life. 
>>> Everything was so obvious.
>>>
>>> CSP model of concurrency was new to me though. Interfaces were more 
>>> familiar due to unix's open,close,read,write interface, which is the 
>>> greatest idea.
>>>
>>> I didn't use generics or templates much (it's kind of stupid for me to 
>>> talk about it's necessity), therefore this is more like a meta-research.
>>>
>>> - Go developers created a great standard library and many great software 
>>> without generics in the language.
>>> - Many companies switched to Go from the languages that have generics in 
>>> it.
>>> - A little copying is better than having a big feature in the language.
>>> - Using generics everywhere is more of a design choice than a necessity.
>>>
>>>
>>> *A language that doesn’t have everything is actually easier to program 
>>> in than some that do. (Dennis Ritchie).*
>>>
>>> I wrote many different types of software in C. A country wide (a big 
>>> one) server, two AV engines for two major AV companies etc. I needed 
>>> generics only few times, but i could handle it in C without using smart 
>>> tricks. In Go however, there are much safer, better and elegant solutions 
>>> to achieve the same results. Do we really need a big feature for it?
>>>
>>> I didn't hear a complaint about the lack of generics in Go from a C 
>>> programmer, although i'm sure there are. 
>>> Maybe java programmers use generics more than they are supposed to. 
>>> Maybe they should stop writing java in Go. I am confident that they would 
>>> abuse generics if Go had one.
>>>
>>> That brings me to my point.
>>>
>>> I believe that generics would divide the Go community.
>>>
>>> It's well known that everybody uses a subset of C++ language. Google 
>>> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
>>> C++ in my last company and i felt the pain.
>>>
>>> Rob Pike himself talked about it. 
>>> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>>>
>>> Now Go is unique because people come to Go from all kind of different 
>>> languages, (javascript, Python, C,...). see 
>>> https://blog.golang.org/survey2016-results
>>>
>>> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
>>> will look alien to Go 1 programmers. Some people will not use generics at 
>>> all while others overuse it.
>>>
>>> For a language like Go, this is disastrous because it's against Go's 
>>> philosophy. I love gofmt because it enforces a standart format and saves 
>>> our time of debating about indention and other things. What good it is to 
>>> have a standard format while you have completely different programming 
>>> styles.
>>>
>>> Dear Go experts;
>>>
>>> Please provide some best practices to achieve generic behavior for the 
>>> most common cases, instead of implementing Generics in Go.
>>>
>>> Let's end this debate and help keeping Go small and simple. It's the 
>>> real virtue of Go. 
>>>
>>> Thanks.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Roberto Zanotto]

I love playing with package reflect, which is much more powerful than 
generics by the way (you can't implement gob or json with generics).

On Saturday, July 29, 2017 at 3:28:56 PM UTC+2, M P r a d e s wrote:
>
> What is overrated is the use of "interface { }" and reflection AKA runtime 
> magics which has no place in a modern statically typed language. It's a 
> cop-out, it's dirty and a direct consequence of the absence of generics in 
> Go.
>
> > Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> You cannot achieve generic behavior without some form of generics. Look at 
> sync.Map it's not compile time type safe. With generics it would be. 
>
>
>
> Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a 
> écrit :
>>
>> *Everything in this thread is my personal opinions, they are not 
>> necessarily the truth.*
>>
>> My main language was C for a decade. I also liked Python. When i started 
>> learning Go, it almost felt like i knew the language in another life. 
>> Everything was so obvious.
>>
>> CSP model of concurrency was new to me though. Interfaces were more 
>> familiar due to unix's open,close,read,write interface, which is the 
>> greatest idea.
>>
>> I didn't use generics or templates much (it's kind of stupid for me to 
>> talk about it's necessity), therefore this is more like a meta-research.
>>
>> - Go developers created a great standard library and many great software 
>> without generics in the language.
>> - Many companies switched to Go from the languages that have generics in 
>> it.
>> - A little copying is better than having a big feature in the language.
>> - Using generics everywhere is more of a design choice than a necessity.
>>
>>
>> *A language that doesn’t have everything is actually easier to program in 
>> than some that do. (Dennis Ritchie).*
>>
>> I wrote many different types of software in C. A country wide (a big one) 
>> server, two AV engines for two major AV companies etc. I needed generics 
>> only few times, but i could handle it in C without using smart tricks. In 
>> Go however, there are much safer, better and elegant solutions to achieve 
>> the same results. Do we really need a big feature for it?
>>
>> I didn't hear a complaint about the lack of generics in Go from a C 
>> programmer, although i'm sure there are. 
>> Maybe java programmers use generics more than they are supposed to. Maybe 
>> they should stop writing java in Go. I am confident that they would abuse 
>> generics if Go had one.
>>
>> That brings me to my point.
>>
>> I believe that generics would divide the Go community.
>>
>> It's well known that everybody uses a subset of C++ language. Google 
>> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
>> C++ in my last company and i felt the pain.
>>
>> Rob Pike himself talked about it. 
>> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>>
>> Now Go is unique because people come to Go from all kind of different 
>> languages, (javascript, Python, C,...). see 
>> https://blog.golang.org/survey2016-results
>>
>> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
>> will look alien to Go 1 programmers. Some people will not use generics at 
>> all while others overuse it.
>>
>> For a language like Go, this is disastrous because it's against Go's 
>> philosophy. I love gofmt because it enforces a standart format and saves 
>> our time of debating about indention and other things. What good it is to 
>> have a standard format while you have completely different programming 
>> styles.
>>
>> Dear Go experts;
>>
>> Please provide some best practices to achieve generic behavior for the 
>> most common cases, instead of implementing Generics in Go.
>>
>> Let's end this debate and help keeping Go small and simple. It's the real 
>> virtue of Go. 
>>
>> Thanks.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jan Mercl]

On Sat, Jul 29, 2017 at 3:28 PM  wrote:

> What is overrated is the use of "interface { }" and reflection AKA
runtime magics which has no place in a modern statically typed language.

interface{} is not a replacement of generics. Interfaces with a real
methods set, like sort.Interface sometimes are.

> It's a cop-out, it's dirty and a direct consequence of the absence
of generics in Go.

Not true. interface{} and reflection is, for example, used by fmt.Printf
for purpose where generics won't help. Alternatively everything must have a
Format() method. But predeclared types cannot have methods.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[prades . marq]

What is overrated is the use of "interface { }" and reflection AKA runtime 
magics which has no place in a modern statically typed language. It's a 
cop-out, it's dirty and a direct consequence of the absence of generics in 
Go.

> Please provide some best practices to achieve generic behavior for the 
most common cases, instead of implementing Generics in Go.

You cannot achieve generic behavior without some form of generics. Look at 
sync.Map it's not compile time type safe. With generics it would be. 



Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a écrit :
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely different programming 
> styles.
>
> Dear Go experts;
>
> Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> Let's end this debate and help keeping Go small and simple. It's the real 
> virtue of Go. 
>
> Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.