Re: [go-nuts] Go Generics using interfaces - alternative take

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 1:54 PM Arnaud Delobelle
 wrote:
>
> I noticed today the blog post about the revised Generics proposal.  What got 
> me excited is this extract at the start:
>
> The biggest change is that we are dropping the idea of contracts. The 
> difference between contracts and interface types was confusing, so we’re 
> eliminating that difference.
>
> To me the lack of orthogonality between contracts and interfaces was the 
> major issue with the previous proposal and I have been musing with ways of 
> resolving it for a while, so I am very pleased that the proposal is going 
> down this path!
>
> Last month I decided to write a post about a way of introducing Generics into 
> Go using interfaces,  which I called "Package Specialization".
>
> Headline features are:
>
> use interfaces to express parametric types;
> no new keyword;
> the only new syntax is “package specialization”: pkg(T=int, Y=*MyType).Func();
> generic code which doesn’t use the package specialization syntax is already 
> valid Go.
>
> The full post can be read here: 
> https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2.html
>
> I was toying with the idea of submitting it here for feedback, to try to move 
> the discussion in that direction.  Well, I guess today's updated proposal 
> steals my thunder! Essentially this is the same idea, but with a different 
> manifestation in the language - I thought that submitting it anyway may 
> provide a useful comparison point to help gauge the updated proposal better.
>
> Note that sadly, I do not have much time to polish a proposal or to follow 
> discussions in general on this or other golang-related discussion lists, so I 
> apologize in advance if I am inadvertently re-hashing ideas that have been 
> put forward and dismissed in the past, or if my blog post is a little low on 
> detail (it was meant to be an exploration of a possible approach).

Thanks.  I hadn't seen that before.

A difficulty with package specialization is when you want to write a
List(List(int)).  That is, a List where each element of the List is a
List(int).  Or, when you want to write a transformation function as in
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#list-transform.
It would seem to require some modification of how imports work in Go,
and that leads into considerable complexity.  See also
.https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
.

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/CAOyqgcVS%3Dae90U51y_%2BN6a00Ve6UTK%3DNfqz38LhzuMSBDrXmZQ%40mail.gmail.com.

Re: [go-nuts] [generics] Type lists should be usable in any interface

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 9:54 PM Bakul Shah  wrote:
>
> Seems to me that perhaps 'ordered' should also be *predeclared*.
> What happens if/when a big int type is added in future? Or
> decimal or big floats. "The Expression Problem" comes to mind :-)

Adding new predeclared types is sure to be rare.

If we want to predeclare constraints like "ordered", we have to
consider all other possible type combinations that people might want.
And it turns out that there are quite a few, like 25.  That's why we
suggested type lists: because it will always work for any combination
of types that people might want, and we don't have to add 25 new
predeclared names.


> It would be nice if it was possible to extend operators for user
> defined types (but I suspect people will object!). If syntax for
> such existed, both 'ordered' and 'comparable' could be defined
> cleanly.

Yes.


> I don't really see very many uses of an interface containing a
> list of types.

Not many, but non-zero.  And it seems clearly essential to permit
people to write generic functions that use operators like "<" and "+".


> Finally how would generics defined using 'ordered' deal with NaNs?
> NaNs are unordered!

See, e.g., 
https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/testdata/go2path/src/slices/slices.go2#14
.

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/CAOyqgcXUnkm5eCB2Eo%3Dk4yOvyiimJrLou-V4bOT_7GNuJnPG7A%40mail.gmail.com.

Re: [go-nuts] [generics] Type lists should be usable in any interface

[Bakul Shah]

On Jun 16, 2020, at 7:06 PM, Brandon Dyck  wrote:
> 
> I find it a little strange that an interface with a type list can only be 
> used as a constraint, and not as the type of a variable or parameter, despite 
> it using basically the same syntax as a normal interface. Is this difference 
> between constraints and other interfaces a property of the type system, or 
> just a limitation of the translation? I don't think it was explicit in the 
> design document. It would certainly be useful to declare variables with 
> type-list interfaces, as it would provide a much less hacky way to define sum 
> types than using an unexported interface method as in 
> https://medium.com/@haya14busa/sum-union-variant-type-in-go-and-static-check-tool-of-switch-case-handling-3bfc61618b1e.

This use is not quite the same as sum types. Basically the use of
a type list in 'ordered' *stands in* for types that have ordered
comparison operators but Go doesn't have a way to specify this.
And even this did not work for the 'comparable' as the list is
open ended. Both seem to have resulted from Go's peculiarity.

In comparison a sum type can contain any types. These types need
not have anything in common. As long as an operation is qualified
with a type assertion this works.

Seems to me that perhaps 'ordered' should also be *predeclared*.
What happens if/when a big int type is added in future? Or
decimal or big floats. "The Expression Problem" comes to mind :-)

It would be nice if it was possible to extend operators for user
defined types (but I suspect people will object!). If syntax for
such existed, both 'ordered' and 'comparable' could be defined
cleanly.

I don't really see very many uses of an interface containing a
list of types.

Finally how would generics defined using 'ordered' deal with NaNs?
NaNs are unordered!

-- 
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/C4CCD5F9-AFD3-462B-B1BC-C127F9EB1884%40iitbombay.org.

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 9:04 PM Xie Zhenye  wrote:
>
> I agree. constraint is different from normal interface. It's better to use 
> type SomeConstraint constraint {} than  type SomeConstraint interface {}

That is an option, but then we would have two different concepts,
constraints and interfaces, that are very very similar.  It's not
clear that that is better.

Ian


> On Wednesday, June 17, 2020 at 11:12:24 AM UTC+8 Brandon Dyck wrote:
>>
>> I find it a little strange that an interface with a type list can only be 
>> used as a constraint, and not as the type of a variable or parameter, 
>> despite it using basically the same syntax as a normal interface. Is this 
>> difference between constraints and other interfaces a property of the type 
>> system, or just a limitation of the translation? I don't think it was 
>> explicit in the design document. It would certainly be useful to declare 
>> variables with type-list interfaces, as it would provide a much less hacky 
>> way to define sum types than using an unexported interface method as in 
>> https://medium.com/@haya14busa/sum-union-variant-type-in-go-and-static-check-tool-of-switch-case-handling-3bfc61618b1e.
>>
>> My failing example is at https://go2goplay.golang.org/p/-lQ0jKs8_hU.
>
> --
> 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/88aa126b-d8f1-49c0-84cd-c0ea8cd87d39n%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/CAOyqgcUKmJX4sCS5Am8KVtJvajNEVQxq1y2d4BONkM6Tm668Ag%40mail.gmail.com.

Re: [go-nuts] [generics] Maybe possible to use <> instead of () as type parameter and

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 9:02 PM Xie Zhenye  wrote:
>
> In the draft, it says:
> "Why not use the syntax F like C++ and Java?
> When parsing code within a function, such as v := F, at the point of 
> seeing the < it's ambiguous whether we are seeing a type instantiation or an 
> expression using the < operator. Resolving that requires effectively 
> unbounded lookahead. In general we strive to keep the Go parser efficient."
>
> Maybe adding type metadata to an identifier during parsing, and using the 
> metadata of an identifier may resolve the ambiguous of type parameter or less 
> operator.   For example, '<' after a variable or constant name is a less 
> operator and '<' after a function or type name is a type parameter.
>
> <> will be more readable than () and easier to identify type parameter and 
> function call.

Let's try using this syntax for a while before we discard it.  Thanks.

That said, it's a key feature of Go that it is possible to parse a
program without requiring any type information.  That is how tools
like gofmt work.  We must be able to parse Go code without building a
symbol table.  So the suggestion of adding type metadata to an
identifier during parsing is not a choice we are going to take.
Thanks for thinking of it, though.

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/CAOyqgcWnL03zdDAHMNt4Lx3OxefKTxfLxs27YCCyqnQMvCmCrg%40mail.gmail.com.

Re: [go-nuts] [generics] Some ideas

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 8:12 PM Pee Jai  wrote:
>
> I read the proposal and am very impressed by it. I have 3 concerns however.
>
> 1. `F(type T)(p T) { ... }`
>
> To me, having 2 or 3 sets of parentheses is very weird. All mainstream 
> programming languages have only 1 set of parentheses for the function's 
> arguments. I've never seen 2 before. I know the proposal says the authors of 
> the draft considered other common symbols including colon. I still think `::` 
> seems nicest.

Let's get some experience with this syntax before we decide to change it.


> 2. Expanding interfaces to include fields
>
> Currently interfaces can dictate methods only. The proposal also adds type 
> lists.
> I propose that for the purposes of generics, the interface also defines 
> fields. This has been rejected numerous times for interfaces (as it is now), 
> but for generics, I think it will greatly enhance the power given to 
> developers whilst honouring the intention/spirit of the proposal.

Thanks.  While it's always interesting to discuss extensions, I don't
see a major need for this one.  It seems that it can be done later if
there is a need.  I'd prefer to keep this design draft as simple as
possible--and it's already very complicated!


> 3. Compile time.
>
> I started using Go around Go1.3 (the C compiler days). Back then compiling 
> was blink-of-an-eye fast. I used it as a selling point to everyone I met at 
> meetups (there was minimal uptake of Go back then so it was meetups for other 
> languages). Now the compiler is fast but for moderate size projects, it's no 
> longer blink-of-an-eye fast. I don't bother hyping this feature any more.
>
> Obviously based on how generics is implemented, the compiler will again be 
> slower.
>
> I propose a compile flag so that when developing all the generic type 
> checking etc is done at run-time (default behaviour). When ready to build for 
> production, a compile flag can use used to move the type checking to happen 
> at compile time.

Thanks, we have a ways to go before we discuss implementation.
Certainly if we do adopt this design draft we will pay close attention
to compile time.

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/CAOyqgcVdO0%3Dr%3DfgfJ14BH3C5nWcE0CZayjc1HgEztdkVGXa2DQ%40mail.gmail.com.

[go-nuts] Re: [generics] Type lists should be usable in any interface

[Xie Zhenye]

I agree. constraint is different from normal interface. It's better to use 
type SomeConstraint constraint {} than  type SomeConstraint interface {} 

On Wednesday, June 17, 2020 at 11:12:24 AM UTC+8 Brandon Dyck wrote:

> I find it a little strange that an interface with a type list can only be 
> used as a constraint, and not as the type of a variable or parameter, 
> despite it using basically the same syntax as a normal interface. Is this 
> difference between constraints and other interfaces a property of the type 
> system, or just a limitation of the translation? I don't think it was 
> explicit in the design document. It would certainly be useful to declare 
> variables with type-list interfaces, as it would provide a much less hacky 
> way to define sum types than using an unexported interface method as in 
> https://medium.com/@haya14busa/sum-union-variant-type-in-go-and-static-check-tool-of-switch-case-handling-3bfc61618b1e
> .
>
> My failing example is at https://go2goplay.golang.org/p/-lQ0jKs8_hU.
>

-- 
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/88aa126b-d8f1-49c0-84cd-c0ea8cd87d39n%40googlegroups.com.

[go-nuts] [generics] Maybe possible to use <> instead of () as type parameter and

[Xie Zhenye]

In the draft, it says:
"Why not use the syntax F like C++ and Java?
When parsing code within a function, such as v := F, at the point of 
seeing the < it's ambiguous whether we are seeing a type instantiation or 
an expression using the < operator. Resolving that requires effectively 
unbounded lookahead. In general we strive to keep the Go parser efficient."

Maybe adding type metadata to an identifier during parsing, and using the 
metadata of an identifier may resolve the ambiguous of type parameter or 
less operator.   For example, '<' after a variable or constant name is a 
less operator and '<' after a function or type name is a type parameter.

<> will be more readable than () and easier to identify type parameter and 
function call.

-- 
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/f8b79cec-6e8e-4d21-8c56-539cb6e7e4c8n%40googlegroups.com.

Re: [go-nuts] Generics: More on parens

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
 wrote:
>
> I, like many others, am not fond of all the parenthesis, particularly at call 
> sites. I think at definition sites, it's not so bad. It seems like the only 
> objection to < and > are the complexity it adds for parsing. It also seems 
> like the only place it adds ambiguity is at call or enstantiation sites. So 
> what if we used . Print.(stringSlice) I think definitions could just swap ()  for < > 
> for generic type parameters, without the dot.
> Aside from that, and wishing that the proposal specified that generics would 
> all be resolved at compile time rather than at run time, I'm really loving 
> this!

Thanks for the note.  I think we should get some experience with
writing code using this syntax before we discard it.

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/CAOyqgcXO2KhFng7ern7%2BQ%3Dsus%2BKA0Rjz4V__zkCiTZYjM27LTg%40mail.gmail.com.

Re: [go-nuts] [generics] Type lists should be usable in any interface

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 8:12 PM Brandon Dyck  wrote:
>
> I find it a little strange that an interface with a type list can only be 
> used as a constraint, and not as the type of a variable or parameter, despite 
> it using basically the same syntax as a normal interface. Is this difference 
> between constraints and other interfaces a property of the type system, or 
> just a limitation of the translation? I don't think it was explicit in the 
> design document. It would certainly be useful to declare variables with 
> type-list interfaces, as it would provide a much less hacky way to define sum 
> types than using an unexported interface method as in 
> https://medium.com/@haya14busa/sum-union-variant-type-in-go-and-static-check-tool-of-switch-case-handling-3bfc61618b1e.
>
> My failing example is at https://go2goplay.golang.org/p/-lQ0jKs8_hU.

We mention this briefly at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
.

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/CAOyqgcX1DS4w4-QbvdqRXGpEKZFJPXCMtM27BK9WiPgbcFg18g%40mail.gmail.com.

[go-nuts] Generics: More on parens

[Aaron Cannon]

I, like many others, am not fond of all the parenthesis, particularly at call 
sites. I think at definition sites, it's not so bad. It seems like the only 
objection to < and > are the complexity it adds for parsing. It also seems like 
the only place it adds ambiguity is at call or enstantiation sites. So what if 
we used .(stringSlice) I think definitions could just swap ()  for < > for 
generic type parameters, without the dot.
Aside from that, and wishing that the proposal specified that generics would 
all be resolved at compile time rather than at run time, I'm really loving this!

Thanks for all the hard work!

Aaron

--
This message was sent from a mobile device

-- 
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/0477C783-B409-4D72-8731-F6691CC856D1%40fireantproductions.com.

[go-nuts] [generics] Some ideas

[Pee Jai]

I read the proposal and am very impressed by it. I have 3 concerns however.

1. `F(type T)(p T) { ... }`

To me, having 2 or 3 sets of parentheses is very weird. All mainstream 
programming languages have only 1 set of parentheses for the function's 
arguments. I've never seen 2 before. I know the proposal says the authors 
of the draft considered other common symbols including colon. *I still 
think `::` seems nicest.*

2. Expanding interfaces to include fields

Currently interfaces can dictate methods only. The proposal also adds type 
lists.
*I propose that for the purposes of generics, the interface also defines 
fields.* This has been rejected numerous times for interfaces (as it is 
now), but for generics, I think it will greatly enhance the power given to 
developers whilst honouring the intention/spirit of the proposal.

See Typescript for guidance. They have successfully implemented interfaces 
that can define fields, type lists and method names in their contracts. The 
team at Microsoft obviously saw a use for it.

3. Compile time.

I started using Go around Go1.3 (the C compiler days). Back then compiling 
was blink-of-an-eye fast. I used it as a selling point to everyone I met at 
meetups (there was minimal uptake of Go back then so it was meetups for 
other languages). Now the compiler is fast but for moderate size projects, 
it's no longer blink-of-an-eye fast. I don't bother hyping this feature any 
more.

Obviously based on how generics is implemented, the compiler will again be 
slower.

*I propose a compile flag so that when developing all the generic type 
checking etc is done at run-time (default behaviour). When ready to build 
for production, a compile flag can use used to move the type checking to 
happen at compile time.*

Thanks for your time,

- pjebs

-- 
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/c0a3a6a2-0c73-4246-ac0b-56da96210ffdo%40googlegroups.com.

[go-nuts] [generics] Type lists should be usable in any interface

[Brandon Dyck]

I find it a little strange that an interface with a type list can only be 
used as a constraint, and not as the type of a variable or parameter, 
despite it using basically the same syntax as a normal interface. Is this 
difference between constraints and other interfaces a property of the type 
system, or just a limitation of the translation? I don't think it was 
explicit in the design document. It would certainly be useful to declare 
variables with type-list interfaces, as it would provide a much less hacky 
way to define sum types than using an unexported interface method as in 
https://medium.com/@haya14busa/sum-union-variant-type-in-go-and-static-check-tool-of-switch-case-handling-3bfc61618b1e.

My failing example is at https://go2goplay.golang.org/p/-lQ0jKs8_hU.

-- 
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/04b721d6-2ccb-43ab-b73e-399d4fcf22b7o%40googlegroups.com.

[go-nuts] subscribe

[Tim Thompson]

-- 
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/CAEPm1L0FqarWM37m8KqhC6MA_dTAZzG1KfT5gAAi5N_aEWKZvA%40mail.gmail.com.

Re: [go-nuts] [generics] Generic functions calls little confusing to readers

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 2:54 PM Alexander Morozov  wrote:
>
> For example consider this example https://play.golang.org/p/rfccpBoFIJN
> There is no generics involved, but for person reading the code there will be 
> additional cognitive load to recognize that it's returned closure call and 
> not generic function call.
> I wonder how could we avoid this confusion (apart from using different 
> brackets :)). Maybe force type keyword in calls as well to show that those 
> arguments are types?

Yes, that kind of seeming ambiguity is definitely possible.  I think
it's an open question whether this kind of code will always be
confusing, or whether we can avoid it with style conventions.  That
is, it's already possible to write confusing code in Go, but people
tend to naturally avoid it by choosing names that clarify the intent.

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/CAOyqgcWjFDno9ZbXRt44RVL5R54Q%2Bxr4bOGw%2B1jXvjN5e_hVwQ%40mail.gmail.com.

Re: [go-nuts] [generics] another parsing ambiguity

[Ian Lance Taylor]

On Tue, Jun 16, 2020 at 4:49 PM Ben Kraft  wrote:
>
> Consider the following code (playground):
>
> type R(type T) struct{}
> func F(type T)() {
>  _ = func() R(T) { return R(T){} }
> }
>
> That is, we have some parameterized type R(T), and a function literal which 
> returns that type R(T). (This is simplified from an example I found while 
> writing generic composition with a result type.)
>
> This currently fails with the following error message: prog.go:5:23: expected 
> operand, found 'return' (the referenced location is indeed the return). (As 
> an aside, this error message was pretty opaque -- not sure if improving that 
> sort of thing is in-scope for the prototype.)
>
> The issue appears to be a parsing ambiguity similar to the one described in 
> the design draft, where func() R(T) has been interpreted as (func() R)(T). 
> But the solution described there doesn't work: writing func() (R(T)) gets 
> parsed as (and gofmted to) func() (R T). That is, it runs into another 
> parsing ambiguity described in the draft. As a further workaround, I 
> eventually realized to use func() (_ R(T)); from there things work fine.
>
> Presumably the solution to the second parsing ambiguity could also work here, 
> if applied to function returns; of course that expands the compatibility 
> break described there.
>
> Not sure if this qualifies as discussion or a bug report; I figured I'd start 
> here but happy to make an issue if that's preferred.

Interesting case.  At the very least we need to describe this case in
the design draft.  Maybe there is a way that we can fix it.

Please do open a bug report for this.  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/CAOyqgcUqez0LzFbSuYcGa5T4ZUhnhAO6jhSrdMfohGw4K6bSzQ%40mail.gmail.com.

[go-nuts] [generics] another parsing ambiguity

[Ben Kraft]

Consider the following code (playground 
):

type R(type T) struct{}
func F(type T)() {
 _ = func() R(T) { return R(T){} }
}

That is, we have some parameterized type R(T), and a function literal which 
returns that type R(T). (This is simplified from an example I found while 
writing generic composition with a result type.)

This currently fails with the following error message: prog.go:5:23: 
expected operand, found 'return' (the referenced location is indeed the 
return). (As an aside, this error message was pretty opaque -- not sure if 
improving that sort of thing is in-scope for the prototype.)

The issue appears to be a parsing ambiguity similar to the one described in 
the design draft 
,
 
where func() R(T) has been interpreted as (func() R)(T). But the solution 
described there doesn't work: writing func() (R(T)) gets parsed as (and 
gofmted to) func() (R T). That is, it runs into another parsing ambiguity 
described in the draft 
.
 
As a further workaround, I eventually realized to use func() (_ R(T)); from 
there things work fine.

Presumably the solution to the second parsing ambiguity could also work 
here, if applied to function returns; of course that expands the 
compatibility break described there.

Not sure if this qualifies as discussion or a bug report; I figured I'd 
start here but happy to make an issue if that's preferred.

-- 
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/2575e57e-d79c-494a-b4b0-9a773171f1c2n%40googlegroups.com.

[go-nuts] Re: [generics] Generic functions calls little confusing to readers

[Zach Easey]

Interesting find, I would expect type parameter declarations to be limited 
to interfaces.

On Tuesday, June 16, 2020 at 2:54:02 PM UTC-7, Alexander Morozov wrote:
>
> For example consider this example https://play.golang.org/p/rfccpBoFIJN
> There is no generics involved, but for person reading the code there will 
> be additional cognitive load to recognize that it's returned closure call 
> and not generic function call.
> I wonder how could we avoid this confusion (apart from using different 
> brackets :)). Maybe force type keyword in calls as well to show that those 
> arguments are types?
>

-- 
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/b68edacf-07ab-4dc7-898a-1610204fbddco%40googlegroups.com.

Re: [go-nuts] Re: pure-go implementation of sqlite

['Dan Kortschak' via golang-nuts]

This is at https://modernc.org/sqlite now, along with the rest of Jan's
amazing things, https://gitlab.com/cznic.

On Tue, 2020-06-16 at 12:27 -0700, Mandolyte wrote:
> SQLite3 support is the stated goal of 
> https://github.com/elliotchance/c2go
> 
> Also, I believe I tested this one a long time ago... but have lost
> track of it after they moved away from Github:
> https://github.com/cznic/sqlite
> 
> 
> 
> On Monday, June 15, 2020 at 12:57:54 PM UTC-4, Douglas Manley wrote:
> > No, unfortunately this just replaces the need for gcc for SQLite3
> > with the need for gcc for Sqinn.  My goal is to have a SQL database
> > for use in Go that is 100% pure Go with zero outside dependencies. 
> > My primary use case is for unit-testing large applications that
> > rely on SQL databases such that no one on the project has to do
> > anything other than install Go to build and test them.
> > 
> > On Monday, June 15, 2020 at 12:31:07 PM UTC-4 cvilsmeier wrote:
> > > Maybe Sqinn-Go can help you:
> > > https://github.com/cvilsmeier/sqinn-go
> > > (I'm the author of it)
> > > 
> 
> -- 
> 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/2c533170-33b5-4eb5-9f58-25c88f34710fo%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/8feafd170a2269c12535927bc09f52fb51af66d5.camel%40kortschak.io.

[go-nuts] [generics] Generic functions calls little confusing to readers

[Alexander Morozov]

For example consider this example https://play.golang.org/p/rfccpBoFIJN
There is no generics involved, but for person reading the code there will 
be additional cognitive load to recognize that it's returned closure call 
and not generic function call.
I wonder how could we avoid this confusion (apart from using different 
brackets :)). Maybe force type keyword in calls as well to show that those 
arguments are types?

-- 
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/63a21024-95d3-474c-9b42-e7b7f913cdadn%40googlegroups.com.

Re: [go-nuts] Black Lives Matter question

[Russ Cox]

Sorry, but this thread is definitely off-topic here. I'm going to lock this
conversation.

Best,
Russ


On Tue, Jun 16, 2020 at 4:53 PM Jon Perryman  wrote:

> Sorry for this being a little off topic but unlike the media which thinks
> with the heart, programmers tend to think with their head. I want to
> believe in the idea of "systemic police racism" over blaming all police for
> a few bad cops. Since this group supports the idea of "systemic police
> racism", my question is where can I find the facts that suggest "systemic
> police racism" is true?
>
> Please don't start a discussion because I only want to see the facts for
> myself. I will only read short simple responses and better would be a
> trusted website.
>
> Here are some facts I collected. I analyzed the FBI and CDC databases but
> they show violence, fear, distrust and disrespect from both sides instead
> of racism. Murder arrests (not a white privilege crime) are 5 times as many
> blacks as whites (by group population). The media report facts to prove
> "systemic police racism" such as police kill 4.9 times as many blacks as
> whites (by group population) but never mention that in a "police / suspect"
> situation, 68 times as many police officers die as blacks (by group
> population). No one mentions that we could save more than 7,000 black men
> each year killed by gun by outlawing firearms.
>
> From the Washington Post, totals for 2015 to 2019
>   4.9 unarmed Black men per million by police
>   1.1 unarmed Hispanic men per million by police
>   1.0 unarmed White men per million by police
>
> From my calculations for 2015 to 2019
>   331 police officers feloniously murdered per million
>   1,952 black male murder victims per million
>   1,590 black male murder victims by gun per million
>   188 white male murder victims per million
>
>  Arrests: Murder and nonnegligent manslaughter
>   5,025 black 46% (115 per million   68%)
>   4,188 white 38% (21 per million   12%)
>   1,462 hispanic 13% (24 per million   14%)
>   255 other 2% (10 per million   6%)
>
> Arrests: Weapons; carrying, possessing, etc.
>   56,143 black 37% (1,286 per million   60%)
>   68,787 white 46% (347 per million   16%)
>   23,125 hispanic 15% (385 per million   18%)
>   3,079 other 2% (117 per million   5%)
>
> Arrests: Rape
>   5,182 black 24% (119 per million   44%)
>   12,187 white 56% (61 per million   23%)
>   3,787 hispanic 17% (63 per million   23%)
> 694 other 3% (26 per million   10%)
>
> Arrests: Aggravated assault
>   101,513 black 28% (2,325 per million   48%)
>   188,087 white 52% (949 per million   20%)
>   61,107 hispanic 17% (1,017 per million   21%)
>   13,341 other 4% (508 per million   11%)
>
> Arrests: Violent crime
>   151,744 black 31% (3,476 per million   53%)
>   236,590 white 49% (1,193 per million   18%)
>   79,078 hispanic 16% (1,316 per million   20%)
>   15,902 other 3% (606 per million   9%)
>
> Graphically, this shows that for violent crimes, Hispanics and whites are
> similar but blacks are significantly higher.
>
> [image: image.png]
>
>
> https://www.fbi.gov/news/pressrel/press-releases/fbi-releases-2019-statistics-on-law-enforcement-officers-killed-in-the-line-of-duty
>
> https://www.cdc.gov/nchs/data/nvsr/nvsr67/nvsr67_05.pdf
>
> https://ucr.fbi.gov/crime-in-the-u.s/2017/crime-in-the-u.s.-2017/tables/table-43
> (2017 is most recent)
>
> --
> 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/CAByJhJmqerF72EV4S7uUWLxU7ZFm_T7gjoWfSeH%2BAcfeDqWCZA%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/CAA8EjDQtH%3DMupu0maN0-u833qrXCw2CDPiSCTwLBWpxSgGMBeg%40mail.gmail.com.

[go-nuts] Go Generics using interfaces - alternative take

[Arnaud Delobelle]

Hi everyone,

I noticed today the blog post about the revised Generics proposal.  What 
got me excited is this extract at the start:

*The biggest change is that we are dropping the idea of contracts. The 
difference between contracts and interface types was confusing, so we’re 
eliminating that difference.*

To me the lack of orthogonality between contracts and interfaces was the 
major issue with the previous proposal and I have been musing with ways of 
resolving it for a while, so I am very pleased that the proposal is going 
down this path!

Last month I decided to write a post about a way of introducing Generics 
into Go using interfaces,  which I called "Package Specialization".

Headline features are:

   - *use interfaces to express parametric types*;
   - no new keyword;
   - the only new syntax is “package specialization”: pkg(T=int, 
   Y=*MyType).Func();
   - generic code which doesn’t use the package specialization syntax is 
   already valid Go.

The full post can be read here: 
https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2.html

I was toying with the idea of submitting it here for feedback, to try to 
move the discussion in that direction.  Well, I guess today's updated 
proposal steals my thunder! Essentially this is the same idea, but with a 
different manifestation in the language - I thought that submitting it 
anyway may provide a useful comparison point to help gauge the updated 
proposal better.

Note that sadly, I do not have much time to polish a proposal or to follow 
discussions in general on this or other golang-related discussion lists, so 
I apologize in advance if I am inadvertently re-hashing ideas that have 
been put forward and dismissed in the past, or if my blog post is a little 
low on detail (it was meant to be an exploration of a possible approach).

Kinds regards,

Arnaud Delobelle

-- 
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/d47d543e-1ac0-4145-ab4a-11c20aea462bn%40googlegroups.com.

[go-nuts] Black Lives Matter question

[Jon Perryman]

Sorry for this being a little off topic but unlike the media which thinks
with the heart, programmers tend to think with their head. I want to
believe in the idea of "systemic police racism" over blaming all police for
a few bad cops. Since this group supports the idea of "systemic police
racism", my question is where can I find the facts that suggest "systemic
police racism" is true?

Please don't start a discussion because I only want to see the facts for
myself. I will only read short simple responses and better would be a
trusted website.

Here are some facts I collected. I analyzed the FBI and CDC databases but
they show violence, fear, distrust and disrespect from both sides instead
of racism. Murder arrests (not a white privilege crime) are 5 times as many
blacks as whites (by group population). The media report facts to prove
"systemic police racism" such as police kill 4.9 times as many blacks as
whites (by group population) but never mention that in a "police / suspect"
situation, 68 times as many police officers die as blacks (by group
population). No one mentions that we could save more than 7,000 black men
each year killed by gun by outlawing firearms.

>From the Washington Post, totals for 2015 to 2019
  4.9 unarmed Black men per million by police
  1.1 unarmed Hispanic men per million by police
  1.0 unarmed White men per million by police

>From my calculations for 2015 to 2019
  331 police officers feloniously murdered per million
  1,952 black male murder victims per million
  1,590 black male murder victims by gun per million
  188 white male murder victims per million

 Arrests: Murder and nonnegligent manslaughter
  5,025 black 46% (115 per million   68%)
  4,188 white 38% (21 per million   12%)
  1,462 hispanic 13% (24 per million   14%)
  255 other 2% (10 per million   6%)

Arrests: Weapons; carrying, possessing, etc.
  56,143 black 37% (1,286 per million   60%)
  68,787 white 46% (347 per million   16%)
  23,125 hispanic 15% (385 per million   18%)
  3,079 other 2% (117 per million   5%)

Arrests: Rape
  5,182 black 24% (119 per million   44%)
  12,187 white 56% (61 per million   23%)
  3,787 hispanic 17% (63 per million   23%)
694 other 3% (26 per million   10%)

Arrests: Aggravated assault
  101,513 black 28% (2,325 per million   48%)
  188,087 white 52% (949 per million   20%)
  61,107 hispanic 17% (1,017 per million   21%)
  13,341 other 4% (508 per million   11%)

Arrests: Violent crime
  151,744 black 31% (3,476 per million   53%)
  236,590 white 49% (1,193 per million   18%)
  79,078 hispanic 16% (1,316 per million   20%)
  15,902 other 3% (606 per million   9%)

Graphically, this shows that for violent crimes, Hispanics and whites are
similar but blacks are significantly higher.

[image: image.png]

https://www.fbi.gov/news/pressrel/press-releases/fbi-releases-2019-statistics-on-law-enforcement-officers-killed-in-the-line-of-duty

https://www.cdc.gov/nchs/data/nvsr/nvsr67/nvsr67_05.pdf
https://ucr.fbi.gov/crime-in-the-u.s/2017/crime-in-the-u.s.-2017/tables/table-43
(2017 is most recent)

-- 
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/CAByJhJmqerF72EV4S7uUWLxU7ZFm_T7gjoWfSeH%2BAcfeDqWCZA%40mail.gmail.com.

[go-nuts] Re: pure-go implementation of sqlite

[Mandolyte]

SQLite3 support is the stated goal of https://github.com/elliotchance/c2go

Also, I believe I tested this one a long time ago... but have lost track of 
it after they moved away from Github:
https://github.com/cznic/sqlite



On Monday, June 15, 2020 at 12:57:54 PM UTC-4, Douglas Manley wrote:
>
> No, unfortunately this just replaces the need for gcc for SQLite3 with the 
> need for gcc for Sqinn.  My goal is to have a SQL database for use in Go 
> that is 100% pure Go with zero outside dependencies.  My primary use case 
> is for unit-testing large applications that rely on SQL databases such that 
> no one on the project has to do anything other than install Go to build and 
> test them.
>
> On Monday, June 15, 2020 at 12:31:07 PM UTC-4 cvilsmeier wrote:
>
>> Maybe Sqinn-Go can help you:
>> https://github.com/cvilsmeier/sqinn-go
>> (I'm the author of it)
>>
>>

-- 
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/2c533170-33b5-4eb5-9f58-25c88f34710fo%40googlegroups.com.

[go-nuts] [security] Vulnerability in golang.org/x/text/encoding/unicode

[Katie Hockman]

Hello gophers,

Version v0.3.3 of golang.org/x/text fixes a vulnerability in the
golang.org/x/text/encoding/unicode package which could lead to the UTF-16
decoder entering an infinite loop, causing the program to crash or run out
of memory.

An attacker could provide a single byte to a UTF16

decoder instantiated with UseBOM or ExpectBOM to trigger an infinite loop
if the String

function on the Decoder is called, or the Decoder is passed to
golang.org/x/text/transform.String
.

transform.String has also been hardened not to enter an infinite loop if a
Transformer
 keeps
returning ErrShortSrc
 even
if atEOF is true.

This issue was first filed as Issue 39491 
by GitHub user abacabadabacaba  and
reported to the security team by Anton Gyllenberg. It is tracked as
CVE-2020-14040.

Cheers,

Katie for the Go team

-- 
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/CALvTBvc82P_AsSDvrDb8b%3D7sbX05vtdxG3n%2BzuvzvrthDCfHXQ%40mail.gmail.com.

[go-nuts] Re: Unable to send continuous event logs using template

[Brian Candler]

text/event-stream is not text/html.  text/event-stream is exactly that: a 
stream of (plain text) messages.  If you point a browser directly at this 
URL, it will render the stream as plain text.

If you want pretty rendering, what you need is a wrapper HTML page which 
contains some Javascript to read the event stream and insert the events 
into your HTML page as they arrive.

The concepts aren't Go-specific, so any page that talks about event stream 
(aka "server-sent events" or "eventsource") should help you.  Here are the 
first few I found:

https://www.html5rocks.com/en/tutorials/eventsource/basics/
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
https://www.w3schools.com/html/html5_serversentevents.asp

-- 
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/16a4874c-2462-45d5-a94e-9eaa0faf6b22o%40googlegroups.com.

[go-nuts] Re: Build Issues on Ubuntu

[Chris Hopkins]

We have a winner!
Lots of attempts to read /usr/local/go/src/syscall, which is very read only
And not any go install it should be using, looks like GOTOOL was pointing 
at the wrong place(the default install, not any of the ones I did). No idea 
who is setting that up, but I can soon fix that.

Thanks!



On Tuesday, 16 June 2020 10:33:16 UTC+1, Brian Candler wrote:
>
> On Monday, 15 June 2020 21:59:21 UTC+1, Chris Hopkins wrote:
>>
>> The ubuntu default 1.14.4
>> https://dl.google.com/go/go1.14.4.src.tar.gz
>>
>
> What about the 1.14.4 precompiled binary?
> https://dl.google.com/go/go1.14.4.linux-amd64.tar.gz
>
> 
> I t might be worth 
> looking at the last few pages of strace output just before it crashes:
> strace -f go build blah
> to see if it gives any clues.
>
>

-- 
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/c1691022-6139-4481-b9cf-e9cdeda26910o%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Ian Lance Taylor]

This thread is visibly not working.

I would like to ask everyone to do their very best to let this thread
drop.  Please do not try to get the last word.

If you absolutely must continue, I strongly encourage you to take it
to private e-mail, off the list.

This applies to everyone, regardless of your position on the issues.

Thank you.

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/CAOyqgcUaJHU1pyzheJpk6Ah1VuN3ZZ7_mejw%2BB8d0k3ywYZ56g%40mail.gmail.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[K Richard Pixley]

On 6/16/20 09:04, 'Thomas Bushnell, BSG' via golang-nuts wrote:

On Tue, Jun 16, 2020 at 11:51 AM 'K Richard Pixley' via golang-nuts 
mailto:golang-nuts@googlegroups.com>> 
wrote:


I do not agree with the Rust team.  I would prefer to make my
technology decisions based on technological criterion.  But if you
force me to make that decision based on your religion, on your
specific brand of racism, then I will.


How does seeing the banner force you to stop using Go, even if you 
disagree with its message?
If using go necessarily means supporting racism, then I will be forced 
to stop.
I don't see how that follows at all. First of all, I reject the notion 
that an anti-racism
It's not "anti-racism", though.  It's pro-racism.  It may be a popular 
racism, but it's pro-racism.
banner creates a "cesspool" or even moves toward that even a hair's 
breadth. But I don't understand why you think that if one cause is 
advertised, all should be, or that if a non-abusive banner is present, 
then abusive ones must be allowed too.


Exactly.  So we need to remove the abusive banner.

Jumping up a level, I think you can see that there isn't agreement 
here.  We haven't even agreed on terms.  And attempting to do so isn't 
really in the charter of this group.


--
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/12bf3c90-6ca2-26b7-7d86-c09e55b9beb8%40noir.com.

Re: [go-nuts] Re: political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

On Tue, Jun 16, 2020 at 11:51 AM 'K Richard Pixley' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I do not agree with the Rust team.  I would prefer to make my technology
> decisions based on technological criterion.  But if you force me to make
> that decision based on your religion, on your specific brand of racism,
> then I will.
>

How does seeing the banner force you to stop using Go, even if you disagree
with its message?

> The only other alternative keeping with the code of conduct requires many
> other viewpoints and opinions to be expressed and that process alone would
> kill the utility of these forums turning them into yet another cesspool of
> religious disagreement.  We're not going to agree on these social issues.
> Agreement with any particular religion should not be required to
> participate nor should we be required to endure social abuse to do so
>
I don't see how that follows at all. First of all, I reject the notion that
an anti-racism banner creates a "cesspool" or even moves toward that even a
hair's breadth. But I don't understand why you think that if one cause is
advertised, all should be, or that if a non-abusive banner is present, then
abusive ones must be allowed too.

Thomas

-- 
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/CA%2BYjuxvcCKFi6_vRTkb6NNuv%3DQHvrNnMVEGMGfGox_PV04OXCw%40mail.gmail.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[David Riley]

On Tuesday, June 16, 2020 at 11:52:10 AM UTC-4, K Richard Pixley wrote:
>
> There is agreement on the code of conduct.  There is not agreement on the 
> banner.  IMO, the banner is out of line with the goals of this group and 
> with the code of conduct.  It's inappropriate.  It needs to be removed.
>
>
> You're welcome to submit a CL and have the community vote on it. I look 
forward to voting on your submission.

-- 
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/67296c2b-add0-4c62-9204-03e0388ea0d1o%40googlegroups.com.

[go-nuts] Unable to send continuous event logs using template

[smartaquarius10]

I'm little new with golang and first time working with html templates. I 
need to send continuous event logs(server sent events) to the client side 
for which I am using flusher.

I'm facing 2 different issues here:

   1. The moment I add these 3 lines

--

w.Header().Add("Content-Type", "text/event-stream")
w.Header().Add("Cache-Control", "no-cache")
w.Header().Add("Connection", "keep-alive")

--

the styles disappears from the website automatically and appears on the 
browser like this[image: enter image description here] 

--

   1. I tried to use flusher and continuously updated the body template in 
   loop for refreshing the time after every 20 seconds using this code:

--

// for {
//  time.Sleep(20 * time.Second)
//  welcome.Time = time.Now().Format(time.Stamp)
//  if err := templates.ExecuteTemplate(w, "body", welcome); err != nil 
{
//  http.Error(w, err.Error(), http.StatusInternalServerError)
//  }
//  //fmt.Fprintf(w, "data: %s\n", in.Text())
//  flusher.Flush()
// }

The moment I uncomment it, rather than updating the same section on the web 
page, template started repeating like this

Welcome Anonymous, it is Jun 16 13:09:19Jun 16 13:09:39Jun 16 13:09:59

--

I would be grateful if someone help me here please.

*The structure of my project is:*

Project
  |_ _client
|_ _ welcome-template.css
|_ _ background.jpeg
  |_ _ main.go 

*Main.go*

package main
import (
"fmt"
"html/template"
"net/http"
"time")

type Welcome struct {
Name string
Time string}

func main() {
htm := `{{define "layout"}}



   
 
 

 Welcome {{.Name}}
   
   
  Welcome {{.Name}}, it is {{template 
"body" .}}
   

{{end}}`
tim := `{{define "body"}}{{.Time}}{{end}}`
welcome := Welcome{"Anonymous", time.Now().Format(time.Stamp)}
templates := template.Must(template.New("layout").Parse(htm))
templates = template.Must(templates.Parse(tim))
http.Handle("/client/", http.StripPrefix("/client/", 
http.FileServer(http.Dir("client"  

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
// flusher, ok := w.(http.Flusher)
// if !ok {
//  http.Error(w, "Streaming not supported", 
http.StatusInternalServerError)
//  return
// }

w.Header().Add("Content-Type", "text/event-stream")
w.Header().Add("Cache-Control", "no-cache")
w.Header().Add("Connection", "keep-alive")
if name := r.FormValue("name"); name != "" {
welcome.Name = name
}
if err := templates.ExecuteTemplate(w, "layout", welcome); err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
}
// for {
//  time.Sleep(20 * time.Second)
//  welcome.Time = time.Now().Format(time.Stamp)
//  if err := templates.ExecuteTemplate(w, "body", welcome); err != nil 
{
//  http.Error(w, err.Error(), http.StatusInternalServerError)
//  }
//  //fmt.Fprintf(w, "data: %s\n", in.Text())
//  flusher.Flush()
// }

})
fmt.Println("Listening")
fmt.Println(http.ListenAndServe(":8080", nil))}

*Welcome-Template.css*

body  {
   min-height:100%;
   background-image: url("/client/background.jpeg"), 
linear-gradient(rgba(0,0,0,0.2),rgba(0,0,0,0.3));
   background-blend-mode: overlay;
   background-size:cover;}
.welcome {
   font-family: 'Segoe UI', 'Tahoma', 'Geneva', 'Verdana', 'sans-serif';
   font-size: 3rem;
   color: aliceblue;}
.center {
   height: 100vh;
display: flex;
justify-content: center;
align-items: center;}

-- 
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/11c55d49-cf81-4fd9-81fb-ba72639d7c08o%40googlegroups.com.

[go-nuts] Golang Developers in Hyderabad

[VIshal Nale]

If you have experience in Golang and want to work with IBM then lets 
connect ... I have a good opportunity in my team.

-- 
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/9ec2ae02-b4ca-4684-9e95-a3bb05a71fcfo%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

['K Richard Pixley' via golang-nuts]

On 6/16/20 5:00 AM, Russ Cox wrote:
...I will quote from the Code of Conduct here – “regardless of gender 
identity and expression, sexual orientation, disabilities, 
neurodiversity, physical appearance, body size, ethnicity, 
nationality, race, age, religion, or similar personal characteristics.”


The banner on our sites is a continuation of that effort, recognizing 
that at this moment:


Except that it's not.  That's part of the problem.  IMO, and many other 
people's opinions, the banner is /counter/ to those goals.


I do not agree with the Rust team.  I would prefer to make my technology 
decisions based on technological criterion.  But if you force me to make 
that decision based on your religion, on your specific brand of racism, 
then I will.


There is agreement on the code of conduct.  There is not agreement on 
the banner.  IMO, the banner is out of line with the goals of this group 
and with the code of conduct.  It's inappropriate.  It needs to be removed.


The only other alternative keeping with the code of conduct requires 
many other viewpoints and opinions to be expressed and that process 
alone would kill the utility of these forums turning them into yet 
another cesspool of religious disagreement.  We're not going to agree on 
these social issues.  Agreement with any particular religion should not 
be required to participate nor should we be required to endure social 
abuse to do so.


--
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/a3e1095d-90c0-974c-b6e3-04ebda9b0a51%40juniper.net.

Re: [go-nuts] Re: political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

On Tue, Jun 16, 2020 at 10:41 AM Space A.  wrote:

>
> Are you saying you don't care about the rest of the World? This
> "situation" does not affect in any way many many gophers which have to deal
> with much more serious problems than you could imagine, on a daily basis.
> There are a lot of projects originating not from US, who are not trying to
> get you attention (and money) by putting on top political topics which they
> think are important and "affecting" everyone.
>
> That's pretty much easy to make this banner appear based on location. But
> if you insist, I can for sure update ABP filters with a couple of clicks.
> Never though I would have to do this on programming language main page.
>

I'm a bit confused.  You're correct that there are many worthy causes. I'm
confused about why that means this one shouldn't be supported, or that you
need to filter the notice out. How does that help the other worthy causes
you mention?

Thomas

-- 
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/CA%2BYjuxt5vSBwo6P2j5QvoVrxe30jUwpBqRDj1yGXMUEp2iYPLA%40mail.gmail.com.

[go-nuts] Re: political fundraising on golang.org!

[Nate Finch]

Raise your hand if you think black lives don't matter?
Raise your hand if you think "[providing] legal representation to prisoners 
who may have been wrongly convicted of crimes, poor prisoners without 
effective representation, and others who may have been denied a fair 
trial." is a bad thing?

Ok, so what are we talking about?

On Sunday, June 14, 2020 at 9:36:38 AM UTC-4, peterGo wrote:
>
> Recently, a political message with a fundraising link appeared as a banner 
> atop golang.org websites: https://golang.org/, https://pkg.go.dev/.
>
> content/static: add Black Lives Matter banner to top of site
> https://go-review.googlesource.com/c/website/+/237589
>
> 
> Black Lives Matter.
> https://support.eji.org/give/153413/#!/donation/checkout;
>target="_blank"
>rel="noopener">Support the Equal Justice Initiative.
> 
>
> How was this decision made?
>
> Go is a programming language. For political fundraising use personal 
> Twitter and Facebook accounts. 
>
> Peter
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de276cb2-b47f-496e-8098-6fa870125faeo%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Space A.]

> To people who object to the banner as too focused on the United States: 
> Google and Go both started here, nearly all of the Go team is here, a 
> substantial number of Go community members live here, and many others 
> travel here for conferences or other reasons. The situation here affects 
> gophers worldwide.
>
>  
Are you saying you don't care about the rest of the World? This "situation" 
does not affect in any way many many gophers which have to deal with much 
more serious problems than you could imagine, on a daily basis. There are a 
lot of projects originating not from US, who are not trying to get you 
attention (and money) by putting on top political topics which they think 
are important and "affecting" everyone.

That's pretty much easy to make this banner appear based on location. But 
if you insist, I can for sure update ABP filters with a couple of clicks. 
Never though I would have to do this on programming language main page.


 

-- 
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/0e9797d6-c7d4-429d-bf1e-592666b75868o%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Russ Cox]

Hi everyone,

I wanted to reply here to acknowledge the feedback on this thread. I hear
those of you who are uncomfortable with the banner, and I appreciate the
honest and mostly constructive discussion here.

As the Rust team said well, tech is and will always be political, not in
the sense of political parties but in the sense of affecting societal
decisions about how opportunities and resources are allocated. The actions
we take or decide not to take unavoidably affect who has the opportunity to
learn Go, not to mention the opportunities that working as a Go developer
can bring. Last November when Go turned 10 I wrote
 that “what we’re most proud of about Go
is not a well-designed feature or a clever bit of code but the positive
impact Go has had in so many people’s lives.” We must not be blind to the
fact that the impact on people’s lives is not equally distributed – not as
widely available as it can or should be. Through actions like adopting a
Code of Conduct and supporting organizations like GoBridge, the Go team and
the Go community have for years promoted efforts to broaden Go’s reach and
stand up for all gophers – and I will quote from the Code of Conduct here –
“regardless of gender identity and expression, sexual orientation,
disabilities, neurodiversity, physical appearance, body size, ethnicity,
nationality, race, age, religion, or similar personal characteristics.”

The banner on our sites is a continuation of that effort, recognizing that
at this moment:

   - There are problems and inequities affecting gophers that extend far
   beyond what we can reach with things like a Code of Conduct or additional
   training opportunities.
   - There is a societal reckoning going on here in the United States, of a
   scale that hasn’t happened in over 50 years, that may lead to real change
   for many current gophers and hopefully many more future gophers.
   - It is important to lend our voices to these efforts, both to support
   our community members and to help influence those societal decisions I
   mentioned. Not speaking up, like not adopting a Code of Conduct, is a way
   of saying everything is fine the way it is. Everything is not fine.
   - Gophers may want to help but not know where to start. Donating to the
   Equal Justice Initiative is only one possible way, but it is a concrete
   specific action. (As others pointed out, EJI is a well-respected non-profit
   not affiliated with a U.S. political party.)

I gladly credit other open source projects, including React, Express, and
OpenTelemetry, for leading the way and inspiring us on the Go team to add
this banner. We are happy to join them in making this important statement
and specific suggestion.

To people who object to the banner as too focused on the United States:
Google and Go both started here, nearly all of the Go team is here, a
substantial number of Go community members live here, and many others
travel here for conferences or other reasons. The situation here affects
gophers worldwide.

To people who think technology can be apolitical or neutral: let me say
that when I started working on Go over a decade ago I thought the same
thing. If you’re not the one being discriminated against – if the playing
field is tilted in your favor – it is very easy not to notice that fact. If
you are interested in an honest, critical examination of that belief, let
me recommend reading this essay by Peggy McIntosh

and
then spending the next week building a similar list of examples specific to
the tech industry.

Posting this banner on our web sites, affirming that Black Lives Matter and
suggesting one possible concrete action to help, is almost literally the
least we can do in support of the (far too few) Black gophers in our
community. The discussion on this list has at times gotten a little heated,
but I hope that it prompts at least a few gophers reading along to become
more aware of these real problems and hopefully to think about ways to help
make change. If so, the banner is working as intended.

Best,
Russ

-- 
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/CAA8EjDQwFiFGNvty5tUTt%2BTYg7sgFrin5T%3DaDP%2B6qPx82qD%3DhQ%40mail.gmail.com.

Re: [go-nuts] pure-go implementation of sqlite

[Misha Gusarov]

On 16 Jun 2020, at 12:35, a2800276 wrote:

> Can you elaborate a little bit on the motivation? I've been using go-sqlite
> on both amd64 and arm64 with absolutely no problem.

The biggest obstacle for me (I'm not the topic-starter) is a loss of
out-of-the-box cross-compilation.

Can be ameliorated somehow by using musl-based toolchain for Linux targets,
but it's still a hassle.

-- 
Misha

-- 
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/46C13306-162D-4CE9-8E5E-04D0497CAE76%40ridge.co.

Re: [go-nuts] Re: pure-go implementation of sqlite

[Harmen]

> > is there (or is somebody working on) a pure-go implementation of sqlite ? 
> > or at least a subset of it, to be able to read sqlite files ? 
> >
> > -s 
> >
> > PS: I know about the (by now) canonical implementations 
> > (mattn/go-sqlite and others) but a completely go-based solution would 
> > facilitate deployment and development across devs machines... 

If you only need to read, and not write, sqlite files, have a look at
https://github.com/alicebob/sqlittle

-- 
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/20200616103957.GA6629%40arp.lijzij.de.

[go-nuts] Re: pure-go implementation of sqlite

[a2800276]

>
> is there (or is somebody working on) a pure-go implementation of sqlite ? 
> or at least a subset of it, to be able to read sqlite files ? 
>
> -s 
>
> PS: I know about the (by now) canonical implementations 
> (mattn/go-sqlite and others) but a completely go-based solution would 
> facilitate deployment and development across devs machines... 
>

sqlite is a bit of a special case, because the C implementation IS sqlite, 
they have a very stable development and testing setup and my trust in 
sqlite is basically trust in the developers of the C code. 
I don't see the advantage of having a Go implementation, expect for the 
sake of Go purity...
Can you elaborate a little bit on the motivation? I've been using go-sqlite 
on both amd64 and arm64 with absolutely no problem.

 

-- 
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/4a05f73f-8915-419d-b9cd-459d41e2e485o%40googlegroups.com.

[go-nuts] Re: Build Issues on Ubuntu

[Brian Candler]

On Monday, 15 June 2020 21:59:21 UTC+1, Chris Hopkins wrote:
>
> The ubuntu default 1.14.4
> https://dl.google.com/go/go1.14.4.src.tar.gz
>

What about the 1.14.4 precompiled binary?
https://dl.google.com/go/go1.14.4.linux-amd64.tar.gz


I t might be worth 
looking at the last few pages of strace output just before it crashes:
strace -f go build blah
to see if it gives any clues.

-- 
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/6e8f8450-cd16-499c-bd14-aa41becf33bfo%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Rusco]

After all (I think this has been discussed already ), who is owner of the 
Golang Project ? Isn't this supposed to be an open source / community based 
project ? 
What about mine political ideas, can I put them also on golang's front 
page, since I am part of the community ?

Where will we end up in some years if this continues, in middle age 
inquisition times with some new Jesuits popping up judging others for their 
political correctness ? 
Isn't Twitter and other social networks enough for articulating political 
opinions, or someone wants to force them upon us ?  

This is very bad smelling, I vote for leaving golangs' homepage neutral as 
for now ! Golang.org for golang.org, Twitter and other for politics. 

-- 
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/6ef509ad-c360-46a1-8959-4391980fd129o%40googlegroups.com.

Re: [go-nuts] Build Issues on Ubuntu

[Chris Hopkins]

Yep, the asyncpreempt has definitly made it work.(But for how long Dun Dun 
Dun!!!)

Humm, interesting. Thanks I can do some more investigation now.


Kind Regards

Chris

On Monday, 15 June 2020 22:27:00 UTC+1, Ian Lance Taylor wrote:
>
> On Mon, Jun 15, 2020 at 1:59 PM Chris Hopkins  > wrote: 
> > 
> > Hi, 
> > (Sorry I've not been active in the group for a long time - job change 
> caused other changes!) 
> > I'm seeing a very strange error on building on one of my machines, in 
> fact I'm seeing it on any attempt to build any go project on that machine 
> e.g. 
> > 
> > ~/home/git/src/github.com/cbehopkins/medorg$ go build 
> check_calc/main.go 
> > check_calc/main.go:8:2: read /home/xxx/home/git/src/
> github.com/cbehopkins/medorg/checksum_test.go: read 
> /home/xxx/home/git/src/github.com/cbehopkins/medorg/checksum_test.go: 
> interrupted system call 
> > 
> > Builds on other machines work fine, so it's something specific to this 
> one. 
> > Literally a hello world does this. I suspected at first it being linked 
> to how that directory is mounted (it's a samba share), but the same happens 
> on the native file system. 
> > Go versions I've used: 
> > The ubuntu default 1.14.4 
> > https://dl.google.com/go/go1.14.4.src.tar.gz 
> > 14.4 built on a different machine and then copied locally (tricky to do 
> as it requires cross compliation). 
> > 
> > The only unique thing aboout this machine, is it is the only one on my 
> network that is both x86 & Linux, other combinations of x86 and OS work 
> fine. Any hints/ideas on how to debug this would be greatly appriciated. 
> (The OS is 
> > Ubuntu 20.04 LTS) 
>
> I don't know why this is happening, but you can probably make progress 
> by setting 
>
> GODEBUG=asyncpreemptoff=1 
>
> That won't fix the general problem, but it will make it happen less 
> frequently. 
>
> 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/7ce84640-1dd8-4440-974c-945f1929ab43o%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[sanye]

On 6/16/20 2:43 PM, Sam Whited wrote:

So you're suggesting that because we can't help all people all of the
time we should help no one at any time? That is a logical fallacy. Right
now in this moment there are protests all over the world about a
specific issue, so yes, a specific cause is being supported because the
time is right, and that is perfectly okay.

—Sam

/    no, we can, maybe put more banners on the page?/



On Mon, Jun 15, 2020, at 21:53, sanye wrote:

Because there are hundreds or thousands of initiatives to support
suffering and dying people in African, Asian, Eastern European, and
what else countries that will never be supported by top banner at
golang.org.

  That's right.


--
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/07eedfb2-8afe-0b1c-e901-a96b0c356209%40gmail.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Sam Whited]

So you're suggesting that because we can't help all people all of the
time we should help no one at any time? That is a logical fallacy. Right
now in this moment there are protests all over the world about a
specific issue, so yes, a specific cause is being supported because the
time is right, and that is perfectly okay.

—Sam

On Mon, Jun 15, 2020, at 21:53, sanye wrote:
> > Because there are hundreds or thousands of initiatives to support
> > suffering and dying people in African, Asian, Eastern European, and
> > what else countries that will never be supported by top banner at
> > golang.org.
>  That's right.

-- 
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/8191276c-7f8e-418b-b46f-0d1614a59885%40www.fastmail.com.