[go-nuts] about generic?

[xie cui]

https://github.com/golang/go/blob/master/src/cmd/compile/internal/noder/noder.go#L80
in my opion, after the call of check2, the generic type and generic func 
has convert to instantiation type or func, so the after this func the 
compiler works similiar to no generic compiler. am i 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/e012731b-88ad-49df-8e5a-a682c7df8bd3n%40googlegroups.com.

Re: [go-nuts] pkg.go.dev Documentation section empty

[Tong Sun]

( Sorry Alex, didn't meant to sent to you personally )

Oh, thanks. Just realized that the Documentation section is only for
modules, right?

I.e., mine is an executable, and this is the first time I'm looking at
my docs on pkg.go.dev, in which my long readme is "missing", the whole
page is almost empty, with the gopher-flying-airplane picture taking
the majority of the empty space, until just now I realized that I
should click on that "Expand" button. Sorry...

On Thu, Mar 18, 2021 at 7:30 PM Axel Wagner
 wrote:
>
> Hi,
>
> https://go.dev/about#adding-a-package gives general information about adding 
> a module.
> One of the most common reasons why documentation might not show up is that 
> your module doesn't contain an open source license that pkg.go.dev 
> recognizes. https://pkg.go.dev/license-policy contains some information on 
> that.
> If you provide us with a link to your module, we might be able to give you 
> more specific information about what is wrong.
>
> On Fri, Mar 19, 2021 at 12:11 AM Tong Sun  wrote:
>>
>> The "Documentation" section is empty for my package on pkg.go.dev.
>>
>> Where can I read how to fix it?
>>
>> Thanks
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/88896681-cac3-4dac-bf4b-568b5cd8c5c4n%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/CAMmz1Ofxvhwy5fpSLmtSJ3dR3ncqy89sqTp6ueeQja9kLQ8a3w%40mail.gmail.com.

Re: [go-nuts] Some questions about the memory allocation strategy of channel

[Paul Zhang]

For this piece of code:

case elem.ptrdata == 0:
   // Elements do not contain pointers.
   // Allocate hchan and buf in one call.
   c = (*hchan)(mallocgc(hchanSize+mem, nil, true))
   c.buf = add(unsafe.Pointer(c), hchanSize)
default:
   // Elements contain pointers.
   c = new(hchan)
   c.buf = mallocgc(mem, elem, true)
}

Can I just understand that for the default case, when the compiler executes
the mallocgc() for c.buf, it would use reflect to build the descriptor for
the type of element? And if it allocates the both spaces in one function
call, it wouldn't build the descriptor for the gc, and gc would find the
descriptor later with more time, thus lead to worse performance? Thanks a
lot!

Ian Lance Taylor  于2021年3月19日周五 上午2:50写道：

> On Thu, Mar 18, 2021 at 9:55 AM Paul Zhang  wrote:
> >
> > I was reading the source code of makechan(), and these questions
> confused me. I would appreciate it if someone could help me.
> >
> > Q1. What does Elements do not contain pointers. mean? Does that means
> that the type of channel is not a pointer type (like chan int and chan
> *int)?
>
> It means that the element type of the channel is not a pointer and
> also does not contain any pointers.  For example "struct { a, b int }"
> does not contain any pointers, but "struct { a int; b []byte }" does
> contain pointers.
>
>
> > Q2. Why does the allocation strategy of memory allocation differ? It
> seems like the buf and the hchan should be allocated into one piece of
> continuous memory, if the "elements contains pointers", so what's the
> point? The logically continuous memory might not physically continuous.
>
> The garbage collector has to always know exactly where pointers are
> stored in memory.  We could in principle use contiguous allocation for
> the case where the element type contains pointers, but we would have
> to build a description that tells the garbage collector exactly where
> those pointers are.  Those descriptions are built by the compiler (on
> tip, the code is in cmd/compile/internal/reflectdata/reflect.go), so
> the compiler would have to build a new descriptor for every channel
> type with an element type that contains pointers.  And the descriptor
> would have to vary based on the channel size, so it would be based not
> just on the channel type but also on the argument passed to "make".
> Of course the argument passed to "make" can be a variable, so that
> adds another complication.
>
> So it's probably possible to use a contiguous buffer here, but it's
> not simple, and it's not the common case, and it's not clear that it
> would be worth 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/CANKef1sTdfZtxaoqeKZJSuOh5uRJxL90N0buuQuU-_YDdvCnxQ%40mail.gmail.com.

Re: [go-nuts] Re: build world question

[Hotei]

Jan,
To clarify a bit, "world" used to be everything under $GOPATH/src.   Since 
gophers can expect at some point to see $GOPATH go away the directory I now 
refer to as "world" is just a local/private version of my github.com/hotei 
repository with about 250 or so subdirs that represent individual 
projects.  I'm about halfway through the conversion process and it's pretty 
much down to a lot of typing now.  Go has gotten a bit more complex lately 
with vendoring and modules but in my opinion it's still the best choice for 
development. One particular strength I can vouch for is that I can look at 
go code I wrote 10 years ago and 99% of the time I understand what I was 
doing at the time.  Can't recall any other language I've used for which I 
can say the same.
David

On Thursday, March 18, 2021 at 12:02:12 PM UTC-4 Jan Mercl wrote:

> On Thu, Mar 18, 2021 at 4:51 PM Brian Candler  wrote:
>
> > OK. I'll just point out that if the repo contains a set of related 
> packages, then normally you'd only put a go.mod at the top level.
>
> I think the OP never mentioned a repository but "world". I infer that
> means all the repositories the OP is dealing with on some machine,
> probably everything under $GOPATH/src.
>

-- 
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/42912903-f717-42dd-9482-497e7828db9dn%40googlegroups.com.

Re: [go-nuts] pkg.go.dev Documentation section empty

['Axel Wagner' via golang-nuts]

Hi,

https://go.dev/about#adding-a-package gives general information about
adding a module.
One of the most common reasons why documentation might not show up is that
your module doesn't contain an open source license that pkg.go.dev
recognizes. https://pkg.go.dev/license-policy contains some information on
that.
If you provide us with a link to your module, we might be able to give you
more specific information about what is wrong.

On Fri, Mar 19, 2021 at 12:11 AM Tong Sun  wrote:

> The "Documentation" section is empty for my package on pkg.go.dev.
>
> Where can I read how to fix it?
>
> Thanks
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/88896681-cac3-4dac-bf4b-568b5cd8c5c4n%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/CAEkBMfGct0-Jq8LkYe_uOLOypQu0NLnEn9zF9ziyP70x0272fg%40mail.gmail.com.

[go-nuts] pkg.go.dev Documentation section empty

[Tong Sun]

The "Documentation" section is empty for my package on pkg.go.dev. 

Where can I read how to fix it?

Thanks


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/88896681-cac3-4dac-bf4b-568b5cd8c5c4n%40googlegroups.com.

Re: [go-nuts] Trying to use a tool in my build (a friction log)

['Jay Conrod' via golang-nuts]

Hey Tim, thanks for writing this up. These kinds of reports are helpful.
I'll try to respond to a few problems individually.

*1. Command installation with "go install"*

There are basically two ways to do this, depending on whether you want to
install the command within the context of your current module or "globally"
ignoring go.mod, go.sum, and vendor.

To install a command globally (you can replace @latest with a specific
version like @v1.2.3):

go install github.com/google/go-licenses@latest


This form (with the @version suffix) is new in Go 1.16
.

Installing a command within the context of the current module is more
complicated. I'd suggest this:

# Add a dependency on the tool (only need to do this once)
go get -d github.com/google/go-licenses

# Import the command from tools.go

# See below


# Sync vendor directory (only if vendoring; only after changing go.mod with
'go get' above)
go mod vendor

# Install the command
go install github.com/google/go-licenses

# Alternatively, build and write to some other directory
go build -o bin/go-licenses github.com/google/go-licenses


The problem with this workflow is that 'go mod tidy' removes the
requirement on the command's module because nothing imports it. 'go mod
vendor' won't vendor the package for the same reason. There is a workaround
documented on the Wiki : import
the command package from a file (usually named tools.go) that is excluded
by a build constraint (usually "tools").

// +build tools

package tools

import _ "github.com/google/go-licenses"


This works, but personally, I don't find this to be an intuitive solution.
At the moment, we don't have a concrete proposal to improve it though.
There's some discussion at #25922
.

*2. "writing go.mod cache" error messages*

This error message should be a lot better. Sorry about that.

Most module-aware commands need to download files into the module cache.
The location of the cache can be set by setting the GOMODCACHE environment
variable (or 'go env -w GOMODCACHE=/some/path'). That defaults to
$GOPATH/pkg/mod, and GOPATH defaults to $HOME/go. So by default, the module
cache is at $HOME/go/pkg/mod. It can't create that directory though.

The error message should explain what went wrong and how to fix it, and it
really shouldn't be repeated. I've opened #45113
 for this.

*3. 'go get' updating go.mod and go.sum*

This is an unfortunate consequence of 'go get' being overloaded for
downloading, installing, and managing package versions. Ideally, we want to
separate these roles into different commands: 'go get' should be used to
manage dependencies (changing requirements in go.mod and go.sum), and 'go
install' should be used to install commands.

We've taken a couple steps toward this in 1.16. The 'go install cmd@version'
form is new. Also, 'go install', 'go build', and other commands no longer
change go.mod or go.sum automatically when something is missing.

We plan to deprecate 'go get' for installing commands. In Go 1.17, 'go get'
will print a warning when the -d flag is not used and the arguments are
main packages. In Go 1.18, we plan to remove that functionality entirely
(the -d flag will always be on). #40276
 is where that deprecation was
proposed.

On Thu, Mar 18, 2021 at 3:36 PM 'Tim Hockin' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> First: go version go1.16 linux/amd64
>
> In one of my side-projects, I build a container image.  It turns out
> to be useful to people, but I got a request to put the license files
> for all code used in the binary into the container.  Lawyers, what can
> you do?
>
> So these people sent me a PR to gather the licenses with `go install
> github.com/google/go-licenses`  in
> the `make container` rule.  Here's
> the friction.
>
> 1) Their PR includes dozens of new lines in go.sum, which makes me
> grumpy.  I set out to see if I can do better.
>
> 2) When I run that command on my workstation I get:
>
> ```
> $ go install github.com/google/go-licenses
> cannot find package "." in:
> /home/thockin/src/go/src/
> k8s.io/git-sync/vendor/github.com/google/go-licenses
> ```
>
> I don't know what to make of that message.  It's not in vendor/ yet -
> I want to put it there (I think?).
>
> So I am left wondering - what is the normal flow for "I want to use
> this Go tool in my build" ?
>
> I tried `-mod=mod`:
>
> ```
> $ (unset GOPATH; go install -mod=mod github.com/google/go-licenses)
> go: writing go.mod cache: mkdir /home/thockin/go: not a directory
> go: writing go.mod cache: mkdir /home/thockin/go: not a directory
> go: writing go.mod cache: mkdir /home/thockin/go: not a directory
> go: writing go.mod cache: mkdir /home/thockin/go: not a directory
> go: writing go.mod cache: mkdir /home/thockin/go: not a direct

[go-nuts] Re: No generic, part -2

[wilk]

On 18-03-2021, Tyler Compton wrote:

> I think we all want to stick our noses in this thread. I'm going to stick
> my nose in it too :)
>
> Space, I don't think you'll ever be happy as a result of this discussion,
> no matter what evidence or arguments others provide you. I think the fact
> is that you were burned by the outcome of the generics proposal. You didn't
> have the time to review the draft proposal and engage with the discussion
> early, and you disagree with the resulting outcome. That's unfortunate and
> I'm sorry it happened. I hope you don't feel that people are trying to
> convince you that you weren't burned. Nothing feels worse than having your
> concerns trivialized.
>
> However, you have to understand that just because you were burned doesn't
> mean that those around you making these decisions are bad actors. There are
> probably small ways that this process could have been improved, but I don't
> think they would have changed the outcome. The reality is that after many
> iterations, the Go team created a proposal that a large enough number of Go
> users found beneficial for it to be accepted. I know you disagree with
> them, but our responsibility as members of this community is to
> exercise our right to disagree without resorting to attacks on character. I
> hope I've been able to address your concerns and disagree with you without
> making you feel I'm attacking your character.
>
> To those who are still attempting to provide evidence that the generics
> proposal process was conducted in good faith, I think you've done
> everything you need to do and it's probably best to just let this one go.

+1 

-- 
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/s30g04%24ie7%241%40ciao.gmane.io.

Re: [go-nuts] Help with contributing to the Golang

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 9:55 AM Kirill Prokopovich  wrote:
>
> Hello everyone!
> Can somebody help with some advice about starting contributing in Golang?
>
> I've already read https://golang.org/doc/contribute.html and tried to find 
> some issues from https://github.com/golang/go/labels/help%20wanted , but it's 
> not so obvious how to choose a free issue but I'm not sure about its status 
> (busy or not)

Most issues are not busy, and especially most "help wanted" issues are
not busy.  It is always OK to ask on an issue whether you can try
fixing it.  We only ask that if you do so, and you decide that you
aren't going to be able to fix it, that you say that too.

Thanks for your interest in Go!

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/CAOyqgcVpyv1Hbi7di2AvpNs2q-mGGR3Tw%3DATaQNNkPYNZuRt4g%40mail.gmail.com.

Re: [go-nuts] go build error in darwin: duplicate symbol

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 9:55 AM Max Xu  wrote:
>
> I'm running into a weird bug:
>
> Failed with command:
> GOOS=darwin go build
>
> Bug success with:
> GOOS=linux go build
>
> The failed Message:
>
> /usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: 
> exit status 1
> duplicate symbol '_readdrivestat' in:
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/11.o
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/36.o
> duplicate symbol '_get_temperature' in:
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> duplicate symbol '_open_smc' in:
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> duplicate symbol '_close_smc' in:
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> ld: 4 duplicate symbols for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)

Hard to say without seeing the code, but my first guess would be
erroneous cgo code.  It looks like you have multiple cases of cgo code
that are defining the same symbol in the C preamble without declaring
it as `static`.

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/CAOyqgcUnSr3hsjP-FvrFZ%2BFjzpjxrnc66uCLpK6T3SK-Ag05%2BQ%40mail.gmail.com.

[go-nuts] Re: %v for []string{} and []string{""}

['Kevin Chowski' via golang-nuts]

The "%#v" print verb is intended to be used for unambiguous printing of a 
type, but that means it will have a prefix of `[]string` in order to ensure 
the type is unambiguous. I personally use %q a lot any time I know I have a 
string (or set of strings) which might be ambiguous in some way, but I 
don't want the `[]string` prefix in there. 
See: https://play.golang.org/p/70Ryd50IGt6

On Thursday, March 18, 2021 at 4:31:32 AM UTC-6 Brian Candler wrote:

> Sure.  I don't have a problem with nil slice and empty slice showing the 
> same, because in all important ways they behave the same - i.e. they have 
> len() of 0, you can append() to them, etc.  The only behavioural difference 
> I can think of is if you explicitly test "foo == nil".
>
> However, a slice with len=1 that showed the same as one with len=0, was 
> what confused me :-)
>
> On reflection, %v is intentionally ambiguous.  There are other examples, 
> e.g.
> - []string{"a","b"} and []string{"a b"}
> - []string{"", ""} and []string{" "}
>
> On Wednesday, 17 March 2021 at 21:24:46 UTC tapi...@gmail.com wrote:
>
>> Printing a nil slice also get the same output [].
>>
>> I remembered Rob Pike ever said in an issue thread that this can't be 
>> changed now for compatibility reason.
>>
>> On Monday, March 15, 2021 at 8:18:46 AM UTC-4 Brian Candler wrote:
>>
>>> I was slightly surprised to discover that the Print() output for an 
>>> empty slice, and a 1-element slice containing the empty string, are the 
>>> same:
>>>
>>> https://play.golang.org/p/btkzgk4LMT9
>>>
>>> It does follow logically from the rules 
>>> .  I guess I need to train 
>>> myself to use %q or %#v.
>>>
>>

-- 
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/9e87e9bc-fbd9-4729-8721-689a62db8130n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Tyler Compton]

I think we all want to stick our noses in this thread. I'm going to stick
my nose in it too :)

Space, I don't think you'll ever be happy as a result of this discussion,
no matter what evidence or arguments others provide you. I think the fact
is that you were burned by the outcome of the generics proposal. You didn't
have the time to review the draft proposal and engage with the discussion
early, and you disagree with the resulting outcome. That's unfortunate and
I'm sorry it happened. I hope you don't feel that people are trying to
convince you that you weren't burned. Nothing feels worse than having your
concerns trivialized.

However, you have to understand that just because you were burned doesn't
mean that those around you making these decisions are bad actors. There are
probably small ways that this process could have been improved, but I don't
think they would have changed the outcome. The reality is that after many
iterations, the Go team created a proposal that a large enough number of Go
users found beneficial for it to be accepted. I know you disagree with
them, but our responsibility as members of this community is to
exercise our right to disagree without resorting to attacks on character. I
hope I've been able to address your concerns and disagree with you without
making you feel I'm attacking your character.

To those who are still attempting to provide evidence that the generics
proposal process was conducted in good faith, I think you've done
everything you need to do and it's probably best to just let this one go.

On Thu, Mar 18, 2021 at 7:08 AM Space A.  wrote:

> Since pro-generics ppl here are struggling to provide any evidence of
> existence of open and public discussion on the topic of dropping generics,
> I will do it myself.
>
> Here is it:
> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>
>
>
> --
> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAA%3DXfu3GpLa38KPKt_M_Sk5PBDq0MAuK8MbZqkddfuYTr4E7Bg%40mail.gmail.com.

[go-nuts] Trying to use a tool in my build (a friction log)

['Tim Hockin' via golang-nuts]

First: go version go1.16 linux/amd64

In one of my side-projects, I build a container image.  It turns out
to be useful to people, but I got a request to put the license files
for all code used in the binary into the container.  Lawyers, what can
you do?

So these people sent me a PR to gather the licenses with `go install
github.com/google/go-licenses` in the `make container` rule.  Here's
the friction.

1) Their PR includes dozens of new lines in go.sum, which makes me
grumpy.  I set out to see if I can do better.

2) When I run that command on my workstation I get:

```
$ go install github.com/google/go-licenses
cannot find package "." in:
/home/thockin/src/go/src/k8s.io/git-sync/vendor/github.com/google/go-licenses
```

I don't know what to make of that message.  It's not in vendor/ yet -
I want to put it there (I think?).

So I am left wondering - what is the normal flow for "I want to use
this Go tool in my build" ?

I tried `-mod=mod`:

```
$ (unset GOPATH; go install -mod=mod github.com/google/go-licenses)
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: finding module for package github.com/google/go-licenses
go: downloading github.com/google/go-licenses v0.0.0-20201026145851-73411c8fa237
mkdir /home/thockin/go: not a directory
```

I keep hearing that GOPATH is dead (and frankly good riddance) but
this tries to write to GOPATH or ~/go (which is also annoying).  I
don't want this project's build spilling over into my homedir.

I tried `go get` but it's the same.

```
$ (unset GOPATH; go get github.com/google/go-licenses)
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: writing go.mod cache: mkdir /home/thockin/go: not a directory
go: downloading github.com/google/go-licenses v0.0.0-20201026145851-73411c8fa237
go get github.com/google/go-licenses: mkdir /home/thockin/go: not a directory
```

What do I *want*?   I want to download a tool repo, build it, drop the
binary into ./bin/tools (or something) and then either vendor it or
have no artifacts.

Since GOPATH seems to be a requirement, I thought maybe I can fake it:

```
$ (export GOPATH="`pwd`/.gopath"; export GOBIN=`pwd`/bin/tools; mkdir
-p "$GOBIN"; go get github.com/google/go-licenses)
go: downloading github.com/google/go-licenses v0.0.0-20201026145851-73411c8fa237
go: downloading github.com/otiai10/copy v1.2.0
go: downloading github.com/spf13/cobra v0.0.5
go: downloading github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
go: downloading github.com/google/licenseclassifier
v0.0.0-20190926221455-842c0d70d702
go: downloading golang.org/x/tools v0.0.0-20191118222007-07fc4c7f2b98
go: downloading gopkg.in/src-d/go-git.v4 v4.13.1
go: downloading github.com/spf13/pflag v1.0.5
go: downloading github.com/inconshreveable/mousetrap v1.0.0
go: downloading github.com/sergi/go-diff v1.0.0
go: downloading gopkg.in/src-d/go-billy.v4 v4.3.2
go: downloading golang.org/x/crypto v0.0.0-20191117063200-497ca9f6d64f
go: downloading golang.org/x/sys v0.0.0-20191119060738-e882bf8e40c2
go: downloading github.com/emirpasic/gods v1.12.0
go: downloading github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99
go: downloading github.com/src-d/gcfg v1.4.0
go: downloading github.com/kevinburke/ssh_config
v0.0.0-20190725054713-01f96b0aa0cd
go: downloading github.com/mitchellh/go-homedir v1.1.0
go: downloading github.com/xanzy/ssh-agent v0.2.1
go: downloading golang.org/x/net v0.0.0-20191119073136-fc4aabc6c914
go: downloading gopkg.in/warnings.v0 v0.1.2
go get: added github.com/google/go-licenses v0.0.0-20201026145851-73411c8fa237
```

This does actually build my

Re: [go-nuts] No generic, part -2

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 5:11 AM Space A.  wrote:
>
> > What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  Thanks.
>
> Ian, seriously. ANY evidence please, which you think "proves" that there was 
> an open and public discussion on dropping generics from your daily agenda and 
> focusing and spending time on more important things, such as first class 
> Android support.

ANY evidence for a discussion about dropping generics?

https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo
https://groups.google.com/g/golang-nuts/c/bj6kMQBTqUY
https://groups.google.com/g/golang-nuts/c/uMBEmlejhzk/m/Uu1kYoDPBgAJ

Does that satisfy your request?

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/CAOyqgcXHes%3DF5vvVPQUtSZS7N94MW6KSjG8YuHTgDC1jj_cvXw%40mail.gmail.com.

Re: [go-nuts] Some questions about the memory allocation strategy of channel

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 9:55 AM Paul Zhang  wrote:
>
> I was reading the source code of makechan(), and these questions confused me. 
> I would appreciate it if someone could help me.
>
> Q1. What does Elements do not contain pointers. mean? Does that means that 
> the type of channel is not a pointer type (like chan int and chan *int)?

It means that the element type of the channel is not a pointer and
also does not contain any pointers.  For example "struct { a, b int }"
does not contain any pointers, but "struct { a int; b []byte }" does
contain pointers.


> Q2. Why does the allocation strategy of memory allocation differ? It seems 
> like the buf and the hchan should be allocated into one piece of continuous 
> memory, if the "elements contains pointers", so what's the point? The 
> logically continuous memory might not physically continuous.

The garbage collector has to always know exactly where pointers are
stored in memory.  We could in principle use contiguous allocation for
the case where the element type contains pointers, but we would have
to build a description that tells the garbage collector exactly where
those pointers are.  Those descriptions are built by the compiler (on
tip, the code is in cmd/compile/internal/reflectdata/reflect.go), so
the compiler would have to build a new descriptor for every channel
type with an element type that contains pointers.  And the descriptor
would have to vary based on the channel size, so it would be based not
just on the channel type but also on the argument passed to "make".
Of course the argument passed to "make" can be a variable, so that
adds another complication.

So it's probably possible to use a contiguous buffer here, but it's
not simple, and it's not the common case, and it's not clear that it
would be worth 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/CAOyqgcWPiMNVwOC2VXctcuVvanSACcatb5TV72B3G0VzeVNioA%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 11:37 AM Space A.  wrote:

 [ omitted ]

This message does not follow the Go Community Code of Conduct
(https://golang.org/conduct).  On this mailing list we ask everybody
to follow those guidelines.  Please respect that.  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/CAOyqgcUce7urTCXHr14iohX-ff%3DY7dV_AOQkrNKwtbehZVeUMw%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Space A.]

Sorry but if you don't want to be targeted, resign from your manager's
position. Less responsibility, less spotlight, and still good compensation
package from Google.

чт, 18 мар. 2021 г. в 20:45, Andrew Bonventre :

> This conversation has not been adhering to Go’s values
>  of being respectful and charitable with each
> other. I’d like to request it come to an end.
>
> Additionally, please do not make assumptions about specific members of the
> community and their role in things. I was “in charge” of the Go websites
> when this banner was launched and I stand by any decision those on the core
> team make on this. Targeting Russ is inappropriate and unfounded.
>
> Thanks,
> Andy
> On Thursday, March 18, 2021 at 1:11:09 PM UTC-4 Thomas Bushnell, BSG wrote:
>
>> On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:
>>
>>> Are you absolutely SURE you want to keep up the "your not welcome here"
>>> sign to people who literally find the message to be dangerous to the very
>>> people they claim to want to protect. Do we really want to encourage an
>>> opensource culture, where people will literally fork a language just
>>> because they don't like the political grandstanding going on because the
>>> people who are supposed to be the smartest people in the world are stupid
>>> enough to abandon liberal principles for wokeism?
>>>
>>
>> I cannot speak for the Go authors, and I certainly cannot speak for
>> Google, but I can say for my part that I want a very clear and very bright
>> sign that racists are not welcome here, no matter how brilliantly they can
>> write computer programs.
>>
>> Thomas
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/DHO4ZZkR8JA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/31872752-2c7e-4a1d-b175-7cc749c393b8n%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/CADKwOTcmXiVFjP_zRRfY-nTTsisr2KN7MsObZpJ5jJ67LgJCjA%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Space A.]

> that racists are not welcome here
You probably mean white racists?
But black are welcomed.

I also very like this cite:

“It should be noted that no ethically -trained software engineer would ever
consent to write a DestroyBaghdad procedure. Basic professional ethics
would instead require him to write a DestroyCity procedure, to which
Baghdad could be given as a parameter.”

― Nathaniel S. Borenstein



чт, 18 мар. 2021 г. в 20:11, 'Thomas Bushnell BSG' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:
>
>> Are you absolutely SURE you want to keep up the "your not welcome here"
>> sign to people who literally find the message to be dangerous to the very
>> people they claim to want to protect. Do we really want to encourage an
>> opensource culture, where people will literally fork a language just
>> because they don't like the political grandstanding going on because the
>> people who are supposed to be the smartest people in the world are stupid
>> enough to abandon liberal principles for wokeism?
>>
>
> I cannot speak for the Go authors, and I certainly cannot speak for
> Google, but I can say for my part that I want a very clear and very bright
> sign that racists are not welcome here, no matter how brilliantly they can
> write computer programs.
>
> Thomas
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/DHO4ZZkR8JA/unsubscribe.
> To unsubscribe from this group and all its topics, 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%2BYjuxskL_ypkm7rthr1374dXBOFQDoG3Y2e3pdivz748sK2iw%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/CADKwOTerPRMDJ7wV7-HUM5Z%3D7c8%2B86ywX4NvFcrxjYd2ZhyoJw%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Robert Engels]

I will point out again - there is a big difference between reading/writing 
generic “usage” code, and generic “implementation” code. The vast majority of 
developers will only need to do the former - and modern IDEs make this somewhat 
trivial. 

> On Mar 18, 2021, at 12:57 PM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
>> On Thu, Mar 18, 2021 at 5:59 PM Kent Sandvik  wrote:
> 
>> So if I understand this correctly, you don't want to learn a new syntax in 
>> the language?
> 
> That is not what I tried to say :) I'm leaning towards being in favor of 
> adding generics.
> I was trying to say that I think it's unavoidable that Go programmers will 
> have to learn to read and use generic code.
> I think it's very reasonable to acknowledge and consider the downsides of a 
> change, while still being in favor of making it. That's kind of my point 
> during this entire thread - that "we decided to add generics" doesn't mean we 
> didn't hear or consider or even agree with the arguments against them. We 
> just feel that the benefits outweigh them.
>  
>> 
>>> On Thu, Mar 18, 2021 at 9:37 AM 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>> I also think there is definitely credence to the idea that we read more 
>>> code than we write (after all, a lot of Go's design is based on that idea 
>>> too). So I definitely agree that most Go programmers will find it hard to 
>>> avoid generics, even if they want. Usage of the language is very likely to 
>>> change and generics are very likely to be used in a lot of Go code.
>>> 
>>> So, if we didn't think generics would make the language better, we 
>>> shouldn't (and wouldn't) add them.
>>> 
 On Thu, Mar 18, 2021 at 5:30 PM Robert Engels  
 wrote:
 I think the most plausible events are that various collections apis make 
 it into the api as a “replacement” for the non type safe interface based 
 ones. 
 
>> On Mar 18, 2021, at 11:20 AM, Kent Sandvik  wrote:
>> 
> 
> I'm very dumb, but if you don't want to use generics or think they are 
> bad for the language, why can't you just ignore them and not use them?
> 
>> On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:
>> Since pro-generics ppl here are struggling to provide any evidence of 
>> existence of open and public discussion on the topic of dropping 
>> generics, I will do it myself.
>> 
>> Here is it: 
>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>> 
>> 
>> 
>> -- 
>> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%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/0868C2C5-A4D5-4D38-B0B6-D1E955EAF7A4%40ix.netcom.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/CAEkBMfHXZpBQSzYuck7h8b79q0D5eRYVpAgitoWuPNacJOT%3Dig%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/CAEkBMfE8pz7m7oKuytYCs2NXks9W7rQhwSNXH3HEtyzYepiU9A%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/934C705A-D3FE-48E2-8C25-091559D199B1%40ix.netcom.com.

Re: [go-nuts] No generic, part -2

['Axel Wagner' via golang-nuts]

On Thu, Mar 18, 2021 at 5:59 PM Kent Sandvik  wrote:

> So if I understand this correctly, you don't want to learn a new syntax in
> the language?
>

That is not what I tried to say :) I'm leaning towards being in favor of
adding generics.
I was trying to say that I think it's unavoidable that Go programmers will
have to learn to read and use generic code.
I think it's very reasonable to acknowledge and consider the downsides of a
change, while still being in favor of making it. That's kind of my point
during this entire thread - that "we decided to add generics" doesn't mean
we didn't hear or consider or even agree with the arguments against them.
We just feel that the benefits outweigh them.


>
> On Thu, Mar 18, 2021 at 9:37 AM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I also think there is definitely credence to the idea that we read more
>> code than we write (after all, a lot of Go's design is based on that idea
>> too). So I definitely agree that most Go programmers will find it hard to
>> avoid generics, even if they want. Usage of the language is very likely to
>> change and generics are very likely to be used in a lot of Go code.
>>
>> So, if we didn't think generics would make the language better, we
>> shouldn't (and wouldn't) add them.
>>
>> On Thu, Mar 18, 2021 at 5:30 PM Robert Engels 
>> wrote:
>>
>>> I think the most plausible events are that various collections apis make
>>> it into the api as a “replacement” for the non type safe interface based
>>> ones.
>>>
>>> On Mar 18, 2021, at 11:20 AM, Kent Sandvik  wrote:
>>>
>>> 
>>> I'm very dumb, but if you don't want to use generics or think they are
>>> bad for the language, why can't you just ignore them and not use them?
>>>
>>> On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:
>>>
 Since pro-generics ppl here are struggling to provide any evidence of
 existence of open and public discussion on the topic of dropping generics,
 I will do it myself.

 Here is it:
 https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ



 --
 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%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/0868C2C5-A4D5-4D38-B0B6-D1E955EAF7A4%40ix.netcom.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/CAEkBMfHXZpBQSzYuck7h8b79q0D5eRYVpAgitoWuPNacJOT%3Dig%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/CAEkBMfE8pz7m7oKuytYCs2NXks9W7rQhwSNXH3HEtyzYepiU9A%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Andrew Bonventre]

This conversation has not been adhering to Go’s values 
 of being respectful and charitable with each 
other. I’d like to request it come to an end.

Additionally, please do not make assumptions about specific members of the 
community and their role in things. I was “in charge” of the Go websites 
when this banner was launched and I stand by any decision those on the core 
team make on this. Targeting Russ is inappropriate and unfounded.

Thanks,
Andy
On Thursday, March 18, 2021 at 1:11:09 PM UTC-4 Thomas Bushnell, BSG wrote:

> On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:
>
>> Are you absolutely SURE you want to keep up the "your not welcome here" 
>> sign to people who literally find the message to be dangerous to the very 
>> people they claim to want to protect. Do we really want to encourage an 
>> opensource culture, where people will literally fork a language just 
>> because they don't like the political grandstanding going on because the 
>> people who are supposed to be the smartest people in the world are stupid 
>> enough to abandon liberal principles for wokeism? 
>>
>
> I cannot speak for the Go authors, and I certainly cannot speak for 
> Google, but I can say for my part that I want a very clear and very bright 
> sign that racists are not welcome here, no matter how brilliantly they can 
> write computer programs.
>
> 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/31872752-2c7e-4a1d-b175-7cc749c393b8n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[David Skinner]

I am very much pro generics, having used them with Go for many years.

I have only found them to be occasionally useful (10%), but on those
occasions, it saves me time, improves reliability, and enhances the ability
to maintain the code.

Having a background in MASM, TASM, Forth, Lisp, C++ leaves me comfortable
with generics. Having one Java project where I was reading newbie use of
generics was a traumatic experience that still gives me nightmares. So I
totally respect those opposed to the generics.

New programmers do not need to learn about reflection, or generics, or
goroutines to create modest programs that do extraordinary things. But as
they advance by reading legacy code, and learning examples, these are
things that they need to add to their toolbox. It does not matter to me if
generics are added to the language or not as I have generics, but anyone
reading my code must learn my version of generics implemented with
+generate. So having a standardized version is great. And if it is not part
of the language, you will still have to learn it and read and use it. I see
no point at this time to not having a standard generics and have it fully
implemented into the compiler, there is no significant long-term
downside, only an improvement in productivity.

Some members of the Go team have used my version of generics and felt that
it could be much better, and I agree. This change is not based on a whim,
it is based on decades of experience and a decade of preparation.

On Thu, Mar 18, 2021 at 11:20 AM Kent Sandvik  wrote:

> I'm very dumb, but if you don't want to use generics or think they are bad
> for the language, why can't you just ignore them and not use them?
>
> On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:
>
>> Since pro-generics ppl here are struggling to provide any evidence of
>> existence of open and public discussion on the topic of dropping generics,
>> I will do it myself.
>>
>> Here is it:
>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>>
>>
>>
>> --
>> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/lC9Z9VZXPdM/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%40mail.gmail.com
> 
> .
>


-- 

Respectfully submitted,
David Lynn Skinner
Secretary, Davsk Ltd Co

 


 


IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
[image: App Green Footer Image] Be like me, be Carbon free - don't print
this and save a tree

"Look deep into nature, and then you will understand everything better." -
Albert Einstein.
   [image: App Video Meeting Image]
 Meet me on Zoom
   
Check out my blog [image: arrow] 

-- 
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/CAGe8nGFCMxVVYDFsZ1%2BS26T0UX_%2BMs1SovAdC55xQ1y5eLjy9A%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:

> Are you absolutely SURE you want to keep up the "your not welcome here"
> sign to people who literally find the message to be dangerous to the very
> people they claim to want to protect. Do we really want to encourage an
> opensource culture, where people will literally fork a language just
> because they don't like the political grandstanding going on because the
> people who are supposed to be the smartest people in the world are stupid
> enough to abandon liberal principles for wokeism?
>

I cannot speak for the Go authors, and I certainly cannot speak for Google,
but I can say for my part that I want a very clear and very bright sign
that racists are not welcome here, no matter how brilliantly they can write
computer programs.

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%2BYjuxskL_ypkm7rthr1374dXBOFQDoG3Y2e3pdivz748sK2iw%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 17, 2021 at 8:22 AM mortdeus  wrote:

> Why do black lives matter more than Syrian lives?


Nobody said they do. The banner does not make any comparisons.

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%2BYjuxv69ce9_wvX_1ZHqSU7dijYw1sbNNQnhyhfg%2BzCEs6oNw%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 17, 2021 at 8:22 AM mortdeus  wrote:

> The problem is that this inspires a political discussion that obviously
> should happen with your city council or your therapist. Not with gophers.
>

If you don't believe the political discussion should happen, then I would
recommend you resist the impulse to keep starting one.

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%2BYjuxs-Zqamgx3E_py4LFwEktO%3D%2B-GyRiz_HR33T89cpv1emQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Kent Sandvik]

So if I understand this correctly, you don't want to learn a new syntax in
the language?

On Thu, Mar 18, 2021 at 9:37 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I also think there is definitely credence to the idea that we read more
> code than we write (after all, a lot of Go's design is based on that idea
> too). So I definitely agree that most Go programmers will find it hard to
> avoid generics, even if they want. Usage of the language is very likely to
> change and generics are very likely to be used in a lot of Go code.
>
> So, if we didn't think generics would make the language better, we
> shouldn't (and wouldn't) add them.
>
> On Thu, Mar 18, 2021 at 5:30 PM Robert Engels 
> wrote:
>
>> I think the most plausible events are that various collections apis make
>> it into the api as a “replacement” for the non type safe interface based
>> ones.
>>
>> On Mar 18, 2021, at 11:20 AM, Kent Sandvik  wrote:
>>
>> 
>> I'm very dumb, but if you don't want to use generics or think they are
>> bad for the language, why can't you just ignore them and not use them?
>>
>> On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:
>>
>>> Since pro-generics ppl here are struggling to provide any evidence of
>>> existence of open and public discussion on the topic of dropping generics,
>>> I will do it myself.
>>>
>>> Here is it:
>>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>>>
>>>
>>>
>>> --
>>> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%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/0868C2C5-A4D5-4D38-B0B6-D1E955EAF7A4%40ix.netcom.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/CAEkBMfHXZpBQSzYuck7h8b79q0D5eRYVpAgitoWuPNacJOT%3Dig%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/CAHC_roFk_3Q0sWLrzZRgHZ_VhF1J0HFbsY_B5_q7uX9HDn5Gdg%40mail.gmail.com.

[go-nuts] Sending 100 Continue with unknown Content-Length

[Marks Polakovs]

Hi all,

I'm writing a server that can receive streaming audio (using the Icecast 
protocol) over HTTP. The gist of the protocol is:

   1. Client sends a PUT with, among others, a "Expect: 100-continue"
   2. Server validates the request and replies with "HTTP/1.1 100 Continue"
   3. Client streams data

The issue I'm running into is that net/http server replies with a 200 OK 
instead of a 100 Continue unless either the Content-Length is nonzero or 
Transfer-Encoding is Chunked - the former makes no sense for a 
(theoretically) infinite stream, while none of the clients I've tested 
(broadcast-using-this-tool and ffmpeg) do the latter.

I noted that net/http/server.go checks req.ContentLength != 0 before 
setting canWriteContinue - would it be worthwhile either removing this 
check, or setting req.ContentLength to -1 if Expect: 100-continue is set 
for a POST or PUT? This would better mirror real-world behaviour.

thanks,
Marks

-- 
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/2d15ff5a-fc9f-4936-bb6c-419feaef2c5fn%40googlegroups.com.

[go-nuts] Help with contributing to the Golang

[Kirill Prokopovich]

Hello everyone!
Can somebody help with some advice about starting contributing in Golang?

I've already read https://golang.org/doc/contribute.html and tried to find 
some issues from https://github.com/golang/go/labels/help%20wanted , but 
it's not so obvious how to choose a free issue but I'm not sure about its 
status (busy or not)

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/01daecb8-be6d-4f02-9326-9472518e88e4n%40googlegroups.com.

[go-nuts] Some questions about the memory allocation strategy of channel

[Paul Zhang]

I was reading the source code of makechan(), and these questions confused 
me. I would appreciate it if someone could help me.

Q1. What does Elements do not contain pointers. mean? Does that means that 
the type of channel is not a pointer type (like chan int and chan *int)?

Q2. Why does the allocation strategy of memory allocation differ? It seems 
like the buf and the hchan should be allocated into one piece of continuous 
memory, if the "elements contains pointers", so what's the point? The 
logically continuous memory might not physically continuous.

-- 
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/8d01bae6-9cb3-47aa-9b17-631bba1a975fn%40googlegroups.com.

[go-nuts] go build error in darwin: duplicate symbol

[Max Xu]

Hi all,

I'm running into a weird bug:

Failed with command:
GOOS=darwin go build

Bug success with:
GOOS=linux go build

The failed Message:

/usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: 
exit status 1
duplicate symbol '_readdrivestat' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/11.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/36.o
duplicate symbol '_get_temperature' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
duplicate symbol '_open_smc' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
duplicate symbol '_close_smc' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
ld: 4 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


My Environment:

go version go1.16.2 darwin/amd64

-- 
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/3979f9aa-1f9e-43b4-b128-b06cf69bb9b5n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

['Axel Wagner' via golang-nuts]

I also think there is definitely credence to the idea that we read more
code than we write (after all, a lot of Go's design is based on that idea
too). So I definitely agree that most Go programmers will find it hard to
avoid generics, even if they want. Usage of the language is very likely to
change and generics are very likely to be used in a lot of Go code.

So, if we didn't think generics would make the language better, we
shouldn't (and wouldn't) add them.

On Thu, Mar 18, 2021 at 5:30 PM Robert Engels  wrote:

> I think the most plausible events are that various collections apis make
> it into the api as a “replacement” for the non type safe interface based
> ones.
>
> On Mar 18, 2021, at 11:20 AM, Kent Sandvik  wrote:
>
> 
> I'm very dumb, but if you don't want to use generics or think they are bad
> for the language, why can't you just ignore them and not use them?
>
> On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:
>
>> Since pro-generics ppl here are struggling to provide any evidence of
>> existence of open and public discussion on the topic of dropping generics,
>> I will do it myself.
>>
>> Here is it:
>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>>
>>
>>
>> --
>> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%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/0868C2C5-A4D5-4D38-B0B6-D1E955EAF7A4%40ix.netcom.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/CAEkBMfHXZpBQSzYuck7h8b79q0D5eRYVpAgitoWuPNacJOT%3Dig%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Robert Engels]

I think the most plausible events are that various collections apis make it 
into the api as a “replacement” for the non type safe interface based ones. 

> On Mar 18, 2021, at 11:20 AM, Kent Sandvik  wrote:
> 
> 
> I'm very dumb, but if you don't want to use generics or think they are bad 
> for the language, why can't you just ignore them and not use them?
> 
>> On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:
>> Since pro-generics ppl here are struggling to provide any evidence of 
>> existence of open and public discussion on the topic of dropping generics, I 
>> will do it myself.
>> 
>> Here is it: 
>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>> 
>> 
>> 
>> -- 
>> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%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/0868C2C5-A4D5-4D38-B0B6-D1E955EAF7A4%40ix.netcom.com.

Re: [go-nuts] No generic, part -2

[Kent Sandvik]

I'm very dumb, but if you don't want to use generics or think they are bad
for the language, why can't you just ignore them and not use them?

On Thu, Mar 18, 2021 at 7:07 AM Space A.  wrote:

> Since pro-generics ppl here are struggling to provide any evidence of
> existence of open and public discussion on the topic of dropping generics,
> I will do it myself.
>
> Here is it:
> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>
>
>
> --
> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%40mail.gmail.com.

Re: [go-nuts] Re: build world question

[Jan Mercl]

On Thu, Mar 18, 2021 at 4:51 PM Brian Candler  wrote:

> OK.  I'll just point out that if the repo contains a set of related packages, 
> then normally you'd only put a go.mod at the top level.

I think the OP never mentioned a repository but "world". I infer that
means all the repositories the OP is dealing with on some machine,
probably everything under $GOPATH/src.

-- 
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/CAA40n-WwUowL_R7Hb8M%2BG%3DfJeMA1nKhv8LefeG0cFEj0jMGoWg%40mail.gmail.com.

[go-nuts] Re: build world question

[Brian Candler]

OK.  I'll just point out that if the repo contains a set of related 
packages, then normally you'd only put a go.mod at the top level.

For an example of this in action, see the "testify" group of packages:
https://github.com/stretchr/testify/

The subdirectories are separate packages.  For example I can do

import (
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
...
assert.NotEqual(t, 1, 2)
require.True(t, true)

However, you'll see there's no go.mod in the package directories.  They are 
anchored to the go.mod at the root.

-- 
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/dcbab28e-e335-4cac-bd7d-8702efd4ab27n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Space A.]

Since pro-generics ppl here are struggling to provide any evidence of 
existence of open and public discussion on the topic of dropping generics, 
I will do it myself.

Here is it: 
https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ



-- 
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/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Space A.]

The same as you just did, completely ignored everything I said in this
thread.

чт, 18 мар. 2021 г. в 16:25, Axel Wagner :

> I find your response disrespectful. You are completely ignoring (in the
> sense of "refusing to take notice of") what I wrote.
> I don't think it is possible to have a productive conversation as long as
> you behave this way.
>
> On Thu, Mar 18, 2021 at 1:48 PM Space A.  wrote:
>
>> That's exactly what I'm saying, topic of dropping generics was never
>> raised, so landing of some version of generics was implied by the process.
>> In fact just a start of that process implied that dropping them entirely
>> was never a question. There was no public discussion with that regard, no
>> poll or anything.
>>
>>
>>
>> четверг, 18 марта 2021 г. в 15:42:44 UTC+3, axel.wa...@googlemail.com:
>>
>>> ISTM that we already provided a bunch of evidence, which you are
>>> rejecting. so "any evidence" clearly is not good enough and you should be a
>>> bit more specific.
>>>
>>> Just to name a few specific examples of evidence provided:
>>> • The FAQ, as well as any interview of the question, have stated clearly
>>> that generics *may* be added, if a satisfying design is found. "May", not
>>> "will".
>>> • The proposal process
>>>  clearly
>>> mentions the option to reject a proposal.
>>> • This push for including generics started simultaneously, using the
>>> same process , as both the "Error
>>> handling" and the "Error values" designs. "Error values" was accepted and
>>> "Error handling" was rejected as results of that process, so rejection was
>>> clearly a possible outcome.
>>> • Since then, there have been numerous blog posts, threads on this
>>> mailing list, talks at conferences and appearances on podcasts by the Go
>>> team. All of them mention the possibility that generics might not happen.
>>> All threads (that I'm aware of) publicly discussing generics discuss the
>>> option not to include them at all at least once.
>>>
>>> I really don't think it's too much to ask, what level of evidence you
>>> are actually looking for. I also strongly feel that the case made by us is
>>> stronger than the case made that there was no discussion about giving up on
>>> generics. The latter seems - as far as I can tell - mainly rely on a)
>>> interpreting statements by members of the Go team in ways incompatible with
>>> the actual words being said and b) speculating about the management process
>>> at Google - without any evidence to base this speculation on.
>>>
>>> On Thu, Mar 18, 2021 at 1:11 PM Space A.  wrote:
>>>
 > What kind of proof would you find to be acceptable?  Can you give an
 example of something that I could say that you would consider to be a
 good answer to that question?  Thanks.

 Ian, seriously. ANY evidence please, which you think "proves" that
 there was an open and public discussion on dropping generics from your
 daily agenda and focusing and spending time on more important things, such
 as first class Android support.

 ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :

> On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
> >
> > Can you provide any proof that there was an open public discussion?
>
> What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  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/1624a7bf-1418-4a24-9e11-5ba8c76852b3n%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/CADKwOTdE5JkAqrq1q%3DMerb%2BXGjZFCxYN-KZrb5mgctTGCbL7YQ%40mail.gmail.com.

[go-nuts] Re: build world question

[Hotei]

Brian, 
Looks like a case of "pilot error".  After tinkering a bit more it started 
to work.  Each directory has its own go.mod file.  Took a little while to 
figure out what the module wanted to see for versioning but that's seems to 
be sorted now.  Still have  a large number of projects to convert but at 
least the process seems to be working ok.  Thanks for the assistance.  
David
On Wednesday, March 17, 2021 at 3:29:37 PM UTC-4 Brian Candler wrote:

> What error do you see?
>
> Are your subdirectories independent modules in their own right (i.e. they 
> have their own "go.mod"), or just separate packages within the same module 
> (go.mod only exists at the top level)?  Normally the latter is what you 
> want.
>
> On Wednesday, 17 March 2021 at 17:57:55 UTC Hotei wrote:
>
>> Heeding the prodding of the go gurus on this list I just converted a 
>> bunch of old code to modules and was wondering what the "module" equivalent 
>> to "go build ./..." is.  I used to be able to use that command at the top 
>> of my code tree and it would attempt to build everything in the subdirs.  
>> Doesn't seem to work now even though each subdir compiles fine 
>> individually.  Haven't been reading golang-nuts every day so sorry if I 
>> missed a previous topic that solves this.
>>
>> Thanks
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/85c42ff3-9aae-43d2-86db-c0cda0520b08n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

['Axel Wagner' via golang-nuts]

I find your response disrespectful. You are completely ignoring (in the
sense of "refusing to take notice of") what I wrote.
I don't think it is possible to have a productive conversation as long as
you behave this way.

On Thu, Mar 18, 2021 at 1:48 PM Space A.  wrote:

> That's exactly what I'm saying, topic of dropping generics was never
> raised, so landing of some version of generics was implied by the process.
> In fact just a start of that process implied that dropping them entirely
> was never a question. There was no public discussion with that regard, no
> poll or anything.
>
>
>
> четверг, 18 марта 2021 г. в 15:42:44 UTC+3, axel.wa...@googlemail.com:
>
>> ISTM that we already provided a bunch of evidence, which you are
>> rejecting. so "any evidence" clearly is not good enough and you should be a
>> bit more specific.
>>
>> Just to name a few specific examples of evidence provided:
>> • The FAQ, as well as any interview of the question, have stated clearly
>> that generics *may* be added, if a satisfying design is found. "May", not
>> "will".
>> • The proposal process
>>  clearly
>> mentions the option to reject a proposal.
>> • This push for including generics started simultaneously, using the
>> same process , as both the "Error
>> handling" and the "Error values" designs. "Error values" was accepted and
>> "Error handling" was rejected as results of that process, so rejection was
>> clearly a possible outcome.
>> • Since then, there have been numerous blog posts, threads on this
>> mailing list, talks at conferences and appearances on podcasts by the Go
>> team. All of them mention the possibility that generics might not happen.
>> All threads (that I'm aware of) publicly discussing generics discuss the
>> option not to include them at all at least once.
>>
>> I really don't think it's too much to ask, what level of evidence you are
>> actually looking for. I also strongly feel that the case made by us is
>> stronger than the case made that there was no discussion about giving up on
>> generics. The latter seems - as far as I can tell - mainly rely on a)
>> interpreting statements by members of the Go team in ways incompatible with
>> the actual words being said and b) speculating about the management process
>> at Google - without any evidence to base this speculation on.
>>
>> On Thu, Mar 18, 2021 at 1:11 PM Space A.  wrote:
>>
>>> > What kind of proof would you find to be acceptable?  Can you give an
>>> example of something that I could say that you would consider to be a
>>> good answer to that question?  Thanks.
>>>
>>> Ian, seriously. ANY evidence please, which you think "proves" that there
>>> was an open and public discussion on dropping generics from your daily
>>> agenda and focusing and spending time on more important things, such as
>>> first class Android support.
>>>
>>> ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :
>>>
 On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
 >
 > Can you provide any proof that there was an open public discussion?

 What kind of proof would you find to be acceptable?  Can you give an
 example of something that I could say that you would consider to be a
 good answer to that question?  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/1624a7bf-1418-4a24-9e11-5ba8c76852b3n%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/CAEkBMfGYysAwJ59wqWwb4eC4_Th8Kzsbo_G1jm1nE_aYnDWFRw%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Robert Engels]

One other point on this. Generics will be trivial for 95% of the people - they 
will only need to be able to read and write the instantiation statements of 
type safe collections. 

Most developers don’t write the generic implementations - these are provided by 
library authors. 

As I’ve said before, I would of taken a more go-like approach - generics seem 
too technical for most go developers - but in the end they will be a net 
benefit. 

> On Mar 15, 2021, at 8:28 PM, Robert Engels  wrote:
> 
> 
> Very well said. 
> 
>>> On Mar 15, 2021, at 7:04 PM, Jeremy French  wrote:
>>> 
>> I was really trying not to weigh in here, mostly because it's a decision 
>> that has been decided, so there's not a lot of point in continuing the 
>> discussion, and yesterday it seemed like the thread would die, yet... it 
>> continues.
>> 
>> For context, I was against the generics proposal, primarily because it would 
>> make *my* life more complicated, while not providing *me* that much benefit. 
>>  I raised the concerns I had, especially in regards to the "if you don't 
>> like it, don't use it" arguments. I participated in a couple conversations 
>> on this mailing list.  In the end, I was fairly convinced that there were 
>> others in the community (and the community as a whole) who would benefit 
>> from the change far more than what it would cost me, and resigned myself to 
>> the change.
>> 
>> All of that is just to establish my bona fides.  If I were inclined to be 
>> biased on this topic, it would be against the Go team, not in their favor.  
>> 
>> And yet, I can say unequivocally that any suggestion that the Go team has 
>> railroaded this proposal through, or has ignored the concerns of its user 
>> base, is pure fiction.  Every single concern or question I've seen raised 
>> has been addressed respectfully and at face value - even, I would say - 
>> several concerns or complaints on this side of the argument that perhaps 
>> reasonably could have been scoffed at or dismissed as just stupid.  They 
>> have been respectful and attentive at every turn.  I don't necessarily agree 
>> or like the decision they made, but these character assassinations against 
>> them or implications that they are subject to corruption from their 
>> corporate parent have no supporting evidence that I've seen, including any 
>> presented in this thread.
>> 
>> It seems pretty clear that they are passionate about the health and 
>> longevity of the project, and are in the unenviable position of having to 
>> make a decision that is guaranteed to make some people angry no matter what 
>> they decide.  But in the end, it is their call to make, and they made it the 
>> best way they could think of to do so.  You can't ask any more than that.
>> 
>>> On Monday, March 15, 2021 at 6:14:36 PM UTC-4 Ian Lance Taylor wrote:
>>> On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com  wrote: 
>>> > 
>>> > I am in favor of the proposal but I think that accounting for popularity 
>>> > votes is not a good measure of things. 
>>> > A lot of people are at various stages of their technical journey in 
>>> > computer science and engineering and there has to be a weight given to 
>>> > the more technical opinions that is not reflected in the github 
>>> > upvote/downvote system. 
>>> > At one point, everyone would have upvoted that the earth was flat. 
>>> > 
>>> > Just a note in passing :) 
>>> 
>>> Yes. I am not saying that the proposal was adopted because it had 
>>> good support. I am arguing against the suggestion that the proposal 
>>> should not have been adopted because it had a lot of critics. 
>>> 
>>> Ian 
>>> 
>>> 
>>> > On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote: 
>>> >> 
>>> >> On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote: 
>>> >> > 
>>> >> > > For example, the multiple proposals that flowed out of 
>>> >> > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
>>> >> >  
>>> >> > None of them have been adopted. 
>>> >> > 
>>> >> > I remember what was happening to "try" error handling proposal. It was 
>>> >> > withdrawn only because of active resistance by the community. 
>>> >> > 
>>> >> > And what's happened to a new "generics" proposal, it also got a lot of 
>>> >> > critics but was "accepted" in less than a month after formal 
>>> >> > publication on github. As Russ said "No change in consensus". What 
>>> >> > does it mean? Who are these people who can change the consensus? How 
>>> >> > was it measured? A few days after Russ locked it, so nobody can even 
>>> >> > say a word against it if they wanted. So it looks very much that 
>>> >> > company management learned from "try" proposal. 
>>> >> 
>>> >> The design draft was put up for discussion for months before it became 
>>> >> a formal proposal. It was not new. 
>>> >> 
>>> >> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs 
>>> >> up and 123 thumbs down (and ten "confused"). Yes, there were cri

Re: [go-nuts] No generic, part -2

[Space A.]

That's exactly what I'm saying, topic of dropping generics was never 
raised, so landing of some version of generics was implied by the process. 
In fact just a start of that process implied that dropping them entirely 
was never a question. There was no public discussion with that regard, no 
poll or anything.



четверг, 18 марта 2021 г. в 15:42:44 UTC+3, axel.wa...@googlemail.com: 

> ISTM that we already provided a bunch of evidence, which you are 
> rejecting. so "any evidence" clearly is not good enough and you should be a 
> bit more specific.
>
> Just to name a few specific examples of evidence provided:
> • The FAQ, as well as any interview of the question, have stated clearly 
> that generics *may* be added, if a satisfying design is found. "May", not 
> "will".
> • The proposal process 
>  clearly 
> mentions the option to reject a proposal.
> • This push for including generics started simultaneously, using the same 
> process , as both the "Error handling" 
> and the "Error values" designs. "Error values" was accepted and "Error 
> handling" was rejected as results of that process, so rejection was clearly 
> a possible outcome.
> • Since then, there have been numerous blog posts, threads on this mailing 
> list, talks at conferences and appearances on podcasts by the Go team. All 
> of them mention the possibility that generics might not happen. All threads 
> (that I'm aware of) publicly discussing generics discuss the option not to 
> include them at all at least once.
>
> I really don't think it's too much to ask, what level of evidence you are 
> actually looking for. I also strongly feel that the case made by us is 
> stronger than the case made that there was no discussion about giving up on 
> generics. The latter seems - as far as I can tell - mainly rely on a) 
> interpreting statements by members of the Go team in ways incompatible with 
> the actual words being said and b) speculating about the management process 
> at Google - without any evidence to base this speculation on.
>
> On Thu, Mar 18, 2021 at 1:11 PM Space A.  wrote:
>
>> > What kind of proof would you find to be acceptable?  Can you give an
>> example of something that I could say that you would consider to be a
>> good answer to that question?  Thanks. 
>>
>> Ian, seriously. ANY evidence please, which you think "proves" that there 
>> was an open and public discussion on dropping generics from your daily 
>> agenda and focusing and spending time on more important things, such as 
>> first class Android support.
>>
>> ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :
>>
>>> On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
>>> >
>>> > Can you provide any proof that there was an open public discussion?
>>>
>>> What kind of proof would you find to be acceptable?  Can you give an
>>> example of something that I could say that you would consider to be a
>>> good answer to that question?  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/1624a7bf-1418-4a24-9e11-5ba8c76852b3n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

['Axel Wagner' via golang-nuts]

ISTM that we already provided a bunch of evidence, which you are rejecting.
so "any evidence" clearly is not good enough and you should be a bit more
specific.

Just to name a few specific examples of evidence provided:
• The FAQ, as well as any interview of the question, have stated clearly
that generics *may* be added, if a satisfying design is found. "May", not
"will".
• The proposal process
 clearly mentions
the option to reject a proposal.
• This push for including generics started simultaneously, using the same
process , as both the "Error handling"
and the "Error values" designs. "Error values" was accepted and "Error
handling" was rejected as results of that process, so rejection was clearly
a possible outcome.
• Since then, there have been numerous blog posts, threads on this mailing
list, talks at conferences and appearances on podcasts by the Go team. All
of them mention the possibility that generics might not happen. All threads
(that I'm aware of) publicly discussing generics discuss the option not to
include them at all at least once.

I really don't think it's too much to ask, what level of evidence you are
actually looking for. I also strongly feel that the case made by us is
stronger than the case made that there was no discussion about giving up on
generics. The latter seems - as far as I can tell - mainly rely on a)
interpreting statements by members of the Go team in ways incompatible with
the actual words being said and b) speculating about the management process
at Google - without any evidence to base this speculation on.

On Thu, Mar 18, 2021 at 1:11 PM Space A.  wrote:

> > What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  Thanks.
>
> Ian, seriously. ANY evidence please, which you think "proves" that there
> was an open and public discussion on dropping generics from your daily
> agenda and focusing and spending time on more important things, such as
> first class Android support.
>
> ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :
>
>> On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
>> >
>> > Can you provide any proof that there was an open public discussion?
>>
>> What kind of proof would you find to be acceptable?  Can you give an
>> example of something that I could say that you would consider to be a
>> good answer to that question?  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/CAEkBMfGnwhTuFHu0HvJrtymvWsazxAh-ijZYX%2BDjuV3L7FoukA%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[ma...@eliasnaur.com]

On Thursday, 18 March 2021 at 13:11:33 UTC+1 Space A. wrote:

> > What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  Thanks. 
>
> Ian, seriously. ANY evidence please, which you think "proves" that there 
> was an open and public discussion on dropping generics from your daily 
> agenda and focusing and spending time on more important things, such as 
> first class Android support.
>
>
Not only is this argument arrogant in judging importance on behalf of Ian 
(or the Go team), it is also invalid; all proposals, including generics, 
are judged on their merits, not in an importance competition with all other 
proposals.

Elias

-- 
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/3dbb1fb2-5cd1-43db-a97c-e1ad1758a026n%40googlegroups.com.

Re: [go-nuts] Re: now that the election is over can we please remove the political ad for golang.org

[Space A.]

Btw, when this started (see original thread) I compared some main pages of 
websites of popular languages. And you know what? I didn't find stupid 
banner on Java or Rust websites, and on many others. Maybe they were smart 
enough to show it only to US visitors, idk. Anyways, Russ Cox obviously 
thinks that there is no other world, so... 

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

So if you live outside of US, and contributed to the language or ecosystem 
you can literally go to hell, as according to him, only US-related activity 
counts and matters. 

Actually "situation there" does not affect me because I use ABP, but funny 
thing is there is chance that Go will become first programming language 
ever whose website will end up in spam filters.


среда, 17 марта 2021 г. в 21:47:33 UTC+3, Rusco: 

> afaik George Soros is behind the BLM Campaign, this alone justifies 
> removing the banner. From now on the Golang Community should be inclusive 
> and tolerate all political opinions. Seems to be harder than writing speedy 
> go code ... 
>
> On Wednesday, 17 March 2021 at 17:59:52 UTC mortdeus wrote:
>
>> "Ian, This individual is either trolling us or suffering some sort of 
>> psychological crisis that warrants intervention by a mental health 
>> professional."
>>
>> Somewhere in the middle, but mostly drunk and extremely aggravated.
>>
>> If what I am saying is annoying you to the point that you want to ban me. 
>> Then just understand that unlike you, I don't get the option to magically 
>> "ban" away the seriously offensive to conservative political ads.
>>
>> Just because you don't understand why BLM "triggers" us. (to use your 
>> terminology) is because you weren't on the other side being persecuted for 
>> your beliefs during this past election. 
>>
>> What's the goal here, to be inclusive to everybody regardless of sex, 
>> race, religion. Or to literally say we draw a line at religion. Because 
>> that is what a political ideology is. Dogma you subscribe to so faithfully 
>> that you convinced you are the only one that is saved and the rest of the 
>> world be damned. 
>>
>> Ban me, because honestly you'd probably be doing me a favor. But like I 
>> mentioned earlier, this is the one issue that is actually heartbreaking to 
>> me. The idea that in order to be a Good Gopher you best vote for Joe Biden.
>>
>> idk im done. ive said all that needed to be said. do what you will, but 
>> just understand that nobody here will have any excuses if it turns out that 
>> the cranks like myself were right in shouting at the top of their lungs 
>> "HEY YOU REAY DONT WANT TO FOLLOW THE RABBIT DOWN THAT HOLE 
>> UNLESS YOU ARE ALICE"
>>
>> You aren't Alice and this story wasn't written with you in mind.
>>
>>
>> On Wednesday, March 17, 2021 at 12:40:19 PM UTC-5 Kurtis Rader wrote:
>>
>>> Ian, This individual is either trolling us or suffering some sort of 
>>> psychological crisis that warrants intervention by a mental health 
>>> professional. Either way I think we've all had quite enough of their rants 
>>> and their behavior warrants banning from this mailing list.
>>>
>>> On Wed, Mar 17, 2021 at 10:33 AM mortdeus  wrote:
>>>
 There is a reason why Steve Jobs spent all the day, yelling at you 
 stubborn #&@#s for not getting why Bob Dylan is an essential component to 
 why Apple is now the most valuable company in the world. 

 If what I am saying sounds crazy, just know you thought my ideas were 
 the dopest ideas in SV when he crammed everything I just said ^ into 
 "Think 
 Different" and had the cult of personality thing going for him, so you 
 would all just listen and do. 

 On Wednesday, March 17, 2021 at 12:28:28 PM UTC-5 mortdeus wrote:

> I literally don't want the banner because I don't like the way it 
> looks. It's really like an ocd thing for me. And you all need to 
> understand, that is extremely important. Way more important than your 
> political concerns. Because like I said, a tool like this is honestly the 
> only effective way to implement the change you all claim to be advocates 
> for. That is why it needs to remain unmolested. 
>
> On Wednesday, March 17, 2021 at 12:26:19 PM UTC-5 mortdeus wrote:
>
>> No Go is literally a 1000x bigger achievement than the Mona Lisa, 
>> because somehow we managed to get a bunch of people to come together and 
>> somehow create a miracle of engineering. 
>>
>> In a perfect world, where the market also adopts the most efficient 
>> technological solutions.
>>
>> Plan 9 should have been the operating system that ruled the Earth and 
>> became essentially wh

Re: [go-nuts] No generic, part -2

[Space A.]

> What kind of proof would you find to be acceptable?  Can you give an
example of something that I could say that you would consider to be a
good answer to that question?  Thanks.

Ian, seriously. ANY evidence please, which you think "proves" that there
was an open and public discussion on dropping generics from your daily
agenda and focusing and spending time on more important things, such as
first class Android support.

ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :

> On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
> >
> > Can you provide any proof that there was an open public discussion?
>
> What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  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/CADKwOTe94%2BPj6pQ%3DnW3FLez-aLMUN9%3DjRJBUnXCyferTRZeYwg%40mail.gmail.com.

Re: [go-nuts] Re: No generic, part -2

['Axel Wagner' via golang-nuts]

On Thu, Mar 18, 2021 at 12:06 PM wilk  wrote:

> It is still possible to write a formal proposal "canceling generics" if
> someone find now a good reason, right ? (at the time of modules i
> believe it was).
>

I believe it is. We can always change things in response to new information
- we could, theoretically, even change decisions we made years ago.

However, it should be clear that the bar for what constitutes a "good
reason" becomes higher over time. In particular, after the acceptance of
the proposal, the minimum bar is that it really is new information. Because
if the argument was already known, it was already considered and weighed as
part of the decision.

As far as I can tell, the things mentioned in this thread (and other recent
threads on this list) are not new. New information might be some technical
difficulty in the implementation, or a corner case or fundamental problem
we didn't know before. Evidence for overwhelming resistance to generics
could also be new information. Though I'm not sure where it's supposed to
come from - as mentioned a couple of times, it's hard to get representative
polling information. But this was what ultimately killed the `try` error
handling proposal, so it's not unthinkable.


>
> Thanks for your patience
>
> >
> > Ian
> >
> >
> >
> >> ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor :
> >>>
> >>> On Tue, Mar 16, 2021 at 6:51 AM Space A.  wrote:
> >>> >
> >>> > > (To be clear, your original claim was that there *was* no
> discussion - which is at least easy to address, because it's clearly not
> true. There was over three years of active discussion on this)
> >>> >
> >>> > No, and I can repeat, there was no (public) discussion on whether
> the idea of generics in Go should be completely dropped. It *was* always a
> "discussion" of how to improve and implement generics in a Go way, but not
> of generics themselves as something to be avoided by all means.
> >>>
> >>> I'm sorry, but that simply isn't the case.  Many different people at
> >>> many different times suggested that the idea of adding generics should
> >>> be dropped.  Those ideas were discussed, supported, opposed, and so
> >>> forth.  It's been a long discussion over many years.
> >>>
> >>> Ian
> >
>
>
> --
> 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/s2vc5m%24sgd%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/CAEkBMfHzzw-bs48%2BMNwVaR9KwsAHdkhvmAhEHqAwS7XoHjp%2BaA%40mail.gmail.com.

[go-nuts] Re: No generic, part -2

[wilk]

On 17-03-2021, Ian Lance Taylor wrote:
> On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
>>
>> Can you provide any proof that there was an open public discussion?
>
> What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  Thanks.

It is still possible to write a formal proposal "canceling generics" if
someone find now a good reason, right ? (at the time of modules i
believe it was).

Thanks for your patience

>
> Ian
>
>
>
>> ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor :
>>>
>>> On Tue, Mar 16, 2021 at 6:51 AM Space A.  wrote:
>>> >
>>> > > (To be clear, your original claim was that there *was* no discussion - 
>>> > > which is at least easy to address, because it's clearly not true. There 
>>> > > was over three years of active discussion on this)
>>> >
>>> > No, and I can repeat, there was no (public) discussion on whether the 
>>> > idea of generics in Go should be completely dropped. It *was* always a 
>>> > "discussion" of how to improve and implement generics in a Go way, but 
>>> > not of generics themselves as something to be avoided by all means.
>>>
>>> I'm sorry, but that simply isn't the case.  Many different people at
>>> many different times suggested that the idea of adding generics should
>>> be dropped.  Those ideas were discussed, supported, opposed, and so
>>> forth.  It's been a long discussion over many years.
>>>
>>> Ian
>


-- 
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/s2vc5m%24sgd%241%40ciao.gmane.io.

Re: [go-nuts] Use cases for custom ResponseWriter

[Amit Saha]

On Wed, Mar 17, 2021 at 8:54 PM Amnon  wrote:
>
>
> https://github.com/gorilla/handlers
> contains a number of ResponseWriters to provide functions such as compression 
> and logging
> On Wednesday, 17 March 2021 at 08:41:09 UTC be...@pferdewetten.de wrote:
>>
>> net/http/httptest contains an implementation of http.ResponseWriter that's 
>> used for testing request handlers in isolation (without spinning up a 
>> server).

Thanks both of you!

>>
>> On 17.03.21 03:12, Amit Saha wrote:
>>
>> Hi all,
>>
>> I came across the need for writing a custom ResponseWriter when I
>> wanted to log the response status code.
>>
>> Is there any other use case where this is needed to implement one?
>> Thanks and appreciate any pointers.
>>
>> Best Regards,
>> Amit.
>>
>> --
>> Gregor Best
>>   be...@pferdewetten.de
>
> --
> 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/5261f1fb-5bba-4c11-b650-304aea20427cn%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/CANODV3%3D2Ra64PCdva6d6oPxsQ%2B8kC12zAi42UGFP98_NxZ7sUw%40mail.gmail.com.

[go-nuts] Re: %v for []string{} and []string{""}

[Brian Candler]

Sure.  I don't have a problem with nil slice and empty slice showing the 
same, because in all important ways they behave the same - i.e. they have 
len() of 0, you can append() to them, etc.  The only behavioural difference 
I can think of is if you explicitly test "foo == nil".

However, a slice with len=1 that showed the same as one with len=0, was 
what confused me :-)

On reflection, %v is intentionally ambiguous.  There are other examples, 
e.g.
- []string{"a","b"} and []string{"a b"}
- []string{"", ""} and []string{" "}

On Wednesday, 17 March 2021 at 21:24:46 UTC tapi...@gmail.com wrote:

> Printing a nil slice also get the same output [].
>
> I remembered Rob Pike ever said in an issue thread that this can't be 
> changed now for compatibility reason.
>
> On Monday, March 15, 2021 at 8:18:46 AM UTC-4 Brian Candler wrote:
>
>> I was slightly surprised to discover that the Print() output for an empty 
>> slice, and a 1-element slice containing the empty string, are the same:
>>
>> https://play.golang.org/p/btkzgk4LMT9
>>
>> It does follow logically from the rules 
>> .  I guess I need to train 
>> myself to use %q or %#v.
>>
>

-- 
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/52ec470e-65d8-40ac-8b6b-b800da813dbfn%40googlegroups.com.