Re: [go-nuts] Re: Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

Hi,

On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:

> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
>

• "Only one generic type" means you can't write generic maps or graph
structures
• "Without constraints" means compilation cost goes up significantly (as
the compiler needs to completely redo type-checking and compilation for
each instantiation - instead of only checking that the function adheres to
the constraints and the type-arguments fulfill it at each call-site. i.e.
you make an NxM problem out of an N+M problem). It also makes good error
messages very hard. And the constraints need to be documented anyway (in a
comment, if nothing else), so that the user knows how to call the function
- might as well have a standardized, machine-checkable way to express that.

So even *if* we only consider containers, the complexity of the design
isn't accidental. There are very concrete (and IMO important) advantages to
these decisions.

That being said, I also, personally, don't consider type-safe containers
the main use-case of generics. It's certainly *one*, and one that can't be
solved without them. I definitely see the advantage of being able to
implement complex data-structures like lock-free concurrent maps or sorted
maps as a library and use them in really performance-sensitive code-paths.
But I also feel that my concerns about generics mainly stem from
experiences with Java and C++ where *everything* was expressed in terms of
abstract generic containers and algorithms, cluttering the code and
requiring you to understand subtle differences between different
implementations of the implementations of the abstract versions. So,
personally, I really hope containers are *not* 95% of the use-case of
generics. In fact, if type-safe containers *where* 95% of the use-case, I
would still be very much opposed to adding generics - I don't think we
really *need* type-safety for containers, as we are usually very well aware
of what's stored in them.

Personally, the main use-case for generics I see (and I want to emphasize
that everyone sees different use-cases as more or less important, depending
on what kind of code they write) is the ability for concurrency as a
library. I think channels and goroutines are great concurrency primitives -
but they are primitives, that need to be composed to be useful. And this
composition is usually very subtle and hard to get right. So being able to
solve these composition problems once and re-use that solution, seems very
exciting to me. But, again, that focus comes from the kind of code I write.

The third use-case I see for generics is to catch bugs by being able to
express more complicated type-invariants in code. An example of that would
be type-safety for context.Value
 (or,
similarly but subtly different, optional interfaces of
http.ResponseWriter). However, for this use-case, I personally don't see
the value-add vs. complexity tradeoff

as very favorable - the type-system needs a *lot* more power to catch
significantly more bugs and more power translates into a lot of complexity.
I don't think the current draft lets us express very powerful invariants.
And while I wouldn't really advocate to make that a target, I think it
would be interesting to see more discussion of this area - i.e. more
case-studies of where Go has type-safety problems and if the current design
can address them.


> func add(x, y GenericType) GenericType {
>   return x + y
> }
>
> add(1,2) // add can compile : func add(x, y int) is generated
> add("abc", "def") // can compile : func add(x, y string) is generated
>
> add(1, "abc") // two differents type : error
>
> GenericType will be like interface{} but instead of casting it'll
> generate on the fly, at compile time the function with the type of each
> functions call.
> I believe it's too easy and i miss something already discussed...
>
> --
> wilk
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/rsk0bb%24tg6%241%40ciao.gmane.io
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGDOqWgEE2a_B9%2BqXftPc6ebBPcs_DcpsrqOvR%2BpCZ9SQ%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

Hi,
ok, so please read it finally and tell which point exactly you think was
against CoC and in what of my messages and in which exact thread, but do
not put my words out of context. And explain why you responded just now,
and to my message to a person who obviously *violated* its terms by
aggressively turning to my personality.

Do you protect this aggressive behavior just because you pro-generics and
silently hate everything I will say (and me personally)? Because if you do,
it's quite stupid. But I hope it's not.


чт, 31 дек. 2020 г. в 07:51, Tyler Compton :

> Space A,
>
>
>> So switching from subject to my personality and telling me what I should
>> and what shouldn't, to whom to listen, and what to read is something in
>> line with "code of conduct" which you appeal as the argument of last resort?
>>
>
> I've seen how you carry yourself on this list, and you really should read
> the code of conduct. I think your arguments would gain quite a bit more
> traction on this list if you presented them in a more respectful way.
>
> On Wed, Dec 30, 2020 at 3:47 PM Space A.  wrote:
>
>> Nice.
>>
>> > You should listen to people who have been doing this much longer than
>> you
>> Thanks, are you sure you know for how long I've been doing *this* to be
>> able to compare?
>> > before discarding all their points as "bullshit"
>> Have *you* actually read and listened because this is not what I've said?
>> > and you should probably review the community code of conduct
>> So switching from subject to my personality and telling me what I should
>> and what shouldn't, to whom to listen, and what to read is something in
>> line with "code of conduct" which you appeal as the argument of last resort?
>>
>>
>> This was actually my first comment on this particular topic. So yea, I
>> read and listened before replying. I could have replied to everyone and
>> explained in detail, but I value the time of my opponents. And my own time,
>> tbh.
>>
>>
>> чт, 31 дек. 2020 г. в 00:03, David Riley :
>>
>>> This topic has shown little other than that a few people here are
>>> unwilling to consider points of view other than their own and declare that
>>> very real problems are not real.
>>>
>>> You should listen to people who have been doing this much longer than
>>> you have before discarding all their points as "bullshit", and you should
>>> probably review the community code of conduct.
>>>
>>> If you've got nothing constructive to contribute, why bother?
>>>
>>>
>>> - Dave
>>>
>>>
>>> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
>>> >
>>> > "runtime type-casting"
>>> > "type safety something"
>>> > "boilerplate"
>>> > "amount of code"
>>> > "benefit something"
>>> > "greatly simplified" (for whom?)
>>> >
>>> > This topic has clearly shown that most people pro-generic have no
>>> *real world* problems that they struggle to solve, yet most of them don't
>>> even understand what *real world* problems are.
>>>
>>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTeXFD8WoGeS4H1OwXnu5N0f-LqcUBGJmUYiCj3BWACkTA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Kevin Chadwick]

On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> I don't think this is accurate.  Surveys express a clear and
> consistent desire for generics that is far ahead of requests for
> operator overloading or other language features.  (To avoid
> misunderstanding I'll say again that changes to the Go language are
> not driven by polls.)

Firstly, I appreciate that dev is not driven by polls but it may be that
internally to Google these desires are true too. It is natural to be less likely
to get an honest answer from many employees, of course.

If Generics is something wanted by the designers without or little debate aside
from the form, then just say so and end the discussion?

One thing brought up in a recent thread is that a past user of Generics in other
languages has found over time he has changed his mind/bias and now prefers his
code without them.

The existence of generics in other languages has likely increased the chances of
this request. Familiarity bias.

Also, whilst understanding that voluntary submission has it's benefits in terms
of avoiding suggestion; that data has already been acquired. I wonder what the
result would be given a number of options. I probably can't think of many of the
good requests, so this could be fuelled by past submissions. I can't remember
hitting a null pointer in my code but certainly have in stdlib network libraries
(missing an & etc.)


Null pointer panic avoidance via automatic error return (what happened before
panics?)

enhanced Gomobile support

enhanced tinygo support

Generics

Flutter, Go cooperation

...

No changes


p.s.

Personally, whilst I respect that I need to account for my familiarity bias. I
feel that Go already has some small rough edges, due to influences and
familiarity bias from some largely frontend languages.

Thank You all for my favourite language and Happy New Year!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2fdc3328-b65a-9de3-b9ba-75e9973cc20b%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Martin Schnabel]

hi Space,

i do not care about this discussion in general and learned to trust the 
go developers to be thoughtful and reasonable.


i wouldn't write this normally, but in case you are not aware it might 
actually help: i did read the last couple of your messages to this list 
again and came to the conclusion that i would not want to enter into a 
discussion with you based on the general tone of your messages, 
regardless of argument or subject.


i don't mean any disrespect. the advice by Tyler is well meaning and 
will certainly be good to follow generally and by everyone:


"I think your arguments would gain quite a bit more traction on this 
list if you presented them in a more respectful way."


a good exercise would be to review your messages from a different point 
of view. read them as if addressed to you and decide whether you would 
want to reply yourself.


anyway, have a happy new year everyone!

On 31.12.20 13:55, Space A. wrote:

Hi,
ok, so please read it finally and tell which point exactly you think was 
against CoC and in what of my messages and in which exact thread, but do 
not put my words out of context. And explain why you responded just now, 
and to my message to a person who obviously *violated* its terms by 
aggressively turning to my personality.


Do you protect this aggressive behavior just because you pro-generics 
and silently hate everything I will say (and me personally)? Because if 
you do, it's quite stupid. But I hope it's not.



чт, 31 дек. 2020 г. в 07:51, Tyler Compton >:


Space A,

So switching from subject to my personality and telling me what
I should and what shouldn't, to whom to listen, and what to read
is something in line with "code of conduct" which you appeal as
the argument of last resort?


I've seen how you carry yourself on this list, and you really should
read the code of conduct. I think your arguments would gain quite a
bit more traction on this list if you presented them in a more
respectful way.

On Wed, Dec 30, 2020 at 3:47 PM Space A. mailto:reexist...@gmail.com>> wrote:

Nice.

 > You should listen to people who have been doing this much
longer than you
Thanks, are you sure you know for how long I've been doing
*this* to be able to compare?
 > before discarding all their points as "bullshit"
Have *you* actually read and listened because this is not what
I've said?
 > and you should probably review the community code of conduct
So switching from subject to my personality and telling me what
I should and what shouldn't, to whom to listen, and what to read
is something in line with "code of conduct" which you appeal as
the argument of last resort?


This was actually my first comment on this particular topic. So
yea, I read and listened before replying. I could have replied
to everyone and explained in detail, but I value the time of my
opponents. And my own time, tbh.


чт, 31 дек. 2020 г. в 00:03, David Riley mailto:fraveyd...@gmail.com>>:

This topic has shown little other than that a few people
here are unwilling to consider points of view other than
their own and declare that very real problems are not real.

You should listen to people who have been doing this much
longer than you have before discarding all their points as
"bullshit", and you should probably review the community
code of conduct.

If you've got nothing constructive to contribute, why bother?


- Dave


 > On Dec 30, 2020, at 3:53 PM, Space A.
mailto:reexist...@gmail.com>> wrote:
 >
 > "runtime type-casting"
 > "type safety something"
 > "boilerplate"
 > "amount of code"
 > "benefit something"
 > "greatly simplified" (for whom?)
 >
 > This topic has clearly shown that most people pro-generic
have no *real world* problems that they struggle to solve,
yet most of them don't even understand what *real world*
problems are.

-- 
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
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com

.

--
You rec

[go-nuts] Linux distro..based only on GO

[L Godioleskky]

All Linux distros are currently based on several languages (Python, Perl, 
C/ C++ etc) as well as tool-type packages like GTK etc

... What if, there was a Linux distro based entirely on GO ?
This would greatly reduce the Linux footprint given the  huge number of 
libraries Linux currently uses to support each language.

It seems to me a Linux distro based entirely on GO would be another major 
GO milestone.  
Is this do-able given the current capability of GO?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/95de7ec1-4932-4bca-9f33-4def9a023988n%40googlegroups.com.

Re: [go-nuts] Linux distro..based only on GO

[Kevin Chadwick]

On 12/31/20 3:26 PM, L Godioleskky wrote:
> 
> It seems to me a Linux distro based entirely on GO would be another major GO
> milestone.  
> Is this do-able given the current capability of GO?
> 

It would seem not, unless you throw the unix philosophy out of the window
completely wrt one tool, one job.

You would likely need cgo for anything graphical currently, anyway.

I suppose the best you could do right now with build size, would be a console
system, busybox style. Calling e.g. cut, sed as command strings from one large
binary. Perhaps the package manager could build the binary based on command
selections?

Alternatively, perhaps tinygo could be used to create small binaries and keep
the unix phlosophy and packaging.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bca69fb7-1254-5063-7f44-bda1d4038edc%40gmail.com.

Re: [go-nuts] Linux distro..based only on GO

[Sebastien Binet]

I believe that's what u-root is:

- https://github.com/u-root/u-root

there are probably others.


‐‐‐ Original Message ‐‐‐

On Thursday, December 31st, 2020 at 4:40 PM, Kevin Chadwick 
 wrote:

> On 12/31/20 3:26 PM, L Godioleskky wrote:
>
> > It seems to me a Linux distro based entirely on GO would be another major GO
> >
> > milestone.  
> >
> > Is this do-able given the current capability of GO?
>
> It would seem not, unless you throw the unix philosophy out of the window
>
> completely wrt one tool, one job.
>
> You would likely need cgo for anything graphical currently, anyway.
>
> I suppose the best you could do right now with build size, would be a console
>
> system, busybox style. Calling e.g. cut, sed as command strings from one large
>
> binary. Perhaps the package manager could build the binary based on command
>
> selections?
>
> Alternatively, perhaps tinygo could be used to create small binaries and keep
>
> the unix phlosophy and packaging.
>
> ---
>
> 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.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/bca69fb7-1254-5063-7f44-bda1d4038edc%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/gCGThroqkQAlWUfHwxNUSbswBIQGrxsN_Pj6s2bDZ7yuTUP2I8F5UgIqOZi4BsyEFDEXmGkH2MO-Iyd1rayc57gIr7bs02YVsH0G7LvUU_E%3D%40sbinet.org.

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

95% was a recalled-guess. I previously linked to an academic paper that studied 
uses of generics in Java, and I believe that was the number - regardless it was 
a very, very high percentage.

Interestingly, I had a previous client that was a case-study in generics gone 
wrong. No kidding, they had created Couple..Sextuple using generics, so you 
would read code that literally looked like this.

x = new 
Sextuple,Integer,Pair>,Boolean>

Then you would put these in a generic map… Ugh. Prior to generics no one would 
of thought of doing something like this - they would have declared concrete 
classes, and container wrappers - similar to Go.

I’ll state for the record again, I was originally very dismayed that Go did not 
offer generics - after developing with it for a while that is far less of an 
issue to me than the error handling. I think the generics can be reasonably 
better solved by external code generators and go:generate - there are 
alternatives to “generics” as a language change.

> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> Hi,
> 
> On Thu, Dec 31, 2020 at 8:59 AM wilk  > wrote:
> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
> 
> • "Only one generic type" means you can't write generic maps or graph 
> structures
> • "Without constraints" means compilation cost goes up significantly (as the 
> compiler needs to completely redo type-checking and compilation for each 
> instantiation - instead of only checking that the function adheres to the 
> constraints and the type-arguments fulfill it at each call-site. i.e. you 
> make an NxM problem out of an N+M problem). It also makes good error messages 
> very hard. And the constraints need to be documented anyway (in a comment, if 
> nothing else), so that the user knows how to call the function - might as 
> well have a standardized, machine-checkable way to express that.
> 
> So even *if* we only consider containers, the complexity of the design isn't 
> accidental. There are very concrete (and IMO important) advantages to these 
> decisions.
> 
> That being said, I also, personally, don't consider type-safe containers the 
> main use-case of generics. It's certainly *one*, and one that can't be solved 
> without them. I definitely see the advantage of being able to implement 
> complex data-structures like lock-free concurrent maps or sorted maps as a 
> library and use them in really performance-sensitive code-paths. But I also 
> feel that my concerns about generics mainly stem from experiences with Java 
> and C++ where *everything* was expressed in terms of abstract generic 
> containers and algorithms, cluttering the code and requiring you to 
> understand subtle differences between different implementations of the 
> implementations of the abstract versions. So, personally, I really hope 
> containers are *not* 95% of the use-case of generics. In fact, if type-safe 
> containers *where* 95% of the use-case, I would still be very much opposed to 
> adding generics - I don't think we really *need* type-safety for containers, 
> as we are usually very well aware of what's stored in them.
> 
> Personally, the main use-case for generics I see (and I want to emphasize 
> that everyone sees different use-cases as more or less important, depending 
> on what kind of code they write) is the ability for concurrency as a library. 
> I think channels and goroutines are great concurrency primitives - but they 
> are primitives, that need to be composed to be useful. And this composition 
> is usually very subtle and hard to get right. So being able to solve these 
> composition problems once and re-use that solution, seems very exciting to 
> me. But, again, that focus comes from the kind of code I write.
> 
> The third use-case I see for generics is to catch bugs by being able to 
> express more complicated type-invariants in code. An example of that would be 
> type-safety for context.Value 
>  (or, similarly 
> but subtly different, optional interfaces of http.ResponseWriter). However, 
> for this use-case, I personally don't see the value-add vs. complexity 
> tradeoff 
> 
>  as very favorable - the type-system needs a *lot* more power to catch 
> significantly more bugs and more power translates into a lot of complexity.
> I don't think the current draft lets us express very powerful invariants. And 
> while I wouldn't really advocate to make that a target, I think it would be 
> interesting to see more discussion of this area - i.e. more case-studies of 
> where Go has type-safety problems and if the current design can address them.
> 
> 
> func add(x, y GenericType) GenericType {
>   return x + y

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Thu, Dec 31, 2020 at 5:46 PM robert engels  wrote:

> I’ll state for the record again, I was originally very dismayed that Go
> did not offer generics - after developing with it for a while that is far
> less of an issue to me than the error handling.
>

Just to illustrate that the plural of "anecdote" isn't "data": I was
originally very vehemently opposed to generics in Go, but after using Go
for a bunch of years, I've been missing them often enough that I think they
provide a net-benefit (despite my criticism of this specific design).

Generics just isn't a "if you use Go long enough you learn they are not
important" thing.


> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> Hi,
>
> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
>>
>
> • "Only one generic type" means you can't write generic maps or graph
> structures
> • "Without constraints" means compilation cost goes up significantly (as
> the compiler needs to completely redo type-checking and compilation for
> each instantiation - instead of only checking that the function adheres to
> the constraints and the type-arguments fulfill it at each call-site. i.e.
> you make an NxM problem out of an N+M problem). It also makes good error
> messages very hard. And the constraints need to be documented anyway (in a
> comment, if nothing else), so that the user knows how to call the function
> - might as well have a standardized, machine-checkable way to express that.
>
> So even *if* we only consider containers, the complexity of the design
> isn't accidental. There are very concrete (and IMO important) advantages to
> these decisions.
>
> That being said, I also, personally, don't consider type-safe containers
> the main use-case of generics. It's certainly *one*, and one that can't be
> solved without them. I definitely see the advantage of being able to
> implement complex data-structures like lock-free concurrent maps or sorted
> maps as a library and use them in really performance-sensitive code-paths.
> But I also feel that my concerns about generics mainly stem from
> experiences with Java and C++ where *everything* was expressed in terms of
> abstract generic containers and algorithms, cluttering the code and
> requiring you to understand subtle differences between different
> implementations of the implementations of the abstract versions. So,
> personally, I really hope containers are *not* 95% of the use-case of
> generics. In fact, if type-safe containers *where* 95% of the use-case, I
> would still be very much opposed to adding generics - I don't think we
> really *need* type-safety for containers, as we are usually very well aware
> of what's stored in them.
>
> Personally, the main use-case for generics I see (and I want to emphasize
> that everyone sees different use-cases as more or less important, depending
> on what kind of code they write) is the ability for concurrency as a
> library. I think channels and goroutines are great concurrency primitives -
> but they are primitives, that need to be composed to be useful. And this
> composition is usually very subtle and hard to get right. So being able to
> solve these composition problems once and re-use that solution, seems very
> exciting to me. But, again, that focus comes from the kind of code I write.
>
> The third use-case I see for generics is to catch bugs by being able to
> express more complicated type-invariants in code. An example of that would
> be type-safety for context.Value
>  (or,
> similarly but subtly different, optional interfaces of
> http.ResponseWriter). However, for this use-case, I personally don't see the
>  value-add vs. complexity tradeoff
> 
>  as very favorable - the type-system needs a *lot* more power to catch
> significantly more bugs and more power translates into a lot of complexity.
> I don't think the current draft lets us express very powerful invariants.
> And while I wouldn't really advocate to make that a target, I think it
> would be interesting to see more discussion of this area - i.e. more
> case-studies of where Go has type-safety problems and if the current design
> can address them.
>
>
>> func add(x, y GenericType) GenericType {
>>   return x + y
>> }
>>
>> add(1,2) // add can compile : func add(x, y int) is generated
>> add("abc", "def") // can compile : func add(x, y string) is generated
>>
>> add(1, "abc") // two differents type : error
>>
>> GenericType will be like interface{} but instead of casting it'll
>> generate on the fly, at compile time the function with the type of each
>> functions call.
>> I believe it's too easy and i mis

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

Go has been in existence for 10+ years and has fairly wide adoption in some 
areas - so it is not hard to make the case that generics are “not an important 
thing” - depends on what you are trying to do with it and what your perspective 
on “the right way” is.


> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> On Thu, Dec 31, 2020 at 5:46 PM robert engels  > wrote:
> I’ll state for the record again, I was originally very dismayed that Go did 
> not offer generics - after developing with it for a while that is far less of 
> an issue to me than the error handling.
> 
> Just to illustrate that the plural of "anecdote" isn't "data": I was 
> originally very vehemently opposed to generics in Go, but after using Go for 
> a bunch of years, I've been missing them often enough that I think they 
> provide a net-benefit (despite my criticism of this specific design).
> 
> Generics just isn't a "if you use Go long enough you learn they are not 
> important" thing.
> 
> 
>> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> wrote:
>> 
>> Hi,
>> 
>> On Thu, Dec 31, 2020 at 8:59 AM wilk > > wrote:
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
>> 
>> • "Only one generic type" means you can't write generic maps or graph 
>> structures
>> • "Without constraints" means compilation cost goes up significantly (as the 
>> compiler needs to completely redo type-checking and compilation for each 
>> instantiation - instead of only checking that the function adheres to the 
>> constraints and the type-arguments fulfill it at each call-site. i.e. you 
>> make an NxM problem out of an N+M problem). It also makes good error 
>> messages very hard. And the constraints need to be documented anyway (in a 
>> comment, if nothing else), so that the user knows how to call the function - 
>> might as well have a standardized, machine-checkable way to express that.
>> 
>> So even *if* we only consider containers, the complexity of the design isn't 
>> accidental. There are very concrete (and IMO important) advantages to these 
>> decisions.
>> 
>> That being said, I also, personally, don't consider type-safe containers the 
>> main use-case of generics. It's certainly *one*, and one that can't be 
>> solved without them. I definitely see the advantage of being able to 
>> implement complex data-structures like lock-free concurrent maps or sorted 
>> maps as a library and use them in really performance-sensitive code-paths. 
>> But I also feel that my concerns about generics mainly stem from experiences 
>> with Java and C++ where *everything* was expressed in terms of abstract 
>> generic containers and algorithms, cluttering the code and requiring you to 
>> understand subtle differences between different implementations of the 
>> implementations of the abstract versions. So, personally, I really hope 
>> containers are *not* 95% of the use-case of generics. In fact, if type-safe 
>> containers *where* 95% of the use-case, I would still be very much opposed 
>> to adding generics - I don't think we really *need* type-safety for 
>> containers, as we are usually very well aware of what's stored in them.
>> 
>> Personally, the main use-case for generics I see (and I want to emphasize 
>> that everyone sees different use-cases as more or less important, depending 
>> on what kind of code they write) is the ability for concurrency as a 
>> library. I think channels and goroutines are great concurrency primitives - 
>> but they are primitives, that need to be composed to be useful. And this 
>> composition is usually very subtle and hard to get right. So being able to 
>> solve these composition problems once and re-use that solution, seems very 
>> exciting to me. But, again, that focus comes from the kind of code I write.
>> 
>> The third use-case I see for generics is to catch bugs by being able to 
>> express more complicated type-invariants in code. An example of that would 
>> be type-safety for context.Value 
>>  (or, similarly 
>> but subtly different, optional interfaces of http.ResponseWriter). However, 
>> for this use-case, I personally don't see the value-add vs. complexity 
>> tradeoff 
>> 
>>  as very favorable - the type-system needs a *lot* more power to catch 
>> significantly more bugs and more power translates into a lot of complexity.
>> I don't think the current draft lets us express very powerful invariants. 
>> And while I wouldn't really advocate to make that a target, I think it would 
>> be interesting to see more discussion of this area - i.e. more case-studies 
>> of where Go has 

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

> hi Space, 
Hey,

> i do not care about this discussion in general 
> i would not want to enter into a discussion with you 

So it's up to you, isn't it? Should I invite you? Or maybe anyone else 
should? I don't know you and don't care about your existence (as you said, 
I don't mean any disrespect, just a fact). I would say that in my 
experience whether you or anyone else enters a discussion depends on 
whether you have anything in mind, on the subject and appropriate 
arguments, or not. Interestingly, but nobody in this and adjacent thread 
who set him(-her)self against generics didn't attempt any personal attack. 
And in this thread you're 3rd person who have nothing to say in general, 
but a lot to say about me. =) Not knowing me at all, even my name. 

So have you read my comment, do you have any arguments regarding my point 
that most of people here who are pro-generics don't understand what *real 
world* problems are and not facing this class of problems? Lets' talk about 
this. All of this (copied):
> > "runtime type-casting" 
> > "type safety something" 
> > "boilerplate" 
> > "amount of code" 
> > "benefit something" 
> > "greatly simplified" (for whom?) 

translates to not more than just a simple implication that "generics are 
better". As simple as that. So the problems people trying to "solve" are a 
kind of very general, imaginary and ephemeral things like:
"generics are better than runtime"
"generics are better than interfaces"
"generics produces less code which is better"
"generics produces smarter code" (Clear is better than clever? No, never 
heard!)
 "generics gives better performance"
etc

and so one so forth. Which are just not correct.

*Not* *a* *single* *real* *world* *problem* in any of presented case. Did I 
miss one? Please point on it! So why shouldn't I or anyone else say it's a 
*bullshit* after all (but I didn't)? After all your attacks?

And all you can say: "i would not want to enter into a discussion with you 
based on the general tone of your messages, regardless of argument or 
subject ". 

Ok, do not.


четверг, 31 декабря 2020 г. в 17:58:24 UTC+3, mb0: 

> hi Space, 
>
> i do not care about this discussion in general and learned to trust the 
> go developers to be thoughtful and reasonable. 
>
> i wouldn't write this normally, but in case you are not aware it might 
> actually help: i did read the last couple of your messages to this list 
> again and came to the conclusion that i would not want to enter into a 
> discussion with you based on the general tone of your messages, 
> regardless of argument or subject. 
>
> i don't mean any disrespect. the advice by Tyler is well meaning and 
> will certainly be good to follow generally and by everyone: 
>
> "I think your arguments would gain quite a bit more traction on this 
> list if you presented them in a more respectful way." 
>
> a good exercise would be to review your messages from a different point 
> of view. read them as if addressed to you and decide whether you would 
> want to reply yourself. 
>
> anyway, have a happy new year everyone! 
>
> On 31.12.20 13:55, Space A. wrote: 
> > Hi, 
> > ok, so please read it finally and tell which point exactly you think was 
> > against CoC and in what of my messages and in which exact thread, but do 
> > not put my words out of context. And explain why you responded just now, 
> > and to my message to a person who obviously *violated* its terms by 
> > aggressively turning to my personality. 
> > 
> > Do you protect this aggressive behavior just because you pro-generics 
> > and silently hate everything I will say (and me personally)? Because if 
> > you do, it's quite stupid. But I hope it's not. 
> > 
> > 
> > чт, 31 дек. 2020 г. в 07:51, Tyler Compton  > >: 
> > 
> > Space A, 
> > 
> > So switching from subject to my personality and telling me what 
> > I should and what shouldn't, to whom to listen, and what to read 
> > is something in line with "code of conduct" which you appeal as 
> > the argument of last resort? 
> > 
> > 
> > I've seen how you carry yourself on this list, and you really should 
> > read the code of conduct. I think your arguments would gain quite a 
> > bit more traction on this list if you presented them in a more 
> > respectful way. 
> > 
> > On Wed, Dec 30, 2020 at 3:47 PM Space A.  > > wrote: 
> > 
> > Nice. 
> > 
> > > You should listen to people who have been doing this much 
> > longer than you 
> > Thanks, are you sure you know for how long I've been doing 
> > *this* to be able to compare? 
> > > before discarding all their points as "bullshit" 
> > Have *you* actually read and listened because this is not what 
> > I've said? 
> > > and you should probably review the community code of conduct 
> > So switching from subject to my personality and telling me what 
> > I should and what shouldn't, to whom to listen, and what to read 
> > is something in line with "code of conduct" whi

[go-nuts] Signature Switch - third path to Go generics

[Wojciech S. Czarnecki]

I regard current Team's proposal a way better than the first iteration. But -
while I see a need for generic way to write common code, I also share
concerns about readability and future abuse of the materialized Go generics
being similar to "the other languages". I consciously did not patricipate in 
the 
[Generics, please go 
away!](https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo)
bikeshed, but I would like to share an idea that may possibly reconcile both 
camps.

   "Signature switch" - readable generic code preserving the Go way.

Generic function declaration is 
https://golang.org/ref/spec#Function_declarations
with at least one type in the Signature given as the ascii character "+" 
followed
by single capital ascii letter, further reffered to as "TypeLetter"; and with a 
single,
non empty, signature switch present in the function body:

func f (x +T) (r +R) {  // generic function
switch func.(type) {  // Signature Switch here. Resolves at COMPILE 
TIME.
case func(x int) (r int): // call-site signature to match
r = x/2 // instantiated code, T and R are now 
ints
}
return r
}

More to read at: https://play.golang.org/p/Q1ry4KPoOOJ

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20201231193635.0d27177a%40xmint.

Re: [go-nuts] Linux distro..based only on GO

[Wendell Hatcher]

no

On Thu, Dec 31, 2020, 10:26 AM L Godioleskky  wrote:

> All Linux distros are currently based on several languages (Python, Perl,
> C/ C++ etc) as well as tool-type packages like GTK etc
>
> ... What if, there was a Linux distro based entirely on GO ?
> This would greatly reduce the Linux footprint given the  huge number of
> libraries Linux currently uses to support each language.
>
> It seems to me a Linux distro based entirely on GO would be another major
> GO milestone.
> Is this do-able given the current capability of GO?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/95de7ec1-4932-4bca-9f33-4def9a023988n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKXhZzzeaTM4abODkW9mnsPcXnmP10_%3Dm9TJbh7Mf7gbOoxeOA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[roger peppe]

Here's one real life example that I came across recently.

I have a CRUD API that supports a bunch of different entity types. They all
support a superset of the same operations.
Each method represents a single HTTP call.

If the generics proposal was implemented, I'd be able to define a common
interface between them all.
Something like this:

type CRUD[Entity any] interface {
Find(ctx context.Context, filter Filter) ([]Entity, error)
FindOne(ctx context.Context, filter Filter) ([]Entity,
error)
Create(ctx context.Context, entity Entity) (Entity, error)
Update(ctx context.Context, entity Entity) (Entity, error)
Delete(ctx context.Context, id string) error
}

The Find operation allows the specification of a start-count window of
results to return.
It would be really nice to be able to define a generic function like this:

func FindAll[Entity any](api CRUD[Entity], filter Filter) ([]Entity,
error)

which would iterate return a slice of all the entities regardless of how
many underlying
calls to Find are needed.

Currently I can't easily do that. I could change the methods so that they
just returned interface
values instead of the respective entity types, but that would make the API
harder and more
error-prone to use. I could use reflection, but that code would be even
harder to read and maintain.

Currently I might end up using code generation, but that has its own issues
(I'd have to write
a code generator, or use some kind of template scheme, in which case the
actual source wouldn't
be amenable to gofmt and static checking).

  cheers,
rog.

On Thu, 24 Dec 2020 at 06:15, Martin Hanson 
wrote:

> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgachY138vaOHWp90Zg6xV6QcqkTAhajGxXPCHWUQeaaz5kg%40mail.gmail.com.

Re: [go-nuts] Signature Switch - third path to Go generics

[K. Alex Mills]

At a glance, this feels to me like it is more complicated than the current
generics proposal. That said, it also seems very original so I have to give
credit there.

This proposal seems to put the responsibility for monomorphizing generic
code onto the programmer. I'm not sure why it would be simpler than
monomorphizing generic functions directly, which we can do today. Although
I guess under this proposal all the monomorphized versions would be able to
share similar function signatures and we can't do that today.

I do worry that in case you have two generic parameters, this proposal
would seem to require NxM cases to be explicitly written out. That feels
like a lot of work as compared to the current proposal, in which the
compiler can inspect the callsites and automatically generate only the
binary code needed to satisfy the types in use.


On Thu, Dec 31, 2020, 12:37 PM Wojciech S. Czarnecki 
wrote:

> I regard current Team's proposal a way better than the first iteration.
> But -
> while I see a need for generic way to write common code, I also share
> concerns about readability and future abuse of the materialized Go generics
> being similar to "the other languages". I consciously did not patricipate
> in the
> [Generics, please go away!](
> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo)
> bikeshed, but I would like to share an idea that may possibly reconcile
> both camps.
>
>"Signature switch" - readable generic code preserving the Go way.
>
> Generic function declaration is
> https://golang.org/ref/spec#Function_declarations
> with at least one type in the Signature given as the ascii character "+"
> followed
> by single capital ascii letter, further reffered to as "TypeLetter"; and
> with a single,
> non empty, signature switch present in the function body:
>
> func f (x +T) (r +R) {  // generic function
> switch func.(type) {  // Signature Switch here. Resolves at
> COMPILE TIME.
> case func(x int) (r int): // call-site signature to match
> r = x/2 // instantiated code, T and R are
> now ints
> }
> return r
> }
>
> More to read at: https://play.golang.org/p/Q1ry4KPoOOJ
>
> Hope this helps,
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20201231193635.0d27177a%40xmint
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALJzkY9EhOqhLYvXm2f7UV4WhQJWDBPB2O4PfbyYSTniP%2BqMRg%40mail.gmail.com.

Re: [go-nuts] Signature Switch - third path to Go generics

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 10:37 AM Wojciech S. Czarnecki  wrote:
>
> I regard current Team's proposal a way better than the first iteration. But -
> while I see a need for generic way to write common code, I also share
> concerns about readability and future abuse of the materialized Go generics
> being similar to "the other languages". I consciously did not patricipate in 
> the
> [Generics, please go 
> away!](https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo)
> bikeshed, but I would like to share an idea that may possibly reconcile both 
> camps.
>
>"Signature switch" - readable generic code preserving the Go way.
>
> Generic function declaration is 
> https://golang.org/ref/spec#Function_declarations
> with at least one type in the Signature given as the ascii character "+" 
> followed
> by single capital ascii letter, further reffered to as "TypeLetter"; and with 
> a single,
> non empty, signature switch present in the function body:
>
> func f (x +T) (r +R) {  // generic function
> switch func.(type) {  // Signature Switch here. Resolves at 
> COMPILE TIME.
> case func(x int) (r int): // call-site signature to match
> r = x/2 // instantiated code, T and R are now 
> ints
> }
> return r
> }
>
> More to read at: https://play.golang.org/p/Q1ry4KPoOOJ
>
> Hope this helps,

Thanks, it's an interesting idea.

That said, one of the minimal requirements that I think applies to any
generics proposal is the ability to write a compile-time-type-safe
container, such as a concurrent hash map.  It should be possible to
declare a hash map that takes any comparable type as a key type, and
any type as a value type, and provide methods to insert and look up
values in the hash map.  It should be possible to use that hash map
safely without writing any type assertions that might fail at run
time.  I don't see how to do that with this suggestion.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX%3DXmL3GeGKahHVYiLUF8snC0h4cm5R5Fs8H1xZLo6vdg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 4:56 AM Space A.  wrote:
>
> ok, so please read it finally and tell which point exactly you think was 
> against CoC and in what of my messages and in which exact thread, but do not 
> put my words out of context. And explain why you responded just now, and to 
> my message to a person who obviously *violated* its terms by aggressively 
> turning to my personality.
>
> Do you protect this aggressive behavior just because you pro-generics and 
> silently hate everything I will say (and me personally)? Because if you do, 
> it's quite stupid. But I hope it's not.


Let's please take a step back and not try to litigate whether a
comment violates the Code of Conduct.

Please just always remember:  Be friendly.  Be charitable.  Be
respectful.  Criticize ideas, not people.  Even then, avoid saying
that ideas are "stupid."

Thanks.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVmUvCnkgK6yb%2BCxwYOf_M4Lc_YOAOnX7Wbvj8o03whbA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick  wrote:
>
> On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> > I don't think this is accurate.  Surveys express a clear and
> > consistent desire for generics that is far ahead of requests for
> > operator overloading or other language features.  (To avoid
> > misunderstanding I'll say again that changes to the Go language are
> > not driven by polls.)
>
> Firstly, I appreciate that dev is not driven by polls but it may be that
> internally to Google these desires are true too. It is natural to be less 
> likely
> to get an honest answer from many employees, of course.

I'm confident that Google employees are entirely willing to honestly
express their feelings about Go.  There is no company mandate to use
Go, or to like it.  (Of course I have no way to prove this.)  I
haven't seen any reason to think that Google employees are either more
or less likely to prefer adding generics to Go than people outside of
Google.  It's not necessarily obvious, but there are Google employees
on golang-nuts arguing that Go doesn't need generics.


> If Generics is something wanted by the designers without or little debate 
> aside
> from the form, then just say so and end the discussion?

I don't think it's that simple.  For a long time now the Go FAQ has
said "Generics are convenient but they come at a cost in complexity in
the type system and run-time. We haven't yet found a design that gives
value proportionate to the complexity, although we continue to think
about it."  What we are considering now is whether the current design
draft gives value proportionate to the complexity.  I like to think
that it does, but obviously I am biased.  And the only way to avoid
that bias is to open up the discussion to the community, which is what
we've been doing over the last couple of years.

In other words, sure, we could say "we want generics."  And I think
that for many of the language designers that is a true statement.  But
it's also true that we only want generics if the language can remain
sufficiently simple and easy to use.  So the bare statement "we want
generics" doesn't get us anywhere useful.  It doesn't end the
discussion.  It just starts it.


> Also, whilst understanding that voluntary submission has it's benefits in 
> terms
> of avoiding suggestion; that data has already been acquired. I wonder what the
> result would be given a number of options. I probably can't think of many of 
> the
> good requests, so this could be fuelled by past submissions. I can't remember
> hitting a null pointer in my code but certainly have in stdlib network 
> libraries
> (missing an & etc.)
>
>
> Null pointer panic avoidance via automatic error return (what happened before
> panics?)
>
> enhanced Gomobile support
>
> enhanced tinygo support
>
> Generics
>
> Flutter, Go cooperation
>
> ...
>
> No changes

These are all very different kinds of things.  For example, I think
it's a category error to think that working on generics somehow means
that we have worse Gomobile support.  To the best of my knowledge, the
people working on generics have never worked on Gomobile, and
vice-versa.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWBiPpMnzkAkfB2tb8VvTM8m1FyXVhHt6iRzv2Pyvfzew%40mail.gmail.com.

[go-nuts] Re: Generics, please go away!

[Alex Besogonov]

On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:

> > OOP isn't specific about how inheritance is handled (or if it is even 
> supported) 
> Oh my... It is pure sophistic nonsense. OOP is all about inheritance. Not 
> just whether you have "objects" in a language spec or not.
>
Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to do 
with inheritance. It's a common feature in object-oriented programming but 
it's not essential.

Moreover, Go has inheritance as well (struct embedding and interface 
inheritance), making it a fairly typical example. The only significant 
difference is that Go has structural typing, instead of manually 
declaration of implemented interfaces.

> But on the topic of generics, this entire thread seems alarmist.  
> Generics will open a huge door for libraries to be written that will make 
> our lives easier.  I'm thinking specifically about data processing and 
> machine learning.  A lot of devs use Python right now for this which leads 
> to duplication of code across languages.  Complex algorithms will be able 
> to be shared without hacky type conversions wrapping every function call. 
> Who is "yours"? You talk about Python so just go ahead and use Python if 
> it serves you, convince your team that Python is better, whatever.
>
You know that this argument can be applied to you as well?
 

> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com: 
>
>> OOP isn't specific about how inheritance is handled (or if it is even 
>> supported).  The basic definition is objects with fields and methods, and 
>> being able to address the itself (typically using 'this' or 'self', but Go 
>> is unique in that you define what to call the object).  It does composition 
>> differently than most languages, but the functional needs are met.
>>
>> But on the topic of generics, this entire thread seems alarmist.  
>> Generics will open a huge door for libraries to be written that will make 
>> our lives easier.  I'm thinking specifically about data processing and 
>> machine learning.  A lot of devs use Python right now for this which leads 
>> to duplication of code across languages.  Complex algorithms will be able 
>> to be shared without hacky type conversions wrapping every function call.  
>> We'll be able to use things like trees as simply as we use maps or slices.  
>> I don't think we'll see the language turn into the grossness that is Java 
>> or C++ because of it.
>>
>> On Wednesday, December 30, 2020 at 4:27:15 AM UTC-8 Space A. wrote:
>>
>>> Go doesn't have classes and is not an OOP language.
>>>
>>> Classes (like in Java) vs structs (like in Go) is about inheritance vs 
>>> composition, not about attaching fields and methods. Inheritance implies 
>>> type hierarchy, child and parent, virtual functions, abstract and final 
>>> implementations and so on so forth to keep this all of this manageable.
>>>
>>>
>>>
>>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov: 
>>>
 Please, stop being so condescending to newcomers and non-professional 
 developers. Generics as uses by end-users will improve their experience, 
 not make it harder.

 (And what is this obsession with "classes"? Go has them - structs with 
 methods are classes).



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.com.

[go-nuts] Re: Generics - please provide real life problems

[Alex Besogonov]

On Wednesday, December 23, 2020 at 10:16:00 PM UTC-8 Martin Hanson wrote:

> If all we're presented are these small theoretical examples of sorting 
> lists, etc., then clearly this is nothing but hype that needs to go 
> away. 
>
My personal example: ordered containers. My code works with physical 
simulations and it needs to be fully deterministic. This means that I can't 
use simple maps because their iteration order is random (on purpose!).

As a result, a lot of my code looked like this:

struct ElectricNode {
ChildrenList []ResistiveNode
ChildrenMap map[string]ResistiveNode
};

When I wanted to remove an element I have to write something like:

newList := make([]ResistiveNode, len(node.ChildrenList)-1)
for _, i := range node.ChildrenList {
   if i.Name != nameToRemove {
  newList = append(newList, i);
   }
}
node.ChildrenList = newList
delete(node.ChildrenMap, nameToRemove);

I had a couple of reflective helpers that did this work through reflection, 
but it was not clean and had broken more than once during refactorings. I 
actually gave up on Go for this project and rewrote it in Python, resulting 
in 10x (ten times) less lines of code.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/131cda29-6201-45bb-8728-4b7af4726ea6n%40googlegroups.com.

Re: [go-nuts] Generics - please provide real life problems

[da...@suarezhouse.net]

Real use cases have been provided it appears for both why generics can be 
good and how they can be used negligently (love the sextuple example BTW).  
I know many things in programming can be used the wrong way but does 
generics potentially cross a threshold where the writer should add an 
import to ensure that the writer is a "library" writer and not someone that 
doesn't understand the benefits?  

A simple import like unsafe that would be a "marker" (probably called 
something better) that would be sufficient to have new programmers not 
assume they should always use generics while enabling more advanced users 
to declare they are intentionally writing generic functions might be an 
easy middle ground. Potentially the marker may also enable some future 
optimizations.

Forgive me if that has already been suggested in a thread that I missed.  
If it has, would love to know why adding a marker as a way to maintain the 
simplicity that others fear will be lost was not something that makes sense 
here.   

Sincerely,
David

On Thursday, December 31, 2020 at 2:02:53 PM UTC-6 Ian Lance Taylor wrote:

> On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick  wrote:
> >
> > On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> > > I don't think this is accurate. Surveys express a clear and
> > > consistent desire for generics that is far ahead of requests for
> > > operator overloading or other language features. (To avoid
> > > misunderstanding I'll say again that changes to the Go language are
> > > not driven by polls.)
> >
> > Firstly, I appreciate that dev is not driven by polls but it may be that
> > internally to Google these desires are true too. It is natural to be 
> less likely
> > to get an honest answer from many employees, of course.
>
> I'm confident that Google employees are entirely willing to honestly
> express their feelings about Go. There is no company mandate to use
> Go, or to like it. (Of course I have no way to prove this.) I
> haven't seen any reason to think that Google employees are either more
> or less likely to prefer adding generics to Go than people outside of
> Google. It's not necessarily obvious, but there are Google employees
> on golang-nuts arguing that Go doesn't need generics.
>
>
> > If Generics is something wanted by the designers without or little 
> debate aside
> > from the form, then just say so and end the discussion?
>
> I don't think it's that simple. For a long time now the Go FAQ has
> said "Generics are convenient but they come at a cost in complexity in
> the type system and run-time. We haven't yet found a design that gives
> value proportionate to the complexity, although we continue to think
> about it." What we are considering now is whether the current design
> draft gives value proportionate to the complexity. I like to think
> that it does, but obviously I am biased. And the only way to avoid
> that bias is to open up the discussion to the community, which is what
> we've been doing over the last couple of years.
>
> In other words, sure, we could say "we want generics." And I think
> that for many of the language designers that is a true statement. But
> it's also true that we only want generics if the language can remain
> sufficiently simple and easy to use. So the bare statement "we want
> generics" doesn't get us anywhere useful. It doesn't end the
> discussion. It just starts it.
>
>
> > Also, whilst understanding that voluntary submission has it's benefits 
> in terms
> > of avoiding suggestion; that data has already been acquired. I wonder 
> what the
> > result would be given a number of options. I probably can't think of 
> many of the
> > good requests, so this could be fuelled by past submissions. I can't 
> remember
> > hitting a null pointer in my code but certainly have in stdlib network 
> libraries
> > (missing an & etc.)
> >
> >
> > Null pointer panic avoidance via automatic error return (what happened 
> before
> > panics?)
> >
> > enhanced Gomobile support
> >
> > enhanced tinygo support
> >
> > Generics
> >
> > Flutter, Go cooperation
> >
> > ...
> >
> > No changes
>
> These are all very different kinds of things. For example, I think
> it's a category error to think that working on generics somehow means
> that we have worse Gomobile support. To the best of my knowledge, the
> people working on generics have never worked on Gomobile, and
> vice-versa.
>
> Ian
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/672538d4-d313-4e60-bc39-bbe56f0c401dn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Thu, Dec 31, 2020 at 9:27 PM Alex Besogonov 
wrote:

> Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example.
>

Interfaces yes (though I would use "subtyping", not "inheritance", but
potato tomato), but struct embedding, no. Embedding a type doesn't make a
struct usable as that type, so it's not subtyping (and notably, methods are
still called on the embedded type).

You're still correct that Go has subtyping though, yes :)


> The only significant difference is that Go has structural typing, instead
> of manually declaration of implemented interfaces.
>
> > But on the topic of generics, this entire thread seems alarmist.
>> Generics will open a huge door for libraries to be written that will make
>> our lives easier.  I'm thinking specifically about data processing and
>> machine learning.  A lot of devs use Python right now for this which leads
>> to duplication of code across languages.  Complex algorithms will be able
>> to be shared without hacky type conversions wrapping every function call.
>> Who is "yours"? You talk about Python so just go ahead and use Python if
>> it serves you, convince your team that Python is better, whatever.
>>
> You know that this argument can be applied to you as well?
>
>
>> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:
>>
>>> OOP isn't specific about how inheritance is handled (or if it is even
>>> supported).  The basic definition is objects with fields and methods, and
>>> being able to address the itself (typically using 'this' or 'self', but Go
>>> is unique in that you define what to call the object).  It does composition
>>> differently than most languages, but the functional needs are met.
>>>
>>> But on the topic of generics, this entire thread seems alarmist.
>>> Generics will open a huge door for libraries to be written that will make
>>> our lives easier.  I'm thinking specifically about data processing and
>>> machine learning.  A lot of devs use Python right now for this which leads
>>> to duplication of code across languages.  Complex algorithms will be able
>>> to be shared without hacky type conversions wrapping every function call.
>>> We'll be able to use things like trees as simply as we use maps or slices.
>>> I don't think we'll see the language turn into the grossness that is Java
>>> or C++ because of it.
>>>
>>> On Wednesday, December 30, 2020 at 4:27:15 AM UTC-8 Space A. wrote:
>>>
 Go doesn't have classes and is not an OOP language.

 Classes (like in Java) vs structs (like in Go) is about inheritance vs
 composition, not about attaching fields and methods. Inheritance implies
 type hierarchy, child and parent, virtual functions, abstract and final
 implementations and so on so forth to keep this all of this manageable.



 вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov:

> Please, stop being so condescending to newcomers and non-professional
> developers. Generics as uses by end-users will improve their experience,
> not make it harder.
>
> (And what is this obsession with "classes"? Go has them - structs with
> methods are classes).
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHeNF_ZtZEEUqNaNFPGX3TzH1jPC0FTeKXMmJ006Sa_qQ%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Wojciech S. Czarnecki]

Dnia 2020-12-31, o godz. 13:41:34
Kevin Chadwick  napisał(a):

> Thank You all for my favourite language and Happy New Year!

Happy New Year! 

Kevin, forgive me that I'd chosen your *nonpartisan* message to cool this 
particular thread
and insert here an announcement of the third way to Go generics, kinda [1].

For the web users [Signature Switch - third path to Go generics] thread link 
is: 
[1] https://groups.google.com/g/golang-nuts/c/dQ6TUxk5-Pc/m/aRu0vvD-CAAJ

Please read whole https://play.golang.org/p/Q1ry4KPoOOJ document before reply.

P.S. This message also goes via bcc to the some people who participated 
in this and former (Gene...away!) firehose threads - I would like to know your
opinion about and I hope no one would mind this one doubled mail :)
If you do mind - I kindly apologize for the inconvenience.

Thank you. And Happy New Year!


-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210101004322.25e2a729%40xmint.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
do with inheritance. It's a common feature in object-oriented programming
but it's not essential.
> Moreover, Go has inheritance as well (struct embedding and interface
inheritance), making it a fairly typical example. The only significant
difference is that Go has structural typing, instead of manually
declaration of implemented interfaces.

You don't disappoint me by repeating wrong statements.

As I said, OOP (if we talk about language, not a program written in OOP
paradigm, because you can use ANY language for that) is all about
inheritance. Period. Proof - take any major OOP language and see how it's
done, what's in its heart.

Secondly, and I copy-paste myself here:
Classes (like in Java) vs structs (like in Go) is about inheritance vs
composition, not about attaching fields and methods. Inheritance implies
type hierarchy, child and parent, virtual functions, abstract and final
implementations and so on so forth to keep this all of this manageable.

If you don't understand what it means, please study a little bit (with all
respect and blabla, I also learn all the time). Because these two
approaches are different.

Here is some small quote and link which I think can help:

My late friend Alain Fournier once told me that he considered the lowest
> form of academic work to be taxonomy. And you know what? Type hierarchies
> are just taxonomy. You need to decide what piece goes in what box, every
> type's parent, whether A inherits from B or B from A.  Is a sortable array
> an array that sorts or a sorter represented by an array? If you believe
> that types address all design issues you must make that decision.
>
I believe that's a preposterous way to think about programming. What
> matters isn't the ancestor relations between things but what they can do
> for you.
>
> That, of course, is where interfaces come into Go. But they're part of a
> bigger picture, the true Go philosophy.
> If C++ and Java are about type hierarchies and the taxonomy of types, Go
> is about composition.
> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>
> We should have some ways of coupling programs like garden hose--screw in
> another segment when it becomes necessary to massage data in another way.
> This is the way of IO also.
>
> That is the way of Go also. Go takes that idea and pushes it very far. It
> is a language of composition and coupling.
> The obvious example is the way interfaces give us the composition of
> components. It doesn't matter what that thing is, if it implements method M
> I can just drop it in here.
> Another important example is how concurrency gives us the composition of
> independently executing computations.
> And there's even an unusual (and very simple) form of type composition:
> embedding.
> These compositional techniques are what give Go its flavor, which is
> profoundly different from the flavor of C++ or Java programs.
>

https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html





чт, 31 дек. 2020 г. в 23:27, Alex Besogonov :

> On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:
>
>> > OOP isn't specific about how inheritance is handled (or if it is even
>> supported)
>> Oh my... It is pure sophistic nonsense. OOP is all about inheritance. Not
>> just whether you have "objects" in a language spec or not.
>>
> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
> do with inheritance. It's a common feature in object-oriented programming
> but it's not essential.
>
> Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example. The only significant
> difference is that Go has structural typing, instead of manually
> declaration of implemented interfaces.
>
> > But on the topic of generics, this entire thread seems alarmist.
>> Generics will open a huge door for libraries to be written that will make
>> our lives easier.  I'm thinking specifically about data processing and
>> machine learning.  A lot of devs use Python right now for this which leads
>> to duplication of code across languages.  Complex algorithms will be able
>> to be shared without hacky type conversions wrapping every function call.
>> Who is "yours"? You talk about Python so just go ahead and use Python if
>> it serves you, convince your team that Python is better, whatever.
>>
> You know that this argument can be applied to you as well?
>
>
>> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:
>>
>>> OOP isn't specific about how inheritance is handled (or if it is even
>>> supported).  The basic definition is objects with fields and methods, and
>>> being able to address the itself (typically using 'this' or 'self', but Go
>>> is unique in that you define what to call the object).  It does composition
>>> differently than most languages, but the functional needs are met.
>>>
>>> But on the topic of g

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Missed your second question.


> > But on the topic of generics, this entire thread seems alarmist.
>> Generics will open a huge door for libraries to be written that will make
>> our lives easier.  I'm thinking specifically about data processing and
>> machine learning.  A lot of devs use Python right now for this which leads
>> to duplication of code across languages.  Complex algorithms will be able
>> to be shared without hacky type conversions wrapping every function call.
>> Who is "yours"? You talk about Python so just go ahead and use Python if
>> it serves you, convince your team that Python is better, whatever.
>>
> You know that this argument can be applied to you as well?
>

Can it? I use Go. I never said anywhere that there is some language like
Python, that Go should take from. Instead I was always saying it must
differentiate. I see no problem in using other languages if they do well
for other people, so I don't understand why so many here want Go to become
yet another Java. If you go by this way, Go will always be just a niche
thing, "bad copy" which lacks so many cool features. And as I said in my
reply to the very first message of the thread, I will go for the fork of
Go1, if it happens. But unfortunately it seems that I will be forced to
live with generics. There will be absolutely no way to use Go without them
when it's landed.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTfzvw9VMiCSDjR60bkdo3%2B%3D%2B0Xur4mF3SewjGxO6Kyiqg%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Fri, Jan 1, 2021 at 1:23 AM Space A.  wrote:

> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
> do with inheritance. It's a common feature in object-oriented programming
> but it's not essential.
> > Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example. The only significant
> difference is that Go has structural typing, instead of manually
> declaration of implemented interfaces.
>
> You don't disappoint me by repeating wrong statements.
>
> As I said, OOP (if we talk about language, not a program written in OOP
> paradigm, because you can use ANY language for that) is all about
> inheritance. Period. Proof - take any major OOP language and see how it's
> done, what's in its heart.
>

Javascript is an incredibly popular language with non-inheritance OOP. Or,
at least, no inheritance at the type-level (so either way, invalidating
your statement that OOP is about type-hierarchies).

Secondly, and I copy-paste myself here:
> Classes (like in Java) vs structs (like in Go) is about inheritance vs
> composition, not about attaching fields and methods. Inheritance implies
> type hierarchy, child and parent, virtual functions, abstract and final
> implementations and so on so forth to keep this all of this manageable.
>

Repetition does not make a false statement true. Instead of copy-pasting
yourself, it would be prudent to cite sources. For example, is there any
text book that agrees with your definition of OOP?

If you don't understand what it means, please study a little bit (with all
> respect and blabla, I also learn all the time). Because these two
> approaches are different.
>
> Here is some small quote and link which I think can help:
>
> My late friend Alain Fournier once told me that he considered the lowest
>> form of academic work to be taxonomy. And you know what? Type hierarchies
>> are just taxonomy. You need to decide what piece goes in what box, every
>> type's parent, whether A inherits from B or B from A.  Is a sortable array
>> an array that sorts or a sorter represented by an array? If you believe
>> that types address all design issues you must make that decision.
>>
> I believe that's a preposterous way to think about programming. What
>> matters isn't the ancestor relations between things but what they can do
>> for you.
>>
>> That, of course, is where interfaces come into Go. But they're part of a
>> bigger picture, the true Go philosophy.
>> If C++ and Java are about type hierarchies and the taxonomy of types, Go
>> is about composition.
>> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>>
>> We should have some ways of coupling programs like garden hose--screw in
>> another segment when it becomes necessary to massage data in another way.
>> This is the way of IO also.
>>
>> That is the way of Go also. Go takes that idea and pushes it very far. It
>> is a language of composition and coupling.
>> The obvious example is the way interfaces give us the composition of
>> components. It doesn't matter what that thing is, if it implements method M
>> I can just drop it in here.
>> Another important example is how concurrency gives us the composition of
>> independently executing computations.
>> And there's even an unusual (and very simple) form of type composition:
>> embedding.
>> These compositional techniques are what give Go its flavor, which is
>> profoundly different from the flavor of C++ or Java programs.
>>
>
One thing that is conspicuously absent from this quote, of course, is the
term "Object oriented programming" (or even just "Object"). FTR, if you
quote Rob Pike, you should also be aware that he has always staunchly
defended the stance that Go is an OOP language:
https://www.youtube.com/watch?t=750&v=rKnDgT73v8s

But either way, if you don't mind me asking: What exactly does any of this
have to do with generics?


> https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
>
>
>
>
>
> чт, 31 дек. 2020 г. в 23:27, Alex Besogonov :
>
>> On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:
>>
>>> > OOP isn't specific about how inheritance is handled (or if it is even
>>> supported)
>>> Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
>>> Not just whether you have "objects" in a language spec or not.
>>>
>> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
>> do with inheritance. It's a common feature in object-oriented programming
>> but it's not essential.
>>
>> Moreover, Go has inheritance as well (struct embedding and interface
>> inheritance), making it a fairly typical example. The only significant
>> difference is that Go has structural typing, instead of manually
>> declaration of implemented interfaces.
>>
>> > But on the topic of generics, this entire thread seems alarmist.
>>> Generics will open a huge door for libraries to be written that will make
>>> our lives easier.  I'm 

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Thu, Dec 31, 2020 at 6:51 PM robert engels  wrote:

> Go has been in existence for 10+ years and has fairly wide adoption in
> some areas - so it is not hard to make the case that generics are “not an
> important thing”
>

This has been brought up in That Other Thread, so let me copy what I said
there (you didn't respond to that particular point, even though you replied
to the E-Mail, so I assume you've already read it):

Of course, this doesn't answer how we'd have managed *with* them.

We did manage for decades without general purpose CPUs. We did manage for
several decades without functions, coroutines or hashtables. We did manage
for decades without portable programming languages or multi-tasking
operating systems. We managed for many decades without the internet or the
world wide web.

In hindsight, though,  "we managed so long without them" doesn't appear to
be a very convincing argument to not have them today.


> - depends on what you are trying to do with it and what your perspective
> on “the right way” is.
>

This seems to indicate some progress in mutual understanding - by saying
that it depends on what you do with the language, you seem to imply that
you understand that other people's use-case might benefit from generics. Am
I reading this correctly?


>
>
> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> On Thu, Dec 31, 2020 at 5:46 PM robert engels 
> wrote:
>
>> I’ll state for the record again, I was originally very dismayed that Go
>> did not offer generics - after developing with it for a while that is far
>> less of an issue to me than the error handling.
>>
>
> Just to illustrate that the plural of "anecdote" isn't "data": I was
> originally very vehemently opposed to generics in Go, but after using Go
> for a bunch of years, I've been missing them often enough that I think they
> provide a net-benefit (despite my criticism of this specific design).
>
> Generics just isn't a "if you use Go long enough you learn they are not
> important" thing.
>
>
>> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> Hi,
>>
>> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>>
>>> If 95% of generics are collections the current draft is overkill.
>>> What about a simplified version with only one generic type (like we do
>>> with interface{}), without constraint as long as it can compile ?
>>>
>>
>> • "Only one generic type" means you can't write generic maps or graph
>> structures
>> • "Without constraints" means compilation cost goes up significantly (as
>> the compiler needs to completely redo type-checking and compilation for
>> each instantiation - instead of only checking that the function adheres to
>> the constraints and the type-arguments fulfill it at each call-site. i.e.
>> you make an NxM problem out of an N+M problem). It also makes good error
>> messages very hard. And the constraints need to be documented anyway (in a
>> comment, if nothing else), so that the user knows how to call the function
>> - might as well have a standardized, machine-checkable way to express that.
>>
>> So even *if* we only consider containers, the complexity of the design
>> isn't accidental. There are very concrete (and IMO important) advantages to
>> these decisions.
>>
>> That being said, I also, personally, don't consider type-safe containers
>> the main use-case of generics. It's certainly *one*, and one that can't be
>> solved without them. I definitely see the advantage of being able to
>> implement complex data-structures like lock-free concurrent maps or sorted
>> maps as a library and use them in really performance-sensitive code-paths.
>> But I also feel that my concerns about generics mainly stem from
>> experiences with Java and C++ where *everything* was expressed in terms of
>> abstract generic containers and algorithms, cluttering the code and
>> requiring you to understand subtle differences between different
>> implementations of the implementations of the abstract versions. So,
>> personally, I really hope containers are *not* 95% of the use-case of
>> generics. In fact, if type-safe containers *where* 95% of the use-case, I
>> would still be very much opposed to adding generics - I don't think we
>> really *need* type-safety for containers, as we are usually very well aware
>> of what's stored in them.
>>
>> Personally, the main use-case for generics I see (and I want to emphasize
>> that everyone sees different use-cases as more or less important, depending
>> on what kind of code they write) is the ability for concurrency as a
>> library. I think channels and goroutines are great concurrency primitives -
>> but they are primitives, that need to be composed to be useful. And this
>> composition is usually very subtle and hard to get right. So being able to
>> solve these composition problems once and re-use that solution, seems very
>> exciting to me. But, again, that focus comes fro

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

[Ivan Serdyuk]

Happy New Year, Than.

So I have rebuilt llvm-goc, after applying 
https://go-review.googlesource.com/c/gollvm/+/270219 .
Here 

 
is my compressed build folder.

I am using 
$ clang --version
clang version 12.0.0
Target: i686-pc-linux-gnu
Thread model: posix
on
$ uname -a
Linux oceanfish81-A8He 4.15.0-129-generic #132-Ubuntu SMP Thu Dec 10 
14:07:35 UTC 2020 i686 i686 i686 GNU/Linux

You can obtain a pre-compiler "MinSizeRel" build of LLVM (including Clang) 
here 

.

I tried to build an avarage libgo package - and here is what I got:

$ ninja libgo_golang.org_x_crypto_chacha20
[1/120] Building Go package 'unicode' (non-PIC)
FAILED: tools/gollvm/libgo/unicode.o 
cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo && 
/usr/local/bin/cmake -E make_directory ./. && 
/home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o 
/home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/./unicode.o 
-fgo-pkgpath=unicode -I . 
/home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/casetables.go
 
/home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/digit.go
 
/home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/graphic.go
 
/home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/letter.go
 
/home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/tables.go
currently Gollvm is not supported on architecture i686
/home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to 
determine target CPU features for target i686-pc-linux-gnu*
[2/120] Building Go package 'internal/unsafeheader' (PIC)
FAILED: tools/gollvm/libgo/internal/.pic/unsafeheader.o 
cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo && 
/usr/local/bin/cmake -E make_directory ./internal/.pic && 
/home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o 
/home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/internal/.pic/unsafeheader.o
 
-fPIC -fgo-pkgpath=internal/unsafeheader -I . 
/home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/unsafeheader/unsafeheader.go
currently Gollvm is not supported on architecture i686
/home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to 
determine target CPU features for target i686-pc-linux-gnu*
ninja: build stopped: subcommand failed.

Ivan
On Tuesday, December 8, 2020 at 3:30:05 PM UTC+2 th...@google.com wrote:

> Hello,
>
> Thanks for the note.
>
> I am still not completely sure what the problem is.
>
>
> You wrote:
>
>  | I found
>  | 
>  | // triple: i686-pc-linux-gnu
>  | static const CpuAttrs attrs1[] = {
>  | // first entry is default cpu
>  | { "i686", "+cx8,+x87"},
>  | 
>  | and (inside the hashmap)
>  | 
>  | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
>  | , which is not what I have supported (for Intel Celeron M440).
>
> What makes you say that this is not what you have supported? Are you
> saying that the cpu clang calls "yonah" doesn't actually have one of these
> features (ex: sse3)?
>
>
>  | Clang reports "unsupported CPU features" on any non-provided one.
>  | So that is one big problem.
>
> Not sure what you mean here. Can you please post the complete clang 
> invocation and error message you are getting?
>
>
>
>  | const TripleCpus triples[] = {
>  | { "x86_64-unknown-linux-gnu", &attrs0[0] },
>  | { "i686-pc-linux-gnu", &attrs1[0] },
>  | { "aarch64-unknown-linux-gnu", &attrs2[0] },
>  | { "", nullptr } // sentinel
>  | };
>  | is not targeting to yonah, while llc is targeting it.
>  | It is always some "default" CPU model and, in fact, your code never 
> provided extraction of the CPU model (from llc).
>  | 
>
> When llc emits the line
>
>   Host CPU: yonah
>
> this does not mean that clang/llc will automatically target 'yonah' when 
> compiling, it just means that the program has detected the host CPU.
>
> Generally speaking if you want clang to produce code targeted specifically 
> to the host CPU, you have to use -march=native or -mtune-native.
>
> Thanks, Than
>
> On Fri, Dec 4, 2020 at 8:08 PM Ivan Serdyuk  
> wrote:
>
>> Hello.
>>
>> This issue is related to 
>> https://go-review.googlesource.com/c/gollvm/+/274574
>> .
>>
>> I think I have some misunderstanding on how you used to deal with CPU 
>> models, for LLVM.
>>
>> First things first - I had success with using
>>
>> #include "llvm/ADT/StringRef.h"
>> #include "llvm/ADT/StringMap.h"
>> #include "llvm/MC/SubtargetFeature.h"
>> #include "llvm/Support/Host.h"
>>
>> using namespace llvm;
>> SubtargetFeatures Features1;
>>
>> int main (int argc, char **argv)
>> {
>> sys::getHostCPUName();
>> StringMap HostFeatures;
>> if (sys::getHostCPUFeatur

Re: [go-nuts] Signature Switch - third path to Go generics

[Wojciech S. Czarnecki]

Dnia 2020-12-31, o godz. 13:15:00
"K. Alex Mills"  napisał(a):

> At a glance, this feels to me like it is more complicated than the current
> generics proposal. That said, it also seems very original so I have to give
> credit there.

It is just the other kind, as I see it. You know, it was born just yesterday :)
I forbade matching on the result parameter type, but I think it might
be part to match, too. See example at the end.
 
> This proposal seems to put the responsibility for monomorphizing generic
> code onto the programmer. I'm not sure why it would be simpler than
> monomorphizing generic functions directly, which we can do today.

It is the author of the generic function that bears the burden - yes. 
But thousands others using her older code need not even know that some day
it went generic and "legacy" signature went to the one of cases. Ie. I as an 
author
may start with plain Go function, then make it generic just when I need same
functionality for other but similar set of parameter types. See Min(x, y) 
example in
the playground document.

> I guess under this proposal all the monomorphized versions would be able to
> share similar function signatures and we can't do that today.

All call sites to the identifier share the signature shape, ie number of 
parameters, yes.

> I do worry that in case you have two generic parameters, this proposal
> would seem to require NxM cases to be explicitly written out.

No. Not that much explicitly. See lines 23..32 in the playground document.

Eg. the "underlying" type syntax lets us write cases that encompass way many of 
NxM
combinations in a few branches of the Signature switch, while analysis (read 
time)
stays linear: find declaration, find case that matches your parameters, read.
Also, if given set of parameter types matches a case signature, compiler will
instantiate (or even reuse in the far future) respective case's code. Otherwise
compile error will tell us that our current types here are not served (yet).
Or that we eg. need to give a type to the untyped constant we used.

Below float to int conversion example deals with any call site that call us 
with any int type
that happens to be based on int32, int64 as "int" and float32, float64 "float". 
Func ToInt
returns result of the x parameter type and an ok flag set to true if conversion 
went ok 
If there was an overflow, func ToInt returns respective MaxInt and false.

Note that (for now) there is no match on the result parameter type, so the 
ToInt got
a parameter that might not be needed were result parameters matched too.
Such version is below, too.

// https://play.golang.org/p/T97kLYaHS9e
// negative numbers branch left out for brevity
func ToInt (x +T, y +U) (r +T, ok bool) {
switch func.(type) {
case func(x (int32), y (float64)) (r T, ok bool): fallthrough
case func(x (int32), y (float32)) (r T, ok bool): // (type) 
underlying type of
  lim := float64(math.Nextafter32(float32(math.MaxInt32+1), 0))
if float64(y) > lim { // Mmm, Is it ok? I should study 
IEEE754 more
return T(math.MaxInt32), false
}
return T(int32(y)), true

case func(x (int64), y (float32)) (r T, ok bool): fallthrough
case func(x (int64), y (float64)) (r T, ok bool):
  lim := math.Nextafter(float64(math.MaxInt64+1), 0)
if float64(y) > lim {
return T(math.MaxInt64), false
}
return T(int64(y)), true
}
return // not reached
}

// if result parameters can be matched
func ToInt (f +F) (r +T, ok bool) {
switch func.(type) {
case func(f (float64)) (r (int32), ok bool): fallthrough
case func(f (float32)) (r (int32), ok bool):
  lim := float64(math.Nextafter32(float32(math.MaxInt32+1), 0))
if float64(f) > lim {
return T(math.MaxInt32), false
}
return T(int32(f)), true

case func(f (float64)) (r (int64), ok bool): fallthrough
case func(f (float32)) (r (int64), ok bool):
  lim := float64(math.Nextafter(float64(math.MaxInt64+1), 0))
if float64(f) > lim { // Mmm, Is it ok? I should study 
IEEE754 more
return T(math.MaxInt64), false
}
return T(int64(f)), true
}
return // not reached
}


> That feels like a lot of work as compared to the current proposal, in which 
> the
> compiler can inspect the callsites and automatically generate only the
> binary code needed to satisfy the types in use.

This is true also for the Signature switch - it is compil

Re: [go-nuts] Generics, please go away!

[Alex Besogonov]

> On Dec 31, 2020, at 15:10, Axel Wagner  wrote:
> 
> On Thu, Dec 31, 2020 at 9:27 PM Alex Besogonov  > wrote:
> Moreover, Go has inheritance as well (struct embedding and interface 
> inheritance), making it a fairly typical example.
> 
> Interfaces yes (though I would use "subtyping", not "inheritance", but potato 
> tomato), but struct embedding, no. Embedding a type doesn't make a struct 
> usable as that type, so it's not subtyping (and notably, methods are still 
> called on the embedded type).
Yes, it does make it usable. See: https://play.golang.org/p/IqxpujkqXnO 


There’s simply no automatic upcasting.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/C484E8FD-1DC3-4604-866F-80F27A49F357%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Robert Engels]

Of course. But you don’t design a language (or any other product) for the 5% - 
you design it for the 95 (80?} percent - if you want you have customers/users 
and stay relevant (in business). 

> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels  wrote:
> 
>> Go has been in existence for 10+ years and has fairly wide adoption in some 
>> areas - so it is not hard to make the case that generics are “not an 
>> important thing”
> 
> This has been brought up in That Other Thread, so let me copy what I said 
> there (you didn't respond to that particular point, even though you replied 
> to the E-Mail, so I assume you've already read it):
> 
> Of course, this doesn't answer how we'd have managed *with* them.
> 
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking operating 
> systems. We managed for many decades without the internet or the world wide 
> web.
> 
> In hindsight, though,  "we managed so long without them" doesn't appear to be 
> a very convincing argument to not have them today.
>  
>> - depends on what you are trying to do with it and what your perspective on 
>> “the right way” is.
> 
> This seems to indicate some progress in mutual understanding - by saying that 
> it depends on what you do with the language, you seem to imply that you 
> understand that other people's use-case might benefit from generics. Am I 
> reading this correctly?
>  
>> 
>> 
>>> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>> 
 On Thu, Dec 31, 2020 at 5:46 PM robert engels  
 wrote:
>>> 
 I’ll state for the record again, I was originally very dismayed that Go 
 did not offer generics - after developing with it for a while that is far 
 less of an issue to me than the error handling.
>>> 
>>> Just to illustrate that the plural of "anecdote" isn't "data": I was 
>>> originally very vehemently opposed to generics in Go, but after using Go 
>>> for a bunch of years, I've been missing them often enough that I think they 
>>> provide a net-benefit (despite my criticism of this specific design).
>>> 
>>> Generics just isn't a "if you use Go long enough you learn they are not 
>>> important" thing.
>>> 
 
> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> Hi,
> 
> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
> 
> • "Only one generic type" means you can't write generic maps or graph 
> structures
> • "Without constraints" means compilation cost goes up significantly (as 
> the compiler needs to completely redo type-checking and compilation for 
> each instantiation - instead of only checking that the function adheres 
> to the constraints and the type-arguments fulfill it at each call-site. 
> i.e. you make an NxM problem out of an N+M problem). It also makes good 
> error messages very hard. And the constraints need to be documented 
> anyway (in a comment, if nothing else), so that the user knows how to 
> call the function - might as well have a standardized, machine-checkable 
> way to express that.
> 
> So even *if* we only consider containers, the complexity of the design 
> isn't accidental. There are very concrete (and IMO important) advantages 
> to these decisions.
> 
> That being said, I also, personally, don't consider type-safe containers 
> the main use-case of generics. It's certainly *one*, and one that can't 
> be solved without them. I definitely see the advantage of being able to 
> implement complex data-structures like lock-free concurrent maps or 
> sorted maps as a library and use them in really performance-sensitive 
> code-paths. But I also feel that my concerns about generics mainly stem 
> from experiences with Java and C++ where *everything* was expressed in 
> terms of abstract generic containers and algorithms, cluttering the code 
> and requiring you to understand subtle differences between different 
> implementations of the implementations of the abstract versions. So, 
> personally, I really hope containers are *not* 95% of the use-case of 
> generics. In fact, if type-safe containers *where* 95% of the use-case, I 
> would still be very much opposed to adding generics - I don't think we 
> really *need* type-safety for containers, as we are usually very well 
> aware of what's stored in them.
> 
> Personally, the main use-case for generics I see (and I want to emphasize 
> that everyone sees