[go-nuts] is func schedule always run on g0's stack?

[xie cui]

https://github.com/golang/go/blob/master/src/runtime/proc.go#L3086

-- 
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/d07b759d-7e13-4f07-967b-17abbd7ad37dn%40googlegroups.com.

[go-nuts] insane idea to eliminate CGO latency

[Jason E. Aten]

I was noodling about how to minimize the cost of crossing the CGO barrier 
from Go code into C code and back.

Then I thought, what if I look at this the other way around.

Instead of teaching the Go compiler how to better run C code, what if a C 
compiler (e.g. clang) was taught to generate code that used the Go stack 
and calling conventions.

Theoretically, the cc output "in Go convention" could be linked with Go 
code without paying the CGO penalty, no?

How crazy is this? :)

-- 
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/028ecd62-5f9f-4cb6-95df-a0b48ff3d825n%40googlegroups.com.

[go-nuts] Re: Does current GC move object now?

[rmfr]

Maybe the reason for such a strict rule on using cgo is just to take 
precautions if our GC moves object in the future? And at that time, the 
syscall implementation must be rewritten to add some codes to pinning the 
objects used by each syscall from being moved. Am I correct?

On Sunday, March 14, 2021 at 2:11:18 PM UTC+8 rmfr wrote:

> I am watching the implementation of syscall `writev` from [here](
> https://github.com/golang/sys/blob/bd2e13477e9c63125302cd9da2d61879c6aa1721/unix/zsyscall_linux.go#L1641),
>  
> and comparing it with the [proposal](
> https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md) 
> of cgo. I found the rule applies on cgo and syscall is inconsistent. 
>
> If the object could be moved during GC, then the code to implement 
> `writev` is incorrect. Because GC could happen during the syscall and the 
> byte slices kernel is using has been moved! :-(
>
> If the object may not be moved during GC, then the code to implement 
> syscall `writev` is correct. But from the perspective of go runtime, cgo is 
> just a kind of special "syscall", then the rule applies to cgo now is far 
> too strict -- you simply couldn't call a C API like `writev` which takes 
> array of byte slices as input arg (because the rule applies on cgo now only 
> allow one input arg contains at most one go pointer).
>
> Maybe I have missed something, please correct me. Thanks a lot for your 
> patient and kindness :-)
>

-- 
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/57c3f2e9-e28c-43e3-b765-b33434b6d1f5n%40googlegroups.com.

[go-nuts] Does current GC move object now?

[rmfr]

I am watching the implementation of syscall `writev` from 
[here](https://github.com/golang/sys/blob/bd2e13477e9c63125302cd9da2d61879c6aa1721/unix/zsyscall_linux.go#L1641),
 
and comparing it with the 
[proposal](https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md)
 
of cgo. I found the rule applies on cgo and syscall is inconsistent. 

If the object could be moved during GC, then the code to implement `writev` 
is incorrect. Because GC could happen during the syscall and the byte 
slices kernel is using has been moved! :-(

If the object may not be moved during GC, then the code to implement 
syscall `writev` is correct. But from the perspective of go runtime, cgo is 
just a kind of special "syscall", then the rule applies to cgo now is far 
too strict -- you simply couldn't call a C API like `writev` which takes 
array of byte slices as input arg (because the rule applies on cgo now only 
allow one input arg contains at most one go pointer).

Maybe I have missed something, please correct me. Thanks a lot for your 
patient and kindness :-)

-- 
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/a6e88a30-a8e2-4745-93ee-cf79fa636d8dn%40googlegroups.com.

[go-nuts] Re: How to call a C `writev` styled library api via cgo without allocation and copying of the whole byte slice vector?

[rmfr]

I have read this proposal 
carefully 
https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md#proposal
   
   1. Go code may pass a Go pointer to C provided that the Go memory to 
   which it points does not contain any Go pointers.


   - The C code must not store any Go pointers in Go memory, even 
   temporarily.
   - When passing a pointer to a field in a struct, the Go memory in 
   question is the memory occupied by the field, not the entire struct.
   - When passing a pointer to an element in an array or slice, the Go 
   memory in question is the entire array or the entire backing array of the 
   slice.
   - *Passing a Go pointer to C code means that that Go pointer is visible 
   to C code; passing one Go pointer does not cause any other Go pointers to 
   become visible.*
   - *The maximum number of Go pointers that can become visible to C code 
   in a single function call is the number of arguments to the function.*

 So does it is correct that you cannot call some C api like `writev` safely 
without concatenating all the byte slices together into one big byte slice?

On Saturday, March 13, 2021 at 10:24:52 PM UTC+8 rmfr wrote:

> Say here is a C api like `ssize_t writev(const struct iovec *iov, int 
> iovcnt)` which the definition of iovec is like below:
>
> ```
> struct iovec {
>  uint8_t   *Base;  /* Base address. */
>  uint64_t Len;/* Length. */
>  };
> ```
>
> For C api which like `ssize_t write(const void *buf, size_t nbyte)`, the 
> solution would be quite straight forward:
>
> ```
> bs := make([]byte, 1024*1024*512)
> // without extra memory allocation and copying of the whole input byte 
> slice :-D
> rc := C.write(unsafe.Pointer([0]), C.int(len(bs)))
> ```
>
> But how to call C `writev` style API without extra memory allocation or 
> copying of the whole byte slice vector?
>
> ```
> bsv := make([][]byte, 1024)
> for i := range bsv{
> bsv[i] = make([]byte, 5*1024*(rand.Intn(i)+1))
> }
> // assuming that allocation of a iovec array is acceptable
> // but allocation and copying of all bsv[x] byte slice member is 
> unacceptable
> //
> iovec := make([]syscall.Iovec, len(bsv))
> for i := range bsv {
> bs := bsv[i]
> if len(bs) > 0 {
> iovec[i].Base = unsafe.Pointer([0])
> iovec[i].Len = uint64(len(bs))
> }
> }
> //
> // rc := C.writev( /* how? :-( */)
> rc := C.writev(unsafe.Pointer([0]), C.int(len(iovec))) // Does this 
> code is right and safe?
> ```
>
> Does the code above is right?
>
> I have read cgo's docs carefully, and here is a constraint from 
> https://golang.org/cmd/cgo/#hdr-Passing_pointers:
>
> > Go code may pass a Go pointer to C provided the Go memory to which it 
> points does not contain any Go pointers.
>
> If the Go memory pointed by `unsafe.Pointer([0])` contains pointer 
> which points to these byte slice members of bsv, so it would be a 
> *violation* of the cgo constraint above. And that means you could not 
> call C `writev` style API without allocation and copying of the whole 
> vector.
>
> Please correct me if I get something wrong. Thanks a lot :-D
>

-- 
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/ed9086ad-db73-489c-8bd5-dc2c17639ffan%40googlegroups.com.

Re: [go-nuts] Unexpected error from os.DirEntry on Win10

[rob]

I need file timestamp and size, so I need a full FileInfo.

-- 
  rob
  drrob...@fastmail.com



On Sat, Mar 13, 2021, at 6:11 PM, Axel Wagner wrote:
> 
> 
> On Sat, Mar 13, 2021 at 11:52 PM rob  wrote:
>> Sorry, I did not intend to open a new thread.

>> I don't know how to answer you about the actual contents of the directory of 
>> interest.  It's my c:\users\rob\Documents directory.

>> There are a lot of files there.  I'm writing my own version of the dir 
>> command, one that will sort and behave exactly as I want.  I decided to 
>> experiment w/ the new library definitions; and discovered that DirEntry is 
>> not a replacement for FileInfo.  I thought that was the intent of the Go 
>> team, but I guess did not understand.

> It is, for most use-cases that want to list the contents of a file. It works 
> around the fact that on many platforms, you already get *some* info in the 
> readdir call but some info only by following it up with a Stat - returning a 
> FileInfo requires you to do the stat, but most applications only need the 
> things returned already by readdir itself and don't need to follow it up with 
> a separate stat call. The DirEntry design splits up the info returned by 
> readdir (namely the file names and the file mode) from the info returned by 
> stat (the DirEntry.Info method).
> 
> I still don't understand why you think that ReadDir/DirEntry did not work for 
> you - as I said, from your code the issue seems to simply be that you call 
> ReadDir on regular files, instead of directories. OTOH, as long as you've 
> find a solution that works for you, I guess that's fine.
>>   In my code I went back to using Lstat, and instead of ioutil.ReadDir, I 
>> now use 

>> f, err := os.Open(directoryname)

>> if err != nil { blah blah blah}

>> files, err := f.Readdir(0)

>> if err != nil { blah blah blah}

>> And this works for me.

>> --rob solomon

>> 

>> 

>> On 3/11/21 4:00 PM, Axel Wagner wrote:
>>> I don't understand why you opened a new thread. But FWIW, it would still be 
>>> useful to know 
>>> a) what the actual contents of the directory are you are globbing
>>> b) which of those file names is then giving you an error
>>> c) and which specific call is returning that error.
>>> 
>>> Your message "Unexpected error from os.DirEntry" is confusing, as the only 
>>> method of os.DirEntry that could return an error, hardcodes that error to 
>>> be nil, as far as I can tell:
>>> https://github.com/golang/go/blob/b3896fc331c36a539f825f1f656cef3f9cdffd3f/src/os/dir_windows.go#L68
>>> 
>>> In the other thread, I also tried to provide a plausible explanation from 
>>> the limited info - it seems strange that you are globbing for *.txt files 
>>> and then call ReadDir with those filenames. Have you read that message?
>>> 
>>> On Thu, Mar 11, 2021 at 9:31 PM rob  wrote:
 As the subject line says, this is on windows.
 I'm getting the file not found error for every file returned by the glob 
 function.   
 
 I guess I misunderstood the purpose of ReadDir, and I really need to call 
 os.Lstat to retrieve the directory information for each individual file 
 that matches the glob pattern on widows 10.
 
 I'll check,  but I'm able to call os.ReadDir on an individual file on 
 Ubuntu 20.04.  I'll confirm when I get home that I'm getting a FileInfo 
 structure returned from this routine 
 
 
 
 -- 
   rob
   drrob...@fastmail.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/137cb626-90f1-455e-b0aa-7a6d476e3813%40www.fastmail.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/df41189f-9f10-4a86-a3d8-5f8da6c0d2af%40www.fastmail.com.

Re: [go-nuts] Re: Error running gollvm on Ubuntu 20.04

[Khanh TN]

Hi, Ian,
It does look like importing golang.org/x/sys/unix causes the problem
A simple go program like

package main

import (
 "fmt"
 "golang.org/x/sys/unix"
)
 
func main() {
   fmt.Println("Hello, World!")
   fmt.Println(unix.Getpagesize())
}

does cause the same error as before. This file builds and runs fine with my 
normal Go but gives that error with Gollvm. If I do not include unix, 
Gollvm does work though.
What do you suggest?

Khanh
On Wednesday, March 10, 2021 at 11:14:19 AM UTC+8 Ian Lance Taylor wrote:

> On Tue, Mar 9, 2021 at 6:29 PM Khanh TN  wrote:
> >
> > Thanks a lot for the fix!
> > I tried git pull all the repos and reinstalled gollvm and I can run "go" 
> now.
> >
> > However there are still problems.
> > I am trying "go build" on some of my go code. Some build just fine.
> > But there is one piece of code that "go build" gives this error:
> > "/usr/bin/ld.gold: error: $WORK/b076/_pkg_.a(gccgo_c.o): failed to match 
> split-stack sequence at section 1 offset 0
> > /usr/bin/ld.gold: error: $WORK/b076/_pkg_.a(gccgo_c.o): failed to match 
> split-stack sequence at section 1 offset a6"
> >
> > On this piece, if I run "go build" using normal Go, not gollvm, it 
> builds just fine.
> > Is there still a bug or is it on my end?
>
> I'm not sure. What version of gold are you using? Do you happen to
> know if the program you are building imports golang.org/x/sys/unix? I
> ask that to try to figure out which gccgo_c file is involved here.
>
> 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/28984b31-abab-4300-b64a-6b71d2866d24n%40googlegroups.com.

Re: [go-nuts] Re: Error running gollvm on Ubuntu 20.04

[Khanh TN]

Hi Ian,
"gold --version" gives me "GNU gold (GNU Binutils for Ubuntu 2.34) 1.16"
"go list -m all" does list the module golang.org/x/sys. Does it help with 
the case?
Thanks for your help.

Khanh

On Wednesday, March 10, 2021 at 11:14:19 AM UTC+8 Ian Lance Taylor wrote:

> I'm not sure. What version of gold are you using? Do you happen to 
> know if the program you are building imports golang.org/x/sys/unix? I 
> ask that to try to figure out which gccgo_c file is involved here. 
>
> 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/7c305fa5-c162-41a4-8e4d-b43681717cbfn%40googlegroups.com.

Re: [go-nuts] Unexpected error from os.DirEntry on Win10

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 11:52 PM rob  wrote:

> Sorry, I did not intend to open a new thread.
>
> I don't know how to answer you about the actual contents of the directory
> of interest.  It's my c:\users\rob\Documents directory.
>
> There are a lot of files there.  I'm writing my own version of the dir
> command, one that will sort and behave exactly as I want.  I decided to
> experiment w/ the new library definitions; and discovered that DirEntry is
> not a replacement for FileInfo.  I thought that was the intent of the Go
> team, but I guess did not understand.
>
It is, for most use-cases that want to list the contents of a file. It
works around the fact that on many platforms, you already get *some* info
in the readdir call but some info only by following it up with a Stat -
returning a FileInfo requires you to do the stat, but most applications
only need the things returned already by readdir itself and don't need to
follow it up with a separate stat call. The DirEntry design splits up the
info returned by readdir (namely the file names and the file mode) from the
info returned by stat (the DirEntry.Info method).

I still don't understand why you think that ReadDir/DirEntry did not work
for you - as I said, from your code the issue seems to simply be that you
call ReadDir on regular files, instead of directories. OTOH, as long as
you've find a solution that works for you, I guess that's fine.

>   In my code I went back to using Lstat, and instead of ioutil.ReadDir, I
> now use
>
> f, err := os.Open(directoryname)
>
> if err != nil { blah blah blah}
>
> files, err := f.Readdir(0)
>
> if err != nil { blah blah blah}
>
> And this works for me.
>
> --rob solomon
>
>
>
> On 3/11/21 4:00 PM, Axel Wagner wrote:
>
> I don't understand why you opened a new thread. But FWIW, it would still
> be useful to know
> a) what the actual contents of the directory are you are globbing
> b) which of those file names is then giving you an error
> c) and which specific call is returning that error.
>
> Your message "Unexpected error from os.DirEntry" is confusing, as the only
> method of os.DirEntry that could return an error, hardcodes that error to
> be nil, as far as I can tell:
>
> https://github.com/golang/go/blob/b3896fc331c36a539f825f1f656cef3f9cdffd3f/src/os/dir_windows.go#L68
>
> In the other thread, I also tried to provide a plausible explanation from
> the limited info - it seems strange that you are globbing for *.txt files
> and then call ReadDir with those filenames. Have you read that message?
>
> On Thu, Mar 11, 2021 at 9:31 PM rob  wrote:
>
>> As the subject line says, this is on windows.
>> I'm getting the file not found error for every file returned by the glob
>> function.
>>
>> I guess I misunderstood the purpose of ReadDir, and I really need to call
>> os.Lstat to retrieve the directory information for each individual file
>> that matches the glob pattern on widows 10.
>>
>> I'll check,  but I'm able to call os.ReadDir on an individual file on
>> Ubuntu 20.04.  I'll confirm when I get home that I'm getting a FileInfo
>> structure returned from this routine
>>
>>
>>
>> --
>>   rob
>>   drrob...@fastmail.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/137cb626-90f1-455e-b0aa-7a6d476e3813%40www.fastmail.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/CAEkBMfGLk7Th3D9jE-AZB6FtqNgtp4No4HVXDtePC7EX_Y9F-g%40mail.gmail.com.

Re: [go-nuts] Unexpected error from os.DirEntry on Win10

[rob]

Sorry, I did not intend to open a new thread.

I don't know how to answer you about the actual contents of the 
directory of interest.  It's my c:\users\rob\Documents directory.


There are a lot of files there.  I'm writing my own version of the dir 
command, one that will sort and behave exactly as I want. I decided to 
experiment w/ the new library definitions; and discovered that DirEntry 
is not a replacement for FileInfo.  I thought that was the intent of the 
Go team, but I guess did not understand.  In my code I went back to 
using Lstat, and instead of ioutil.ReadDir, I now use


f, err := os.Open(directoryname)

if err != nil { blah blah blah}

files, err := f.Readdir(0)

if err != nil { blah blah blah}

And this works for me.

--rob solomon



On 3/11/21 4:00 PM, Axel Wagner wrote:
I don't understand why you opened a new thread. But FWIW, it would 
still be useful to know

a) what the actual contents of the directory are you are globbing
b) which of those file names is then giving you an error
c) and which specific call is returning that error.

Your message "Unexpected error from os.DirEntry" is confusing, as the 
only method of os.DirEntry that could return an error, hardcodes that 
error to be nil, as far as I can tell:
https://github.com/golang/go/blob/b3896fc331c36a539f825f1f656cef3f9cdffd3f/src/os/dir_windows.go#L68 



In the other thread, I also tried to provide a plausible explanation 
from the limited info - it seems strange that you are globbing for 
*.txt files and then call ReadDir with those filenames. Have you read 
that message?


On Thu, Mar 11, 2021 at 9:31 PM rob > wrote:


As the subject line says, this is on windows.
I'm getting the file not found error for every file returned by
the glob function.

I guess I misunderstood the purpose of ReadDir, and I really need
to call os.Lstat to retrieve the directory information for each
individual file that matches the glob pattern on widows 10.

I'll check,  but I'm able to call os.ReadDir on an individual file
on Ubuntu 20.04.  I'll confirm when I get home that I'm getting a
FileInfo structure returned from this routine



-- 
  rob

drrob...@fastmail.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/137cb626-90f1-455e-b0aa-7a6d476e3813%40www.fastmail.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/f677bd54-cb56-3c9c-8ea4-f89e45ceadb1%40fastmail.com.

Re: [go-nuts] Re: sort string slice like it contains key,val

['Axel Wagner' via golang-nuts]

One thing I would add is that you'll likely want to use the *Stable
versions of the sort functions, to make sure the order of equivalent
elements does not change.
Apart from that, the solution posted by Carla above with an added step to
remove duplicates seems like the best solution.

On Sat, Mar 13, 2021 at 11:27 PM Vasiliy Tolstov 
wrote:

> вс, 14 мар. 2021 г. в 01:10, Brian Candler :
> >
> > If I understand rightly, the values in the slice are to be interpreted
> (key, value) pairs?  In that case, the natural thing to me is to build a
> map.  This also takes care of "duplicate key, last value wins".  You can
> then sort the keys and convert it back:
> > https://play.golang.org/p/dTjmO18T1vQ
> >
> > However, I think that a slice of adjacent keys and values is not a
> particularly natural way to represent this data; it's clearer to make a
> structure which holds keys and vals.
> > https://play.golang.org/p/jq358XyKLlx
> >
>
> Yes, but in a small amount of items the operation on slice is faster
> than map. My case - have not more then 16-20 elements
>
> > On Saturday, 13 March 2021 at 13:37:21 UTC va...@selfip.ru wrote:
> >>
> >> Hi!
> >> I'm stuck at sorting stuff like
> >>
> []string{"xxxkey","xxxval","zzzkey","zzzval","aaakey","aaaval","zzzkey","val"}
> >> i need to get after sorting something like
> >> []string{"aaakey","aaaval", "xxxkey","xxxval","zzzkey","val"}
> >>
> >> So i'm sort by "key" and if key is duplicated - last wins.
> >> Mostly i want to avoid creating helper slices that contains keys and
> >> vals dedicated, does it possible to do sorting only by swapping
> >> "key/val" ?
> >>
> >> --
> >> Vasiliy Tolstov,
> >> e-mail: v.to...@selfip.ru
> >
> > --
> > 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/8eaa86e7-8787-4fc3-bed6-761586825cefn%40googlegroups.com
> .
>
>
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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/CACaajQvwWX3N0tczs31Jka%3D2UDD_kK2SN-QYJTS_eO46cLAyuQ%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/CAEkBMfEpv3MD_AA5SoVGViPxwrW-Tg_h1xbWo7D7tHhFjR88%3DQ%40mail.gmail.com.

Re: [go-nuts] Re: sort string slice like it contains key,val

[Vasiliy Tolstov]

вс, 14 мар. 2021 г. в 01:10, Brian Candler :
>
> If I understand rightly, the values in the slice are to be interpreted (key, 
> value) pairs?  In that case, the natural thing to me is to build a map.  This 
> also takes care of "duplicate key, last value wins".  You can then sort the 
> keys and convert it back:
> https://play.golang.org/p/dTjmO18T1vQ
>
> However, I think that a slice of adjacent keys and values is not a 
> particularly natural way to represent this data; it's clearer to make a 
> structure which holds keys and vals.
> https://play.golang.org/p/jq358XyKLlx
>

Yes, but in a small amount of items the operation on slice is faster
than map. My case - have not more then 16-20 elements

> On Saturday, 13 March 2021 at 13:37:21 UTC va...@selfip.ru wrote:
>>
>> Hi!
>> I'm stuck at sorting stuff like
>> []string{"xxxkey","xxxval","zzzkey","zzzval","aaakey","aaaval","zzzkey","val"}
>> i need to get after sorting something like
>> []string{"aaakey","aaaval", "xxxkey","xxxval","zzzkey","val"}
>>
>> So i'm sort by "key" and if key is duplicated - last wins.
>> Mostly i want to avoid creating helper slices that contains keys and
>> vals dedicated, does it possible to do sorting only by swapping
>> "key/val" ?
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.to...@selfip.ru
>
> --
> 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/8eaa86e7-8787-4fc3-bed6-761586825cefn%40googlegroups.com.



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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/CACaajQvwWX3N0tczs31Jka%3D2UDD_kK2SN-QYJTS_eO46cLAyuQ%40mail.gmail.com.

[go-nuts] Re: sort string slice like it contains key,val

[Brian Candler]

If I understand rightly, the values in the slice are to be interpreted 
(key, value) pairs?  In that case, the natural thing to me is to build a 
map.  This also takes care of "duplicate key, last value wins".  You can 
then sort the keys and convert it back:
https://play.golang.org/p/dTjmO18T1vQ

However, I think that a slice of adjacent keys and values is not a 
particularly natural way to represent this data; it's clearer to make a 
structure which holds keys and vals.
https://play.golang.org/p/jq358XyKLlx

On Saturday, 13 March 2021 at 13:37:21 UTC va...@selfip.ru wrote:

> Hi!
> I'm stuck at sorting stuff like
>
> []string{"xxxkey","xxxval","zzzkey","zzzval","aaakey","aaaval","zzzkey","val"}
> i need to get after sorting something like
> []string{"aaakey","aaaval", "xxxkey","xxxval","zzzkey","val"}
>
> So i'm sort by "key" and if key is duplicated - last wins.
> Mostly i want to avoid creating helper slices that contains keys and
> vals dedicated, does it possible to do sorting only by swapping
> "key/val" ?
>
> -- 
> Vasiliy Tolstov,
> e-mail: v.to...@selfip.ru
>

-- 
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/8eaa86e7-8787-4fc3-bed6-761586825cefn%40googlegroups.com.

Re: [go-nuts] sort string slice like it contains key,val

[Vasiliy Tolstov]

вс, 14 мар. 2021 г. в 00:41, Robert Engels :
>
> That wasn’t specified in the assignment :)

=) As always after first stuff i need the second =)

>
> On Mar 13, 2021, at 2:59 PM, Levieux Michel  wrote:
>
> 
> Your need is not only to sort your data elements then..?
> Using the previously advised solution you can just range the slice *after* 
> you sort it, so you can just check for the next element, which I'd say is not 
> *too bad*, what are your performance constraints?
>
> Le sam. 13 mars 2021 à 21:33, Vasiliy Tolstov  a écrit :
>>
>> Looks fine =) But how to remove duplicates?
>> I'm found this stuff
>> https://github.com/campoy/unique/blob/master/unique.go but as i
>> understand it needs to adapt to my case =)
>>
>> сб, 13 мар. 2021 г. в 16:47, 'Carla Pfaff' via golang-nuts
>> :
>> >
>> > On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:
>> >>
>> >> the sort package from the stdlib, it contains an interface that you can 
>> >> easily implement for such problematics :)
>> >
>> >
>> > Like this: https://play.golang.org/p/eoLJ2aVAWkD
>> >
>> >
>> > --
>> > 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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com.
>>
>>
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>>
>> --
>> 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/CACaajQt22G7JxY3yGiMt_H37aSkBatz3W6FZF90Gv90Uo0zTUA%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/CAL4P9zwK5vh1cwmq0yrCVuJsNCg0WXqfhZuXg%2BgV2MTFO--KvQ%40mail.gmail.com.



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

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

Re: [go-nuts] sort string slice like it contains key,val

[Vasiliy Tolstov]

I think that remove after sort is good for me, thanks

сб, 13 мар. 2021 г. в 23:59, Levieux Michel :
>
> Your need is not only to sort your data elements then..?
> Using the previously advised solution you can just range the slice *after* 
> you sort it, so you can just check for the next element, which I'd say is not 
> *too bad*, what are your performance constraints?
>
> Le sam. 13 mars 2021 à 21:33, Vasiliy Tolstov  a écrit :
>>
>> Looks fine =) But how to remove duplicates?
>> I'm found this stuff
>> https://github.com/campoy/unique/blob/master/unique.go but as i
>> understand it needs to adapt to my case =)
>>
>> сб, 13 мар. 2021 г. в 16:47, 'Carla Pfaff' via golang-nuts
>> :
>> >
>> > On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:
>> >>
>> >> the sort package from the stdlib, it contains an interface that you can 
>> >> easily implement for such problematics :)
>> >
>> >
>> > Like this: https://play.golang.org/p/eoLJ2aVAWkD
>> >
>> >
>> > --
>> > 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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com.
>>
>>
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>>
>> --
>> 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/CACaajQt22G7JxY3yGiMt_H37aSkBatz3W6FZF90Gv90Uo0zTUA%40mail.gmail.com.



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

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

Re: [go-nuts] sort string slice like it contains key,val

[Robert Engels]

That wasn’t specified in the assignment :)

> On Mar 13, 2021, at 2:59 PM, Levieux Michel  wrote:
> 
> 
> Your need is not only to sort your data elements then..? 
> Using the previously advised solution you can just range the slice *after* 
> you sort it, so you can just check for the next element, which I'd say is not 
> *too bad*, what are your performance constraints?
> 
>> Le sam. 13 mars 2021 à 21:33, Vasiliy Tolstov  a écrit :
>> Looks fine =) But how to remove duplicates?
>> I'm found this stuff
>> https://github.com/campoy/unique/blob/master/unique.go but as i
>> understand it needs to adapt to my case =)
>> 
>> сб, 13 мар. 2021 г. в 16:47, 'Carla Pfaff' via golang-nuts
>> :
>> >
>> > On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:
>> >>
>> >> the sort package from the stdlib, it contains an interface that you can 
>> >> easily implement for such problematics :)
>> >
>> >
>> > Like this: https://play.golang.org/p/eoLJ2aVAWkD
>> >
>> >
>> > --
>> > 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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com.
>> 
>> 
>> 
>> -- 
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>> 
>> -- 
>> 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/CACaajQt22G7JxY3yGiMt_H37aSkBatz3W6FZF90Gv90Uo0zTUA%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/CAL4P9zwK5vh1cwmq0yrCVuJsNCg0WXqfhZuXg%2BgV2MTFO--KvQ%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/39A64340-E93D-48E3-A66F-1BB7923B027E%40ix.netcom.com.

Re: [go-nuts] sort string slice like it contains key,val

[Levieux Michel]

Your need is not only to sort your data elements then..?
Using the previously advised solution you can just range the slice *after*
you sort it, so you can just check for the next element, which I'd say is
not *too bad*, what are your performance constraints?

Le sam. 13 mars 2021 à 21:33, Vasiliy Tolstov  a
écrit :

> Looks fine =) But how to remove duplicates?
> I'm found this stuff
> https://github.com/campoy/unique/blob/master/unique.go but as i
> understand it needs to adapt to my case =)
>
> сб, 13 мар. 2021 г. в 16:47, 'Carla Pfaff' via golang-nuts
> :
> >
> > On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:
> >>
> >> the sort package from the stdlib, it contains an interface that you can
> easily implement for such problematics :)
> >
> >
> > Like this: https://play.golang.org/p/eoLJ2aVAWkD
> >
> >
> > --
> > 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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com
> .
>
>
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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/CACaajQt22G7JxY3yGiMt_H37aSkBatz3W6FZF90Gv90Uo0zTUA%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/CAL4P9zwK5vh1cwmq0yrCVuJsNCg0WXqfhZuXg%2BgV2MTFO--KvQ%40mail.gmail.com.

Re: [go-nuts] sort string slice like it contains key,val

[Vasiliy Tolstov]

Looks fine =) But how to remove duplicates?
I'm found this stuff
https://github.com/campoy/unique/blob/master/unique.go but as i
understand it needs to adapt to my case =)

сб, 13 мар. 2021 г. в 16:47, 'Carla Pfaff' via golang-nuts
:
>
> On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:
>>
>> the sort package from the stdlib, it contains an interface that you can 
>> easily implement for such problematics :)
>
>
> Like this: https://play.golang.org/p/eoLJ2aVAWkD
>
>
> --
> 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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com.



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

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

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

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 6:24 PM Space A.  wrote:

> There is a huge difference between generics and some regular questions
> like `Etag` implementation, isn't it? In time, investments, "community
> demand", commitments to upper management, etc
>

Indeed. That doesn't change the fact that Russ has a track record and I
trust him.


> And Russ didn't write academic paper regarding it
>

Apparently I missed something. I'm unaware of any papers by Russ.


> (before accepting proposal in less than a month after it was published). =)
>

The proposal has been evolving and discussed for almost three years before
that. The reason it got accepted in the space of a months is that it was
only published as a proposal once the authors felt confident that the
refinements they made in response to the public discussion were sufficient
to make it acceptable. In particular, it has changed very little from the
version they posted more than a year earlier. After three years of
discussion, it would have been surprising if new flaws would have surfaced
that made it intractable.

It is a testament to how thoroughly it was discussed, not an indication
that it wasn't.

FWIW, if you only focus on the one-month period between the proposal
getting posted and it being accepted, I am beginning to understand why you
think there was never a possibility of it being rejected. It would mean you
are unaware of the decade of discussion preceding it.



> сб, 13 мар. 2021 г. в 19:39, Axel Wagner :
>
>> On Sat, Mar 13, 2021 at 4:59 PM Space A.  wrote:
>>
>>> You are a smart guy, one of the smartest I have ever talked to. But it
>>> looks like you somehow missed a very obvious thing. The people you
>>> mentioned (and most of the so-called Go team) AFAIK are Google employees.
>>> They work for a company and they are paid for the work they do.
>>>
>>
>> I did not miss this.
>>
>>
>>> If, as you say, they spend so much time, literally years, keep replying
>>> "if we find an approach that gives value blablabla", how do you imagine
>>> anyone responsible for the process at the end say smth like: "Alright guys,
>>> after spending so many man-years we have few solutions, but we finally
>>> realized that we were moving in wrong direction, so now we gonna be
>>> dropping everything for the sake of better future of Go".
>>>
>>
>> The person responsible for the process (if there is any one person) is
>> Russ. I would have expect him to say that, if it was his opinion. He has a
>> good track record of acknowledging the arguments on all sides of the
>> process and committing to a decision - even it if goes contrary to a
>> previous statement of his.
>>
>> Here is a recent example I was involved in
>> . He
>> originally said, in no uncertain terms, that `ETag`s will be supported when
>> an `embed.FS` is served over `net/http`. When it became clear that we don't
>> have a good design to make it happen, he admitted that it's unfortunate to
>> break that promise, but it's better than ending with a bad design.
>>
>> Even then, what you are saying doesn't make a lot of sense to me. If they
>> spend many years saying "we may add generics, if we find a design that
>> works", they seem to be perfectly set up to say "we didn't find one" to
>> their hypothetical employer (to be clear: Their employer doesn't care).
>> Like, if anything, what they said made it *more* plausible to just drop
>> generics altogether if they don't like the design.
>>
>> And, personally, I was in the room when the original contracts design was
>> first shown externally (at the GopherCon 2018 contributor summit) and I
>> talked to Ian and Robert (and others) about it. As far as I remember, they
>> were pretty open about their intent to let this be the last attempt, which
>> would either lead to a) generics landing in Go or b) generics actually
>> being rejected (in the sense of "changing the FAQ entry to say 'there will
>> never be generics in Go, because we've given up on finding a design that
>> works'").
>> That is, I'm not just working from the actual literal words of everyone
>> involved and every public statement any of them has ever made (which I
>> heard) but also from actually talking to them, in person, asking them
>> clarifying questions and interpreting their facial and body language.
>>
>> Of course, you don't have to believe me about any of this. But I can
>> categorically say that, as far as I can tell, your allegations that the
>> decision to add generics was pre-made is baseless.
>>
>>
>>> Like c'mon? Read what's written, not just words and punctuation
>>>
>>
>> As a rule, I try to avoid speculating about intent. It is hard enough to
>> interpret what people are actually directly saying, without speculating
>> about their internal monologue.
>> For example, when the Go team said "we may add generics, if we find a
>> design that works", you seemingly heard "we will add generics in the
>> future" and many others 

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

[Martin Schnabel]

hi jan,

i mostly share your perspective, but i may be a bit more optimistic.

the language as-is can be used to write horrible code already (i know 
because i did and still sometimes do). i am also sure that many will 
"abstract prematurely" before they see the light and come to reason (i 
will probably do the same, because it is part of the learning process).


but i also have trust in the go developers and community and they earned 
it. i am optimistically certain that the go standard library will not 
morph into an java-esque object-hell (as some others seem to fear), not 
only because many of use would nag and complain as we do, but because 
the developers set out with - or flocked to - this same ideal of less is 
more.


on the other hand are valid use-cases currently covered by code 
duplication, code generation, and empty interfaces. that would often 
gain from a clear type signature in addition to the existing docs or 
well vetted and battle tested data structure packages. how many project 
have their own tree implementations with subtle bugs, that nobody had 
time to properly review? how many ways are there to generate code? how 
many copy and pasted blocks of code have missed a change in the last 
line? i know i have read papers that quantify these types of errors (i 
think it was from someone involved in the findbugs project in java 
land). although i don't remember details, i know it was not pretty and 
mirrored my own experience reading and writing code.


my argument is, that if you do not use generics in your own code, but 
libraries used by you do, then you would still need to read the docs and 
learn the api - not a big difference from that perspective.


in the best case we add some type-safety, avoid obscure code generation 
scripts, error prone duplication and simplify some apis, all while 
making some code more comfortable - and other code even possible to write.


in the worst case we have some inappropriately popular libraries and 
frameworks that use generics, that we can decide to ignore as a company, 
group or individual. i would argue that we already have them here and 
there and they don't particularly rely on generics to exist.


i think that go is what it is, not because of the language spec, but 
because of the people that use it as to write code. nobody is perfect, 
but we have many brilliant people on this list with a whole lot of 
experience. i learned to trust the decisions of the go developer team 
and they earned my respect and gratitude. the reason anyone would freely 
choose go to write code is tied to the ideas, works and decisions of 
these some people. why would i stop having trust in them now?


On 13.03.21 14:09, Jan Mercl wrote:

On Sat, Mar 13, 2021 at 1:44 PM Martin Schnabel  wrote:


as far as i know there is no reason that anybody has to write code with
generics when they are available. therefor i really don't understand the
negative mails to this list.


That nonchalantly ignores that code is way more often read than written.

"Clever" use of preprocessing macros can make C code unreadable to
anyone other than its author unless learning the mindset behind the
macros. Symbols in the binary can have very little connection with the
symbols in the source code. Nice tar pit for transpiling/debugging
etc. I believe that's why Go does not have C macros or anything like
that.

The problem with generics is not the same, but it shares some of the
problems depicted above. The no more existing 1:1 symbol mapping is
the one I regret most by a wide margin. Goodbye easy and simple
grepping.

Good use of generics _will_ be good for Go, don't get me wrong about
this. But, when looking at random code in the wild, let me ask: What's
the ratio of poor vs good code one encounters at random?

And don't get me wrong the second time. I'm writing a lot of poor
code. Once I start using generics, my future self will be probably the
first one to curse me for that.



--
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/5880b473-4198-8c4a-fcb0-faa4a3c07f3d%40mb0.org.

Re: [go-nuts] Auto Make a named return map

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 6:14 PM Kevin Chadwick  wrote:

> Nonsense around performance is the reason that c sucks.
>

Lack of "nonsense around performance" is also the reason why many people
use Go instead of, say, Python.

I'm once again not sure what your objective is here. No one is trying to
argue that it is impossible to introduce semantics like you propose.
We are only trying to give you the reasons why that's currently not done.

You can always file a proposal to change the semantics. But I would
strongly suggest to a) get acquainted with the reasons given to you for why
maps work the way they do and b) have good answers ready when they come up
in the discussion. At least better answers than just dismissing them. If
your only response to someone saying that performance would suffer to much
if we had to allocate a map for every zero value is "that is performance
nonsense", my prediction is that your proposal would not get very accepted.

-- 
> 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/CANNfpqcW2yRLefLzc9h1Dqk7Hr5ASwmrfoLD-QxhxwA7nwEzXw%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/CAEkBMfH2oEhF4-e957Pip5B50c7fc0fE14njra0PHShqQ%2Bo6JQ%40mail.gmail.com.

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

[Space A.]

> Here is a recent example I was involved in
. He
originally said, in no uncertain terms, that `ETag`s will be supported when
an `embed.FS` is served over `net/http`.

There is a huge difference between generics and some regular questions like
`Etag` implementation, isn't it? In time, investments, "community demand",
commitments to upper management, etc
And Russ didn't write academic paper regarding it (before accepting
proposal in less than a month after it was published). =)

сб, 13 мар. 2021 г. в 19:39, Axel Wagner :

> On Sat, Mar 13, 2021 at 4:59 PM Space A.  wrote:
>
>> You are a smart guy, one of the smartest I have ever talked to. But it
>> looks like you somehow missed a very obvious thing. The people you
>> mentioned (and most of the so-called Go team) AFAIK are Google employees.
>> They work for a company and they are paid for the work they do.
>>
>
> I did not miss this.
>
>
>> If, as you say, they spend so much time, literally years, keep replying
>> "if we find an approach that gives value blablabla", how do you imagine
>> anyone responsible for the process at the end say smth like: "Alright guys,
>> after spending so many man-years we have few solutions, but we finally
>> realized that we were moving in wrong direction, so now we gonna be
>> dropping everything for the sake of better future of Go".
>>
>
> The person responsible for the process (if there is any one person) is
> Russ. I would have expect him to say that, if it was his opinion. He has a
> good track record of acknowledging the arguments on all sides of the
> process and committing to a decision - even it if goes contrary to a
> previous statement of his.
>
> Here is a recent example I was involved in
> . He
> originally said, in no uncertain terms, that `ETag`s will be supported when
> an `embed.FS` is served over `net/http`. When it became clear that we don't
> have a good design to make it happen, he admitted that it's unfortunate to
> break that promise, but it's better than ending with a bad design.
>
> Even then, what you are saying doesn't make a lot of sense to me. If they
> spend many years saying "we may add generics, if we find a design that
> works", they seem to be perfectly set up to say "we didn't find one" to
> their hypothetical employer (to be clear: Their employer doesn't care).
> Like, if anything, what they said made it *more* plausible to just drop
> generics altogether if they don't like the design.
>
> And, personally, I was in the room when the original contracts design was
> first shown externally (at the GopherCon 2018 contributor summit) and I
> talked to Ian and Robert (and others) about it. As far as I remember, they
> were pretty open about their intent to let this be the last attempt, which
> would either lead to a) generics landing in Go or b) generics actually
> being rejected (in the sense of "changing the FAQ entry to say 'there will
> never be generics in Go, because we've given up on finding a design that
> works'").
> That is, I'm not just working from the actual literal words of everyone
> involved and every public statement any of them has ever made (which I
> heard) but also from actually talking to them, in person, asking them
> clarifying questions and interpreting their facial and body language.
>
> Of course, you don't have to believe me about any of this. But I can
> categorically say that, as far as I can tell, your allegations that the
> decision to add generics was pre-made is baseless.
>
>
>> Like c'mon? Read what's written, not just words and punctuation
>>
>
> As a rule, I try to avoid speculating about intent. It is hard enough to
> interpret what people are actually directly saying, without speculating
> about their internal monologue.
> For example, when the Go team said "we may add generics, if we find a
> design that works", you seemingly heard "we will add generics in the
> future" and many others seemingly heard "we will never add generics". If we
> need to allow for different people hearing logically opposite messages from
> the same words, running a public project seems intractable.
>
> So, I really don't think we should take stock in anything but the actual
> words people said.
>
>
>
>> And I repeat, there wasn't a (public) question or discussion or anything
>> regarding should we drop this topic entirely.
>>
>
> That is not correct. The possibility of rejecting the proposal (and thus
> likely rejecting generics altogether) was always part of the conversation.
>
>
>>
>>
>>
>> сб, 13 мар. 2021 г. в 18:32, Axel Wagner :
>>
>>> On Sat, Mar 13, 2021 at 4:19 PM Space A.  wrote:
>>>
 > The discussion of whether or not generics will be added to Go has
 been going on for more than a decade.
 That's a lie. There has never been a question of "add it or not". It
 was always "we will add them" sooner or later.

>>>
>>> It is 

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On Sat, 13 Mar 2021, 17:00 Jan Mercl, <0xj...@gmail.com> wrote:

> On Sat, Mar 13, 2021 at 5:52 PM Kevin Chadwick 
> wrote:
>
> > Very little resources, unless the map is actually used and not for long.
> If you really need to control gos memory use, you need to preallocate
> arrays in a long standing manner anyway, not for maps though, as you can't
> delete without realloc.
>
> How did you figure out "very little resources"?
>
> What if there's a hot loop called a billion times doing something and
> returning a non zero map in the very last call? We're then talking
> about probably measurable slowdowns and gigabytes of garbage the
> collector has to deal with. Allocating "preemptively" might be
> sometimes a good idea, but that's a decision better left to humans as
> the compiler usually does not have enough info to make that decision
> right.
>
> Ignoring for now other techniques that might get the cost of this
> down. They exist.
>

If you are doing something a billion times then whatever you are doing is
more expensive than allocating a zero map. You can also avoid that return
if really necessary, which I doubt. It is right for optimisation steps to
increase, over run of the mill stuff.

Nonsense around performance is the reason that c sucks.

>

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

Re: [go-nuts] Auto Make a named return map

[Jan Mercl]

On Sat, Mar 13, 2021 at 5:52 PM Kevin Chadwick  wrote:

> Very little resources, unless the map is actually used and not for long. If 
> you really need to control gos memory use, you need to preallocate arrays in 
> a long standing manner anyway, not for maps though, as you can't delete 
> without realloc.

How did you figure out "very little resources"?

What if there's a hot loop called a billion times doing something and
returning a non zero map in the very last call? We're then talking
about probably measurable slowdowns and gigabytes of garbage the
collector has to deal with. Allocating "preemptively" might be
sometimes a good idea, but that's a decision better left to humans as
the compiler usually does not have enough info to make that decision
right.

Ignoring for now other techniques that might get the cost of this
down. They exist.

-- 
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-UVHC7BtSJQoq%3DLZ-h4%3D97f7nMnTw0TWT%3DH8ceT85dGkw%40mail.gmail.com.

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

[jake...@gmail.com]

This thread seems like it has devolved into a rehashing of the recent Generics, 
please go away! thread 
. 
This seems unfair to the original poster, who asked a simple , respectful, 
question in good faith, and seems to be satisfied with the answers he got. 
This tread is now so devolved that it would be hard for him to even ask a 
followup. I would respectfully suggest that those wanting to rehash the 
generic debate please continue on the  Generics, please go away! thread 
. 

[I will no longer be following this thread]

- Jake

On Friday, March 12, 2021 at 10:30:49 AM UTC-5 alex-coder wrote:

> Hello again, 
> I apologize for being so intrusive. 
> Where it is possible to read about the evaluations of labor and complexity 
> for 
> GO itself for different implementations to introduce generic in GO ?
>
> Thank you.
>

-- 
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/678e9dc6-7c68-4048-9708-6b137e0ce7cdn%40googlegroups.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On Sat, 13 Mar 2021, 15:05 Jan Mercl, <0xj...@gmail.com> wrote:

> On Fri, Mar 12, 2021 at 1:24 AM Kevin Chadwick 
> wrote:
>
> > Why doesn't go auto init or make an empty map for a named return to
> avoid the potential chance of a panic due to operating on a nil return?
>
> A non-zero value map value must be allocated. All well-known Go
> compilers allocate maps in heap. Allocating automagically a map that
> may end up never used is a waste of resources.
>

Very little resources, unless the map is actually used and not for long. If
you really need to control gos memory use, you need to preallocate arrays
in a long standing manner anyway, not for maps though, as you can't delete
without realloc.

>

-- 
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/CANNfpqceqbKAAoSu2ukCiydsn5ZZaorEN7vt_%3D1-T-wh0NrrSA%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 4:59 PM Space A.  wrote:

> You are a smart guy, one of the smartest I have ever talked to. But it
> looks like you somehow missed a very obvious thing. The people you
> mentioned (and most of the so-called Go team) AFAIK are Google employees.
> They work for a company and they are paid for the work they do.
>

I did not miss this.


> If, as you say, they spend so much time, literally years, keep replying
> "if we find an approach that gives value blablabla", how do you imagine
> anyone responsible for the process at the end say smth like: "Alright guys,
> after spending so many man-years we have few solutions, but we finally
> realized that we were moving in wrong direction, so now we gonna be
> dropping everything for the sake of better future of Go".
>

The person responsible for the process (if there is any one person) is
Russ. I would have expect him to say that, if it was his opinion. He has a
good track record of acknowledging the arguments on all sides of the
process and committing to a decision - even it if goes contrary to a
previous statement of his.

Here is a recent example I was involved in
. He
originally said, in no uncertain terms, that `ETag`s will be supported when
an `embed.FS` is served over `net/http`. When it became clear that we don't
have a good design to make it happen, he admitted that it's unfortunate to
break that promise, but it's better than ending with a bad design.

Even then, what you are saying doesn't make a lot of sense to me. If they
spend many years saying "we may add generics, if we find a design that
works", they seem to be perfectly set up to say "we didn't find one" to
their hypothetical employer (to be clear: Their employer doesn't care).
Like, if anything, what they said made it *more* plausible to just drop
generics altogether if they don't like the design.

And, personally, I was in the room when the original contracts design was
first shown externally (at the GopherCon 2018 contributor summit) and I
talked to Ian and Robert (and others) about it. As far as I remember, they
were pretty open about their intent to let this be the last attempt, which
would either lead to a) generics landing in Go or b) generics actually
being rejected (in the sense of "changing the FAQ entry to say 'there will
never be generics in Go, because we've given up on finding a design that
works'").
That is, I'm not just working from the actual literal words of everyone
involved and every public statement any of them has ever made (which I
heard) but also from actually talking to them, in person, asking them
clarifying questions and interpreting their facial and body language.

Of course, you don't have to believe me about any of this. But I can
categorically say that, as far as I can tell, your allegations that the
decision to add generics was pre-made is baseless.


> Like c'mon? Read what's written, not just words and punctuation
>

As a rule, I try to avoid speculating about intent. It is hard enough to
interpret what people are actually directly saying, without speculating
about their internal monologue.
For example, when the Go team said "we may add generics, if we find a
design that works", you seemingly heard "we will add generics in the
future" and many others seemingly heard "we will never add generics". If we
need to allow for different people hearing logically opposite messages from
the same words, running a public project seems intractable.

So, I really don't think we should take stock in anything but the actual
words people said.



> And I repeat, there wasn't a (public) question or discussion or anything
> regarding should we drop this topic entirely.
>

That is not correct. The possibility of rejecting the proposal (and thus
likely rejecting generics altogether) was always part of the conversation.


>
>
>
> сб, 13 мар. 2021 г. в 18:32, Axel Wagner :
>
>> On Sat, Mar 13, 2021 at 4:19 PM Space A.  wrote:
>>
>>> > The discussion of whether or not generics will be added to Go has been
>>> going on for more than a decade.
>>> That's a lie. There has never been a question of "add it or not". It was
>>> always "we will add them" sooner or later.
>>>
>>
>> It is somewhat amusing, though ultimately frustrating, that for ten years
>> people where misquoting the Go team to say they categorically reject
>> generics and now that a decision has been made to add them, they are being
>> misquoted as saying they will *definitely* add them, sooner or later.
>>
>> Both are not true. The stance has always been (demonstrably
>> 
>>  since
>> before the open sourcing of Go) that generics *may* come at some point, *if
>> they can figure out a way that gives value commensurate with their
>> complexity.* This messaging has been consistent.
>>
>> Even for this specific push (which started with the 

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

['Carla Pfaff' via golang-nuts]

On Saturday, 13 March 2021 at 15:31:05 UTC+1 Space A. wrote:

> There wasn't even a poll or anything. So the question of whether this 
> topic should be dropped completely (a lot of reasons why) has not been 
> thought out.
>

It was already explained that Go development is not driven by polls or 
surveys: 
https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/uGjSw4VGBgAJ
You were in the same thread, you should already know this.

-- 
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/609679d4-5155-43e8-8e2d-4abea18f0874n%40googlegroups.com.

Re: [go-nuts] Re: go get v git clone

[arthurwil...@gmail.com]

On Saturday, March 13, 2021 at 8:44:44 AM UTC-6 Jan Mercl wrote:

> On Sat, Mar 13, 2021 at 3:35 PM arthurwil...@gmail.com 
>  wrote: 
>
> > I just want to remove one thing go getted, not the entire cache. 
>
> For new features one can fill a proposal. If accepted, a follow-up 
> with the implementation CL is very nice


proprosal created https://github.com/golang/go/issues/44989
 

-- 
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/b2ead015-d8af-40e9-bfe7-d14ef4fc45f0n%40googlegroups.com.

Re: [go-nuts] Re: go get v git clone

[arthurwil...@gmail.com]

On Saturday, March 13, 2021 at 10:02:50 AM UTC-6 Jan Mercl wrote:

> On Sat, Mar 13, 2021 at 4:57 PM arthurwil...@gmail.com 
>  wrote: 
>
> > OK I'll try and figure out how to do that. What is a CL? 
>
> Change List. A patch against the repository that implements a feature, 
> fixes a bug etc.

Thanks Jan. I never heard CL jargon for patchset before.  I was wondering 
what does Craigs List have to do with this. 

-- 
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/b71c45ab-fb5c-4bf5-ac83-aef87b8ccd83n%40googlegroups.com.

Re: [go-nuts] Re: go get v git clone

[Jan Mercl]

On Sat, Mar 13, 2021 at 4:57 PM arthurwil...@gmail.com
 wrote:

> OK I'll try and figure out how to do that. What is a CL?

Change List. A patch against the repository that implements a feature,
fixes a bug etc.

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

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

[Jan Mercl]

On Sat, Mar 13, 2021 at 4:43 PM 'Axel Wagner' via golang-nuts
 wrote:
>
> I don't think it is useful to quibble over the definition of "ignore". When I 
> said it is demonstrably false that arguments have been ignored, I was 
> assuming what I perceive to be the common definition: "refuse to take notice 
> of or acknowledge; disregard intentionally. fail to consider (something 
> significant)". Under this definition, that statement implies that arguments 
> have not been given consideration, which would be false. They have been 
> considered, they just where not actually followed.
>
> If the statement was made using a different definition, that is fine - at 
> least we've gotten that clarification, then. I just did not want there to be 
> any misunderstandings about what actually happened. I didn't want to start a 
> debate about the English language.

I believe we are using the very same definition. What I'm failing at
is to explain the context.

I may invest in bitcoins, let's say.

One thing/opinion is that it may bring profit. The other is that I may
lose my money. When I decide to buy bitcoins as well if I decide to do
the opposite, I'm from that moment ignoring one of those opinions
because the decision has been made. I cannot keep considering both the
conflicting opinions. I _must_ from now on ignore one of them. Failing
to do that means no decision can be made.

Only the future can tell if that was a wise choice or not. And that's
exactly the same about Go and generics.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VBO%2BZc7HMs13KmN%2BcoUipaz%3DKSWv81VUbOKN7u8YOBeA%40mail.gmail.com.

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

[Space A.]

You are a smart guy, one of the smartest I have ever talked to. But it
looks like you somehow missed a very obvious thing. The people you
mentioned (and most of the so-called Go team) AFAIK are Google employees.
They work for a company and they are paid for the work they do. If, as you
say, they spend so much time, literally years, keep replying "if we find an
approach that gives value blablabla", how do you imagine anyone responsible
for the process at the end say smth like: "Alright guys, after spending so
many man-years we have few solutions, but we finally realized that we were
moving in wrong direction, so now we gonna be dropping everything for the
sake of better future of Go". Like c'mon? Read what's written, not just
words and punctuation, it was a one way ticket (and managers knew it), if
you start this process, start spending money and reporting man hours, you
know that it will land somewhere.

And I repeat, there wasn't a (public) question or discussion or anything
regarding should we drop this topic entirely.




сб, 13 мар. 2021 г. в 18:32, Axel Wagner :

> On Sat, Mar 13, 2021 at 4:19 PM Space A.  wrote:
>
>> > The discussion of whether or not generics will be added to Go has been
>> going on for more than a decade.
>> That's a lie. There has never been a question of "add it or not". It was
>> always "we will add them" sooner or later.
>>
>
> It is somewhat amusing, though ultimately frustrating, that for ten years
> people where misquoting the Go team to say they categorically reject
> generics and now that a decision has been made to add them, they are being
> misquoted as saying they will *definitely* add them, sooner or later.
>
> Both are not true. The stance has always been (demonstrably
> 
>  since
> before the open sourcing of Go) that generics *may* come at some point, *if
> they can figure out a way that gives value commensurate with their
> complexity.* This messaging has been consistent.
>
> Even for this specific push (which started with the contracts design)
> whenever Ian, Russ, Robert or anyone else on the Go team has been asked if
> generics *will* be added, the response has been a consistent "if we find
> an approach that gives value commensurate with their complexity. We are
> hopeful that this one does, but we will see". The first time anyone has
> actually said generics *will* be added was when the proposal was marked
> as accepted
> . And I
> wouldn't condone the use of "always" for "since about a month ago" any more
> than I would condone "they ignored arguments" to mean "they disagreed with
> arguments".
>
> If you insist on calling me a liar again, I would appreciate it if you
> could provide a source showing that anything of what I wrote here is
> untrue. Though, to be frank, I don't really think there is much point to
> this discussion either way - you have already demonstrated in the past that
> you are at best difficult to have a productive conversation with.
>
>
>>
>>
>>
>> сб, 13 мар. 2021 г. в 17:31, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> I want to re-iterate: The discussion of whether or not generics will be
>>> added to Go has been going on for more than a decade. All arguments from
>>> all sides have gotten fair consideration. A decision was reached.
>>>
>>> You might not agree with that decision. But saying that "there are no
>>> arguments" or that "arguments have been ignored" is simply and demonstrably
>>> false. I understand that it can be difficult to accept that other qualified
>>> people can come to different conclusions from you, based on the same
>>> available data. But it's simply going to happen. So please be mindful of
>>> how you communicate. And ideally, don't try to re-open this discussion with
>>> the same arguments that have already been heard. It took enough time and
>>> energy from everyone to reach a decision once.
>>>
>>> On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:
>>>
 HI Martin,

 as Jan already explained, you're not only writing code, you also
 reading it. And you have to understand what's written. At the same time
 you're not just coding in Go, you're using the whole ecosystem including
 libraries and tools. So the mantra "just don't use if you don't like'' does
 not work, every Go programmer will be forced to use generics, to read and
 at the end, to write that code.

 Second question you may ask - yes it will be overused, in fact in the
 very first year everything will be flooded with bad code. Because it's a
 new toy and biggest change to the language in years, because it's a "smart"
 way of doing things (we are mature programmers, aren't we?), because "type
 safety" and "performance" and so on so forth.





 сб, 13 мар. 2021 г. в 15:45, Martin 

Re: [go-nuts] Re: go get v git clone

[arthurwil...@gmail.com]

On Saturday, March 13, 2021 at 8:44:44 AM UTC-6 Jan Mercl wrote:

> On Sat, Mar 13, 2021 at 3:35 PM arthurwil...@gmail.com 
>  wrote: 
>
> > I just want to remove one thing go getted, not the entire cache. 
>
> For new features one can fill a proposal. If accepted, a follow-up 
> with the implementation CL is very nice


OK I'll try and figure out how to do that. What is a CL?  

-- 
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/eedd8c55-73e2-44e4-8be0-9d67c4ed2f6an%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

I don't think it is useful to quibble over the definition of "ignore". When
I said it is demonstrably false that arguments have been ignored, I was
assuming what I perceive to be the common definition: "refuse to take
notice of or acknowledge; disregard intentionally. fail to consider
(something significant)". Under this definition, that statement implies
that arguments have not been given consideration, which would be false.
They have been *considered*, they just where not actually followed.

If the statement was made using a different definition, that is fine - at
least we've gotten that clarification, then. I just did not want there to
be any misunderstandings about what actually happened. I didn't want to
start a debate about the English language.

On Sat, Mar 13, 2021 at 4:35 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Sat, Mar 13, 2021 at 4:18 PM Bruno Albuquerque  wrote:
>
> > FWIIW, I also agree that "ignore" makes no sense here. You might listen
> and think about several opinions/options and conclude that one of them is
> the best one. This does not mean you ignored all the others.
>
> You do not ignore the differing opinions before you make the decision.
> The decision makes them ignored because you cannot not ignore them. If
> you would still consider them you cannot make the decision.
>
> The decision outcome of whether to adopt generics or not adopt
> generics is _binary_, hence why I knowingly use "ignore" and it means
> exactly what it says. Kinda Sophie's choice, if you will.
>
> The process of reaching the decision, OTOH, does not ignore
> arguments/opinions. That I've never said and I don't know why it would
> be inferred by anyone.
>
> Last attempt to clarify: You cannot please all the parties at the same
> time with this kind of decision, one must realize/admit that's a
> non-goal. However, from the POV of someone from the "losing" side,
> his/her argument can be legitimely, but subjectively perceived as
> ignored - even when it was not actually ignored during the process.
>

-- 
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/CAEkBMfG8NMR0WCq_o%3D%2BENKqa3%3DEODzfvF0O7Nv-ZHDDGiU4%2BZA%40mail.gmail.com.

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

[Jan Mercl]

On Sat, Mar 13, 2021 at 4:18 PM Bruno Albuquerque  wrote:

> FWIIW, I also agree that "ignore" makes no sense here. You might listen and 
> think about several opinions/options and conclude that one of them is the 
> best one. This does not mean you ignored all the others.

You do not ignore the differing opinions before you make the decision.
The decision makes them ignored because you cannot not ignore them. If
you would still consider them you cannot make the decision.

The decision outcome of whether to adopt generics or not adopt
generics is _binary_, hence why I knowingly use "ignore" and it means
exactly what it says. Kinda Sophie's choice, if you will.

The process of reaching the decision, OTOH, does not ignore
arguments/opinions. That I've never said and I don't know why it would
be inferred by anyone.

Last attempt to clarify: You cannot please all the parties at the same
time with this kind of decision, one must realize/admit that's a
non-goal. However, from the POV of someone from the "losing" side,
his/her argument can be legitimely, but subjectively perceived as
ignored - even when it was not actually ignored during the process.

-- 
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-U72Uk9xU3hppRsyZiGT_YUYOMRjKkeXsczNbCY%2B2H-oQ%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 4:19 PM Space A.  wrote:

> > The discussion of whether or not generics will be added to Go has been
> going on for more than a decade.
> That's a lie. There has never been a question of "add it or not". It was
> always "we will add them" sooner or later.
>

It is somewhat amusing, though ultimately frustrating, that for ten years
people where misquoting the Go team to say they categorically reject
generics and now that a decision has been made to add them, they are being
misquoted as saying they will *definitely* add them, sooner or later.

Both are not true. The stance has always been (demonstrably

since
before the open sourcing of Go) that generics *may* come at some point, *if
they can figure out a way that gives value commensurate with their
complexity.* This messaging has been consistent.

Even for this specific push (which started with the contracts design)
whenever Ian, Russ, Robert or anyone else on the Go team has been asked if
generics *will* be added, the response has been a consistent "if we find an
approach that gives value commensurate with their complexity. We are
hopeful that this one does, but we will see". The first time anyone has
actually said generics *will* be added was when the proposal was marked as
accepted .
And I wouldn't condone the use of "always" for "since about a month ago"
any more than I would condone "they ignored arguments" to mean "they
disagreed with arguments".

If you insist on calling me a liar again, I would appreciate it if you
could provide a source showing that anything of what I wrote here is
untrue. Though, to be frank, I don't really think there is much point to
this discussion either way - you have already demonstrated in the past that
you are at best difficult to have a productive conversation with.


>
>
>
> сб, 13 мар. 2021 г. в 17:31, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com>:
>
>> I want to re-iterate: The discussion of whether or not generics will be
>> added to Go has been going on for more than a decade. All arguments from
>> all sides have gotten fair consideration. A decision was reached.
>>
>> You might not agree with that decision. But saying that "there are no
>> arguments" or that "arguments have been ignored" is simply and demonstrably
>> false. I understand that it can be difficult to accept that other qualified
>> people can come to different conclusions from you, based on the same
>> available data. But it's simply going to happen. So please be mindful of
>> how you communicate. And ideally, don't try to re-open this discussion with
>> the same arguments that have already been heard. It took enough time and
>> energy from everyone to reach a decision once.
>>
>> On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:
>>
>>> HI Martin,
>>>
>>> as Jan already explained, you're not only writing code, you also reading
>>> it. And you have to understand what's written. At the same time you're not
>>> just coding in Go, you're using the whole ecosystem including libraries and
>>> tools. So the mantra "just don't use if you don't like'' does not work,
>>> every Go programmer will be forced to use generics, to read and at the end,
>>> to write that code.
>>>
>>> Second question you may ask - yes it will be overused, in fact in the
>>> very first year everything will be flooded with bad code. Because it's a
>>> new toy and biggest change to the language in years, because it's a "smart"
>>> way of doing things (we are mature programmers, aren't we?), because "type
>>> safety" and "performance" and so on so forth.
>>>
>>>
>>>
>>>
>>>
>>> сб, 13 мар. 2021 г. в 15:45, Martin Schnabel :
>>>
 (sorry space a, i didn't reply to list)

 hi alex and space a.

 as far as i know there is no reason that anybody has to write code with
 generics when they are available. therefor i really don't understand
 the
 negative mails to this list.

 do you also want others not to use them? how would that help you? could
 you please explain to me your personal gain if generics are not added
 to
 go and not available to me and other users? many users have valid use
 cases for generics and custom code generation to deal with them now.

 i personally never had a reason to use imaginary numbers in go, they
 are
 however part of the language as literals and accompanied by special
 built-ins. should i care, do you?

 please explain

 On 13.03.21 12:34, Space A. wrote:
 > There is no rationale. They decided, and they implemented. No one
 from
 > Go team ever took the argument against it seriously because
 "community"
 > demands, blabla. And because Russ Cox with friends written an
 academic
 > paper so this is now a question of pure science. Write your own 

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

[Space A.]

> The discussion of whether or not generics will be added to Go has been
going on for more than a decade.
That's a lie. There has never been a question of "add it or not". It was
always "we will add them" sooner or later.




сб, 13 мар. 2021 г. в 17:31, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> I want to re-iterate: The discussion of whether or not generics will be
> added to Go has been going on for more than a decade. All arguments from
> all sides have gotten fair consideration. A decision was reached.
>
> You might not agree with that decision. But saying that "there are no
> arguments" or that "arguments have been ignored" is simply and demonstrably
> false. I understand that it can be difficult to accept that other qualified
> people can come to different conclusions from you, based on the same
> available data. But it's simply going to happen. So please be mindful of
> how you communicate. And ideally, don't try to re-open this discussion with
> the same arguments that have already been heard. It took enough time and
> energy from everyone to reach a decision once.
>
> On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:
>
>> HI Martin,
>>
>> as Jan already explained, you're not only writing code, you also reading
>> it. And you have to understand what's written. At the same time you're not
>> just coding in Go, you're using the whole ecosystem including libraries and
>> tools. So the mantra "just don't use if you don't like'' does not work,
>> every Go programmer will be forced to use generics, to read and at the end,
>> to write that code.
>>
>> Second question you may ask - yes it will be overused, in fact in the
>> very first year everything will be flooded with bad code. Because it's a
>> new toy and biggest change to the language in years, because it's a "smart"
>> way of doing things (we are mature programmers, aren't we?), because "type
>> safety" and "performance" and so on so forth.
>>
>>
>>
>>
>>
>> сб, 13 мар. 2021 г. в 15:45, Martin Schnabel :
>>
>>> (sorry space a, i didn't reply to list)
>>>
>>> hi alex and space a.
>>>
>>> as far as i know there is no reason that anybody has to write code with
>>> generics when they are available. therefor i really don't understand the
>>> negative mails to this list.
>>>
>>> do you also want others not to use them? how would that help you? could
>>> you please explain to me your personal gain if generics are not added to
>>> go and not available to me and other users? many users have valid use
>>> cases for generics and custom code generation to deal with them now.
>>>
>>> i personally never had a reason to use imaginary numbers in go, they are
>>> however part of the language as literals and accompanied by special
>>> built-ins. should i care, do you?
>>>
>>> please explain
>>>
>>> On 13.03.21 12:34, Space A. wrote:
>>> > There is no rationale. They decided, and they implemented. No one from
>>> > Go team ever took the argument against it seriously because
>>> "community"
>>> > demands, blabla. And because Russ Cox with friends written an academic
>>> > paper so this is now a question of pure science. Write your own and
>>> they
>>> > could listen. (No)
>>> >
>>> > суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:
>>> >
>>> > Hello,
>>> >
>>> > Thank you for the answers.
>>> > Now I have something to read. :-)
>>> >
>>> > So, sorry for my English.
>>> > Personally, I would add a dynamic dispatching into GO
>>> > and left language without generic in order to keep simplicity for
>>> GO
>>> > and to make life of the applied programmers easier :-)
>>> >
>>> > What I'm looking for is the rationale behind the technical decision
>>> > to understand why the sort of decision has been taken.
>>> >
>>> > Thank you again for the answers.
>>> >
>>> > On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor
>>> wrote:
>>> >
>>> > On Fri, Mar 12, 2021 at 7:31 AM alex-coder >> >
>>> > wrote:
>>> >  >
>>> >  > Hello again,
>>> >  > I apologize for being so intrusive.
>>> >  > Where it is possible to read about the evaluations of labor
>>> > and complexity for
>>> >  > GO itself for different implementations to introduce generic
>>> > in GO ?
>>> >
>>> > LIke others, I'm not quite sure what you are asking, but
>>> perhaps
>>> > you
>>> > want to look at
>>> >
>>> >
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>>> > <
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>>> >
>>> >
>>> >
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
>>> > <
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
>>> >
>>> >
>>> >
>>> 

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

[Bruno Albuquerque]

FWIIW, I also agree that "ignore" makes no sense here. You might listen and
think about several opinions/options and conclude that one of them is the
best one. This does not mean you ignored all the others.


On Sat, Mar 13, 2021 at 7:06 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Sat, Mar 13, 2021 at 4:00 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Sat, Mar 13, 2021 at 3:53 PM Axel Wagner
>>  wrote:
>>
>> > We have different interpretations of "ignore". To me, "ignore" means
>> "be unaware of or pretend they don't exist".
>> > You seem to use it as "disagree about their validity or the weight they
>> are given in the decision". That seems questionable to me.
>>
>> No, that's not what I think. Opinions are not objectively measurable
>> and are thus in principle equal. Qualified people (not sure how to
>> define them), beginners, whoever. The decision maker assigned
>> subjective weights to the differing opinions and, again, that's just
>> fine and the only way to get the decision.
>>
>
> I agree. I still believe that using "ignore" is a misuse of how the word
> is commonly understood. But as long as it's clear that what you describe
> here is demonstrably what has happened, I guess it does not matter what
> word you prefer to use for that.
>
>
>>
>> In no way that means my opinions are better or worse than yours or
>> anyone else's. They just differ and there's nothing wrong about that
>> either.
>>
>
>
>
> --
> 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/CAEkBMfEfpAvm6zPjGKqVGVfDSPPbVwpRdz3sn4njrBgZAG2sew%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/CAEd86TyVXu4JQRGys8c8eH2G6HHJNSFEB%3DTobbk9D103G_NMqQ%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 4:00 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Sat, Mar 13, 2021 at 3:53 PM Axel Wagner
>  wrote:
>
> > We have different interpretations of "ignore". To me, "ignore" means "be
> unaware of or pretend they don't exist".
> > You seem to use it as "disagree about their validity or the weight they
> are given in the decision". That seems questionable to me.
>
> No, that's not what I think. Opinions are not objectively measurable
> and are thus in principle equal. Qualified people (not sure how to
> define them), beginners, whoever. The decision maker assigned
> subjective weights to the differing opinions and, again, that's just
> fine and the only way to get the decision.
>

I agree. I still believe that using "ignore" is a misuse of how the word is
commonly understood. But as long as it's clear that what you describe here
is demonstrably what has happened, I guess it does not matter what word you
prefer to use for that.


>
> In no way that means my opinions are better or worse than yours or
> anyone else's. They just differ and there's nothing wrong about that
> either.
>

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

Re: [go-nuts] Auto Make a named return map

[Jan Mercl]

On Fri, Mar 12, 2021 at 1:24 AM Kevin Chadwick  wrote:

> Why doesn't go auto init or make an empty map for a named return to avoid the 
> potential chance of a panic due to operating on a nil return?

A non-zero value map value must be allocated. All well-known Go
compilers allocate maps in heap. Allocating automagically a map that
may end up never used is a waste of resources.

-- 
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-UuFkAK0PUVZyc2jj4vUWNecA0sjCCHj-nK4Y_KT8YnBw%40mail.gmail.com.

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

[Jan Mercl]

On Sat, Mar 13, 2021 at 3:53 PM Axel Wagner
 wrote:

> We have different interpretations of "ignore". To me, "ignore" means "be 
> unaware of or pretend they don't exist".
> You seem to use it as "disagree about their validity or the weight they are 
> given in the decision". That seems questionable to me.

No, that's not what I think. Opinions are not objectively measurable
and are thus in principle equal. Qualified people (not sure how to
define them), beginners, whoever. The decision maker assigned
subjective weights to the differing opinions and, again, that's just
fine and the only way to get the decision.

In no way that means my opinions are better or worse than yours or
anyone else's. They just differ and there's nothing wrong about that
either.

-- 
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-Up%2Bo6R%3Dc_wjJhMyoN90BeNo2_Vbny2yGwPCeL44XVtJg%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 3:42 PM Jan Mercl <0xj...@gmail.com> wrote:

> Not false at all. If you have more than one party, differing in
> conflicting opinions on a subject and you make a final decision, you
> _must_ ignore at least arguments of one of the parties.


We have different interpretations of "ignore". To me, "ignore" means "be
unaware of or pretend they don't exist".
You seem to use it as "disagree about their validity or the weight they are
given in the decision". That seems questionable to me.

That's nothing
> wrong. It's the only way to make the decision happen.
>
> Would the decision have been to not introduce generics in Go, the
> arguments of people advocating generics would have to be - in the end
> - ignored.
>
> > So please be mindful of how you communicate.
>
> I would like to ask for the same - but not only from S.A.
>

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

Re: [go-nuts] Auto Make a named return map

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 3:22 PM Kevin Chadwick  wrote:

> In that case, as far as I understand it, which may be a limited
> understanding. I
> disagree with this being a useful property.


That is your prerogative. I was simply trying to explain why maps work the
way they do (and ISTM that if you want to change the way they work, you
should really try to understand why they work this way first). I wasn't
trying to convince you it's a good thing.


> Replacing a map of 0 length with one
> that is larger is not a problem. Checking the length of a map also makes
> more
> sense to me than nil.
>

Neither of these seems relevant. I agree that if the zero value of a map
was a non-nil empty map, that you could check the length to see if it is
empty by checking it's length. And that comparison to nil would likely be
obsolete (though, again, slices work that way and still have a separate nil
value and that doesn't seem to bother people).
I also don't think anyone disagrees that it would be nice to have the zero
value of a map be simply an empty map (that you can write to).

Neither of these have anything to do with whether or not the zero value is
represented by 0-bytes, though.
There are ways to get these properties that would leave the zero value as
0-bytes - for example, a linked list of key-value pairs that uses an
append-like builtin.
There are ways that get these properties while destroying the property that
the zero value is 0-bytes - for example your suggestion of implicitly
initializing maps using `make`.

What you describe are the language-level semantics of maps - can a
programmer compare them to nil, or can they write to it. But this property
is not about semantics, it's an implementation restriction. It's just that
we can't find a way to implement better semantics, without losing this
property or incurring some other significant downsides.

Though I personally do not agree with Nulls in JSON either. An intentional
> empty
> is always more useful. Similarly, nulls when permitted always being
> unintentional is more useful in my eyes.
>
> --
> 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/b962ffa5-0201-bffb-90c0-8f6de262d9a7%40gmail.com
> .
>

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

Re: [go-nuts] Re: go get v git clone

[Jan Mercl]

On Sat, Mar 13, 2021 at 3:35 PM arthurwil...@gmail.com
 wrote:

> I just want to remove one thing go getted, not the entire cache.

For new features one can fill a proposal. If accepted, a follow-up
with the implementation CL is very nice

-- 
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-XsHzM%3D%3DNq2v%3DN7hurgsVbk5tQQQxeqREW6ET%2BXFQqXsA%40mail.gmail.com.

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

[alex-coder]

Hello again.

Looks like I have the several problems. :-)
First one is my English, it seems my written explanations not properly 
describe my wishes.
Next one is that I have missed the already closed discussion and include my 
opinion in context
where it would be unnecessary.

So, of course, of course the initial point to include generic into GO was 
the customer wishes.
And moreover possible I should change my opinion after reading all the 
references provided. :-)

Thank all of you.

On Saturday, March 13, 2021 at 5:31:50 PM UTC+3 axel.wa...@googlemail.com 
wrote:

> I want to re-iterate: The discussion of whether or not generics will be 
> added to Go has been going on for more than a decade. All arguments from 
> all sides have gotten fair consideration. A decision was reached.
>
> You might not agree with that decision. But saying that "there are no 
> arguments" or that "arguments have been ignored" is simply and demonstrably 
> false. I understand that it can be difficult to accept that other qualified 
> people can come to different conclusions from you, based on the same 
> available data. But it's simply going to happen. So please be mindful of 
> how you communicate. And ideally, don't try to re-open this discussion with 
> the same arguments that have already been heard. It took enough time and 
> energy from everyone to reach a decision once.
>
> On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:
>
>> HI Martin,
>>
>> as Jan already explained, you're not only writing code, you also reading 
>> it. And you have to understand what's written. At the same time you're not 
>> just coding in Go, you're using the whole ecosystem including libraries and 
>> tools. So the mantra "just don't use if you don't like'' does not work, 
>> every Go programmer will be forced to use generics, to read and at the end, 
>> to write that code. 
>>
>> Second question you may ask - yes it will be overused, in fact in the 
>> very first year everything will be flooded with bad code. Because it's a 
>> new toy and biggest change to the language in years, because it's a "smart" 
>> way of doing things (we are mature programmers, aren't we?), because "type 
>> safety" and "performance" and so on so forth. 
>>
>>
>>
>>
>>
>> сб, 13 мар. 2021 г. в 15:45, Martin Schnabel :
>>
>>> (sorry space a, i didn't reply to list)
>>>
>>> hi alex and space a.
>>>
>>> as far as i know there is no reason that anybody has to write code with 
>>> generics when they are available. therefor i really don't understand the 
>>> negative mails to this list.
>>>
>>> do you also want others not to use them? how would that help you? could 
>>> you please explain to me your personal gain if generics are not added to 
>>> go and not available to me and other users? many users have valid use 
>>> cases for generics and custom code generation to deal with them now.
>>>
>>> i personally never had a reason to use imaginary numbers in go, they are 
>>> however part of the language as literals and accompanied by special 
>>> built-ins. should i care, do you?
>>>
>>> please explain
>>>
>>> On 13.03.21 12:34, Space A. wrote:
>>> > There is no rationale. They decided, and they implemented. No one from 
>>> > Go team ever took the argument against it seriously because 
>>> "community" 
>>> > demands, blabla. And because Russ Cox with friends written an academic 
>>> > paper so this is now a question of pure science. Write your own and 
>>> they 
>>> > could listen. (No)
>>> > 
>>> > суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:
>>> > 
>>> > Hello,
>>> > 
>>> > Thank you for the answers.
>>> > Now I have something to read. :-)
>>> > 
>>> > So, sorry for my English.
>>> > Personally, I would add a dynamic dispatching into GO
>>> > and left language without generic in order to keep simplicity for 
>>> GO
>>> > and to make life of the applied programmers easier :-)
>>> > 
>>> > What I'm looking for is the rationale behind the technical decision
>>> > to understand why the sort of decision has been taken.
>>> > 
>>> > Thank you again for the answers.
>>> > 
>>> > On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor 
>>> wrote:
>>> > 
>>> > On Fri, Mar 12, 2021 at 7:31 AM alex-coder >> >
>>> > wrote:
>>> >  >
>>> >  > Hello again,
>>> >  > I apologize for being so intrusive.
>>> >  > Where it is possible to read about the evaluations of labor
>>> > and complexity for
>>> >  > GO itself for different implementations to introduce generic
>>> > in GO ?
>>> > 
>>> > LIke others, I'm not quite sure what you are asking, but 
>>> perhaps
>>> > you
>>> > want to look at
>>> > 
>>> > 
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>>> > <
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md

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

[Jan Mercl]

On Sat, Mar 13, 2021 at 3:31 PM 'Axel Wagner' via golang-nuts
 wrote:

> I want to re-iterate: The discussion of whether or not generics will be added 
> to Go has been going on for more than a decade. All arguments from all sides 
> have gotten fair consideration. A decision was reached.
>
> You might not agree with that decision. But saying that "there are no 
> arguments" or that "arguments have been ignored" is simply and demonstrably 
> false.

Not false at all. If you have more than one party, differing in
conflicting opinions on a subject and you make a final decision, you
_must_ ignore at least arguments of one of the parties. That's nothing
wrong. It's the only way to make the decision happen.

Would the decision have been to not introduce generics in Go, the
arguments of people advocating generics would have to be - in the end
- ignored.

> So please be mindful of how you communicate.

I would like to ask for the same - but not only from S.A.

-- 
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-U22r%3DA%2BHr6Df2LiC%2Biv0cVGAN_%3DwsgHuDX1%2BgUMjCxOw%40mail.gmail.com.

[go-nuts] Re: go get v git clone

[arthurwil...@gmail.com]

On Friday, March 12, 2021 at 11:13:44 PM UTC-6 Carla Pfaff wrote:

> You use git clone. Go get is for adding a dependency to a project.
>
> Also how do I delete something I go getted?
>>
>  
> ~/go/pkg/mod is just a local cache, nothing you work in. You can clear the 
> whole module cache with go clean -modcache
>

I just want to remove one thing go getted, not the entire cache. 

-- 
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/33d704a3-27e9-4000-8d30-0ee6bab7dbd4n%40googlegroups.com.

[go-nuts] How to call a C `writev` styled library api via cgo without allocation and copying of the whole byte slice vector?

[rmfr]

Say here is a C api like `ssize_t writev(const struct iovec *iov, int 
iovcnt)` which the definition of iovec is like below:

```
struct iovec {
 uint8_t   *Base;  /* Base address. */
 uint64_t Len;/* Length. */
 };
```

For C api which like `ssize_t write(const void *buf, size_t nbyte)`, the 
solution would be quite straight forward:

```
bs := make([]byte, 1024*1024*512)
// without extra memory allocation and copying of the whole input byte 
slice :-D
rc := C.write(unsafe.Pointer([0]), C.int(len(bs)))
```

But how to call C `writev` style API without extra memory allocation or 
copying of the whole byte slice vector?

```
bsv := make([][]byte, 1024)
for i := range bsv{
bsv[i] = make([]byte, 5*1024*(rand.Intn(i)+1))
}
// assuming that allocation of a iovec array is acceptable
// but allocation and copying of all bsv[x] byte slice member is 
unacceptable
//
iovec := make([]syscall.Iovec, len(bsv))
for i := range bsv {
bs := bsv[i]
if len(bs) > 0 {
iovec[i].Base = unsafe.Pointer([0])
iovec[i].Len = uint64(len(bs))
}
}
//
// rc := C.writev( /* how? :-( */)
rc := C.writev(unsafe.Pointer([0]), C.int(len(iovec))) // Does this 
code is right and safe?
```

Does the code above is right?

I have read cgo's docs carefully, and here is a constraint from 
https://golang.org/cmd/cgo/#hdr-Passing_pointers:

> Go code may pass a Go pointer to C provided the Go memory to which it 
points does not contain any Go pointers.

If the Go memory pointed by `unsafe.Pointer([0])` contains pointer 
which points to these byte slice members of bsv, so it would be a 
*violation* of the cgo constraint above. And that means you could not call 
C `writev` style API without allocation and copying of the whole vector.

Please correct me if I get something wrong. Thanks a lot :-D

-- 
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/1638feb7-3f3d-4061-ad70-a031839b7542n%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

I want to re-iterate: The discussion of whether or not generics will be
added to Go has been going on for more than a decade. All arguments from
all sides have gotten fair consideration. A decision was reached.

You might not agree with that decision. But saying that "there are no
arguments" or that "arguments have been ignored" is simply and demonstrably
false. I understand that it can be difficult to accept that other qualified
people can come to different conclusions from you, based on the same
available data. But it's simply going to happen. So please be mindful of
how you communicate. And ideally, don't try to re-open this discussion with
the same arguments that have already been heard. It took enough time and
energy from everyone to reach a decision once.

On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:

> HI Martin,
>
> as Jan already explained, you're not only writing code, you also reading
> it. And you have to understand what's written. At the same time you're not
> just coding in Go, you're using the whole ecosystem including libraries and
> tools. So the mantra "just don't use if you don't like'' does not work,
> every Go programmer will be forced to use generics, to read and at the end,
> to write that code.
>
> Second question you may ask - yes it will be overused, in fact in the very
> first year everything will be flooded with bad code. Because it's a new toy
> and biggest change to the language in years, because it's a "smart" way of
> doing things (we are mature programmers, aren't we?), because "type safety"
> and "performance" and so on so forth.
>
>
>
>
>
> сб, 13 мар. 2021 г. в 15:45, Martin Schnabel :
>
>> (sorry space a, i didn't reply to list)
>>
>> hi alex and space a.
>>
>> as far as i know there is no reason that anybody has to write code with
>> generics when they are available. therefor i really don't understand the
>> negative mails to this list.
>>
>> do you also want others not to use them? how would that help you? could
>> you please explain to me your personal gain if generics are not added to
>> go and not available to me and other users? many users have valid use
>> cases for generics and custom code generation to deal with them now.
>>
>> i personally never had a reason to use imaginary numbers in go, they are
>> however part of the language as literals and accompanied by special
>> built-ins. should i care, do you?
>>
>> please explain
>>
>> On 13.03.21 12:34, Space A. wrote:
>> > There is no rationale. They decided, and they implemented. No one from
>> > Go team ever took the argument against it seriously because "community"
>> > demands, blabla. And because Russ Cox with friends written an academic
>> > paper so this is now a question of pure science. Write your own and
>> they
>> > could listen. (No)
>> >
>> > суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:
>> >
>> > Hello,
>> >
>> > Thank you for the answers.
>> > Now I have something to read. :-)
>> >
>> > So, sorry for my English.
>> > Personally, I would add a dynamic dispatching into GO
>> > and left language without generic in order to keep simplicity for GO
>> > and to make life of the applied programmers easier :-)
>> >
>> > What I'm looking for is the rationale behind the technical decision
>> > to understand why the sort of decision has been taken.
>> >
>> > Thank you again for the answers.
>> >
>> > On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor
>> wrote:
>> >
>> > On Fri, Mar 12, 2021 at 7:31 AM alex-coder 
>> > wrote:
>> >  >
>> >  > Hello again,
>> >  > I apologize for being so intrusive.
>> >  > Where it is possible to read about the evaluations of labor
>> > and complexity for
>> >  > GO itself for different implementations to introduce generic
>> > in GO ?
>> >
>> > LIke others, I'm not quite sure what you are asking, but perhaps
>> > you
>> > want to look at
>> >
>> >
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>> > <
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>> >
>> >
>> >
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
>> > <
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
>> >
>> >
>> >
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
>> > <
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
>> >
>> >
>> >
>> > 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 

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

[Space A.]

> There have been many discussions and debates about generics (first as to
whether they should be added at all
That's simply not true, there have never been raised a discussion of
whether they should be added or not. There wasn't even a poll or anything.
So the question of whether this topic should be dropped completely (a lot
of reasons why) has not been thought out.

> If you are not okay with generics, so be it, but one - don't manipulate
facts
Where did I manipulate?

> stop being that dogmatic and negative here, please, for the sake of all
of us
Why do you tell me what to do, what to say, or what to feel?


сб, 13 мар. 2021 г. в 16:17, Levieux Michel :

> It's not because the arguments didn't appear numerous / convincing enough
> that they were not taken into account. You are just stating your incapacity
> to accept that you might be wrong, as anyone can, and that you cannot
> discuss something (clearly because you don't want to *discuss*, you want
> people to take everything you say for granted and absolute truth).
>
> There have been many discussions and debates about generics (first as to
> whether they should be added at all, then as to how they should be
> implemented if ever they were), different proposals that were rejected
> after lots and lots of arguments on both + and - minus sides, up to where
> we are now.
>
> If you are not okay with generics, so be it, but one - don't manipulate
> facts, and second - stop being that dogmatic and negative here, please, for
> the sake of all of us.
>
> In advance, thanks for your time and consideration.
>
> Cheers.
>
> Le sam. 13 mars 2021 à 12:34, Space A.  a écrit :
>
>> There is no rationale. They decided, and they implemented. No one from Go
>> team ever took the argument against it seriously because "community"
>> demands, blabla. And because Russ Cox with friends written an academic
>> paper so this is now a question of pure science. Write your own and they
>> could listen. (No)
>>
>> суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:
>>
>>> Hello,
>>>
>>> Thank you for the answers.
>>> Now I have something to read. :-)
>>>
>>> So, sorry for my English.
>>> Personally, I would add a dynamic dispatching into GO
>>> and left language without generic in order to keep simplicity for GO
>>> and to make life of the applied programmers easier :-)
>>>
>>> What I'm looking for is the rationale behind the technical decision
>>> to understand why the sort of decision has been taken.
>>>
>>> Thank you again for the answers.
>>>
>>> On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor wrote:
>>>
 On Fri, Mar 12, 2021 at 7:31 AM alex-coder  wrote:
 >
 > Hello again,
 > I apologize for being so intrusive.
 > Where it is possible to read about the evaluations of labor and
 complexity for
 > GO itself for different implementations to introduce generic in GO ?

 LIke others, I'm not quite sure what you are asking, but perhaps you
 want to look at


 https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md

 https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md

 https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md

 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/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%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/CADKwOTf_DAOcMPp5smAtLZbAwEt5P7TpfhEpBeEWuYgBnRHy1w%40mail.gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/13/21 1:40 PM, Axel Wagner wrote:
> 
> Compiler complication is not the concern. It would be easy to build any of the
> suggested semantics into the language. It is just that none of the suggestions
> so far seem clearly better - that is, they all come with their own downsides.
> 

OK, I really meant, GC complexity, etc. Perhaps it does not affect that either.

> The concern about the zero value consisting of 0 bytes is more about
> performance. As long as that's the case, initialization is very close to free.
> As soon as the zero value becomes some non-zero bytes, they have to be written
> and that incurs a cost. 
> 
> When we say "the zero value of a map should only contain zero bytes", what we
> mean is that if I write
> var m map[int]int
> that should a) reserve some memory for m (currently that's as many bytes as a
> pointer needs) and b) those bytes should be zero after that.
> If "make was called implicitly" or anything like that, those bytes wouldn't be
> zero anymore - they would contain a pointer to an allocated map header.
> 
> It's as simple as that. You might feel that preserving that property is not
> important or less important than having a useful zero value for maps. That's
> fine. But that's the property Ian is talking about.


In that case, as far as I understand it, which may be a limited understanding. I
disagree with this being a useful property. Replacing a map of 0 length with one
that is larger is not a problem. Checking the length of a map also makes more
sense to me than nil.

Though I personally do not agree with Nulls in JSON either. An intentional empty
is always more useful. Similarly, nulls when permitted always being
unintentional is more useful in my eyes.

-- 
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/b962ffa5-0201-bffb-90c0-8f6de262d9a7%40gmail.com.

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

[Space A.]

HI Martin,

as Jan already explained, you're not only writing code, you also reading
it. And you have to understand what's written. At the same time you're not
just coding in Go, you're using the whole ecosystem including libraries and
tools. So the mantra "just don't use if you don't like'' does not work,
every Go programmer will be forced to use generics, to read and at the end,
to write that code.

Second question you may ask - yes it will be overused, in fact in the very
first year everything will be flooded with bad code. Because it's a new toy
and biggest change to the language in years, because it's a "smart" way of
doing things (we are mature programmers, aren't we?), because "type safety"
and "performance" and so on so forth.





сб, 13 мар. 2021 г. в 15:45, Martin Schnabel :

> (sorry space a, i didn't reply to list)
>
> hi alex and space a.
>
> as far as i know there is no reason that anybody has to write code with
> generics when they are available. therefor i really don't understand the
> negative mails to this list.
>
> do you also want others not to use them? how would that help you? could
> you please explain to me your personal gain if generics are not added to
> go and not available to me and other users? many users have valid use
> cases for generics and custom code generation to deal with them now.
>
> i personally never had a reason to use imaginary numbers in go, they are
> however part of the language as literals and accompanied by special
> built-ins. should i care, do you?
>
> please explain
>
> On 13.03.21 12:34, Space A. wrote:
> > There is no rationale. They decided, and they implemented. No one from
> > Go team ever took the argument against it seriously because "community"
> > demands, blabla. And because Russ Cox with friends written an academic
> > paper so this is now a question of pure science. Write your own and they
> > could listen. (No)
> >
> > суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:
> >
> > Hello,
> >
> > Thank you for the answers.
> > Now I have something to read. :-)
> >
> > So, sorry for my English.
> > Personally, I would add a dynamic dispatching into GO
> > and left language without generic in order to keep simplicity for GO
> > and to make life of the applied programmers easier :-)
> >
> > What I'm looking for is the rationale behind the technical decision
> > to understand why the sort of decision has been taken.
> >
> > Thank you again for the answers.
> >
> > On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor
> wrote:
> >
> > On Fri, Mar 12, 2021 at 7:31 AM alex-coder 
> > wrote:
> >  >
> >  > Hello again,
> >  > I apologize for being so intrusive.
> >  > Where it is possible to read about the evaluations of labor
> > and complexity for
> >  > GO itself for different implementations to introduce generic
> > in GO ?
> >
> > LIke others, I'm not quite sure what you are asking, but perhaps
> > you
> > want to look at
> >
> >
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
> > <
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
> >
> >
> >
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
> > <
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
> >
> >
> >
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
> > <
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
> >
> >
> >
> > 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/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/golang-nuts/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%40googlegroups.com?utm_medium=email_source=footer
> >.
>
> --
> 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/c67e637e-6eea-de85-1d43-e2d775424044%40mb0.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" 

Re: [go-nuts] it seems the func NewSparseTreeHelper is not used by any code?

['Axel Wagner' via golang-nuts]

I agree, it seems unused. Someone probably forgot to delete it when it was
replaced by something else.

On Sat, Mar 13, 2021 at 3:09 PM xie cui  wrote:

>
> https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/sparsetreemap.go#L59
> where is code call NewSparseTreeHelper,  the comment says it is used by gc
> package, by i can not find it. please help?
>
> --
> 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/6489c7c9-67a4-4932-b2f5-ec14041b3201n%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/CAEkBMfG3STqMamJL7sZ7YSSU_sWmka77%3DwjYtGcuWoDerKLexg%40mail.gmail.com.

[go-nuts] it seems the func NewSparseTreeHelper is not used by any code?

[xie cui]

https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/sparsetreemap.go#L59
where is code call NewSparseTreeHelper,  the comment says it is used by gc 
package, by i can not find it. please help?

-- 
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/6489c7c9-67a4-4932-b2f5-ec14041b3201n%40googlegroups.com.

Re: [go-nuts] sort string slice like it contains key,val

['Carla Pfaff' via golang-nuts]

On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:

> the sort package from the stdlib, it contains an interface that you can 
> easily implement for such problematics :)
>

Like this: https://play.golang.org/p/eoLJ2aVAWkD
 

-- 
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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com.

Re: [go-nuts] sort string slice like it contains key,val

[Levieux Michel]

Hi,

You should take a look at the sort package from the stdlib, it contains an
interface that you can easily implement for such problematics :)

Hope this helps!

Le sam. 13 mars 2021 à 14:37, Vasiliy Tolstov  a
écrit :

> Hi!
> I'm stuck at sorting stuff like
>
> []string{"xxxkey","xxxval","zzzkey","zzzval","aaakey","aaaval","zzzkey","val"}
> i need to get after sorting something like
> []string{"aaakey","aaaval", "xxxkey","xxxval","zzzkey","val"}
>
> So i'm sort by "key" and if key is duplicated - last wins.
> Mostly i want to avoid creating helper slices that contains keys and
> vals dedicated, does it possible to do sorting only by swapping
> "key/val" ?
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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/CACaajQt82U878secmTSPaFW85a%3DWA20-vF%2BsPub%2B_w3i%3DohtEA%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/CAL4P9zxtGtLHVv-ujZ9c4Q0ButzobB78KZr3e5%3D-ucuP8curyQ%40mail.gmail.com.

Re: [go-nuts] Auto Make a named return map

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 2:14 PM Kevin Chadwick  wrote:

>
> >
> > I don't think we should change creation; what about having the first
> insert
> > make the map if it's nil?
> >
> > It seems that would be fairly transparent.
> >
>
> This wouldn't solve the problem that I saw.


It really is just another way to say "the zero value of a map should be an
empty map". That is "it's initialized on the first write" was a suggestion
on how to implement those semantics, because to the programmer there would
no longer be a distinction between an empty map and a "nil" map. Currently,
the only difference is that you can't write to a nil map (as well as
comparing it to nil). That difference would disappear.

As an aside: It's the same for slices, currently. An empty slice and a nil
slice are identical in every way, except for comparison to nil.

AFAICT, it looks like I misread Ian's response as if make could always be
> used
> then it would solve the problem rather than being a cause of a compiler
> complication.
>

Compiler complication is not the concern. It would be easy to build any of
the suggested semantics into the language. It is just that none of the
suggestions so far seem clearly better - that is, they all come with their
own downsides.

The concern about the zero value consisting of 0 bytes is more about
performance. As long as that's the case, initialization is very close to
free. As soon as the zero value becomes some non-zero bytes, they have to
be written and that incurs a cost.

When we say "the zero value of a map should only contain zero bytes", what
we mean is that if I write
var m map[int]int
that should a) reserve some memory for m (currently that's as many bytes as
a pointer needs) and b) those bytes should be zero after that.
If "make was called implicitly" or anything like that, those bytes wouldn't
be zero anymore - they would contain a pointer to an allocated map header.

It's as simple as that. You might feel that preserving that property is not
important or less important than having a useful zero value for maps.
That's fine. But that's the property Ian is talking about.



>
> --
> 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/87d37b24-14ba-1d9c-35eb-eef9832a10bc%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHzsX2mxLu-ihqkR_btNgkzHsae1b%3DrqJhc-JXQousrDw%40mail.gmail.com.

[go-nuts] sort string slice like it contains key,val

[Vasiliy Tolstov]

Hi!
I'm stuck at sorting stuff like
[]string{"xxxkey","xxxval","zzzkey","zzzval","aaakey","aaaval","zzzkey","val"}
i need to get after sorting something like
[]string{"aaakey","aaaval", "xxxkey","xxxval","zzzkey","val"}

So i'm sort by "key" and if key is duplicated - last wins.
Mostly i want to avoid creating helper slices that contains keys and
vals dedicated, does it possible to do sorting only by swapping
"key/val" ?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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/CACaajQt82U878secmTSPaFW85a%3DWA20-vF%2BsPub%2B_w3i%3DohtEA%40mail.gmail.com.

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

[Levieux Michel]

It's not because the arguments didn't appear numerous / convincing enough
that they were not taken into account. You are just stating your incapacity
to accept that you might be wrong, as anyone can, and that you cannot
discuss something (clearly because you don't want to *discuss*, you want
people to take everything you say for granted and absolute truth).

There have been many discussions and debates about generics (first as to
whether they should be added at all, then as to how they should be
implemented if ever they were), different proposals that were rejected
after lots and lots of arguments on both + and - minus sides, up to where
we are now.

If you are not okay with generics, so be it, but one - don't manipulate
facts, and second - stop being that dogmatic and negative here, please, for
the sake of all of us.

In advance, thanks for your time and consideration.

Cheers.

Le sam. 13 mars 2021 à 12:34, Space A.  a écrit :

> There is no rationale. They decided, and they implemented. No one from Go
> team ever took the argument against it seriously because "community"
> demands, blabla. And because Russ Cox with friends written an academic
> paper so this is now a question of pure science. Write your own and they
> could listen. (No)
>
> суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:
>
>> Hello,
>>
>> Thank you for the answers.
>> Now I have something to read. :-)
>>
>> So, sorry for my English.
>> Personally, I would add a dynamic dispatching into GO
>> and left language without generic in order to keep simplicity for GO
>> and to make life of the applied programmers easier :-)
>>
>> What I'm looking for is the rationale behind the technical decision
>> to understand why the sort of decision has been taken.
>>
>> Thank you again for the answers.
>>
>> On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor wrote:
>>
>>> On Fri, Mar 12, 2021 at 7:31 AM alex-coder  wrote:
>>> >
>>> > Hello again,
>>> > I apologize for being so intrusive.
>>> > Where it is possible to read about the evaluations of labor and
>>> complexity for
>>> > GO itself for different implementations to introduce generic in GO ?
>>>
>>> LIke others, I'm not quite sure what you are asking, but perhaps you
>>> want to look at
>>>
>>>
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>>>
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
>>>
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
>>>
>>> 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/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%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/CAL4P9zwtF0hk3z2dHUe6BX9uhXLkfL9tZypsQMGWaXDGSv6ZZw%40mail.gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

> 
> I don't think we should change creation; what about having the first 
> insert
> make the map if it's nil?
> 
> It seems that would be fairly transparent.
> 

This wouldn't solve the problem that I saw. Whilst, an easy personal fix is to
make sure coders always make a map whenever used. I figured a user might quite
easily think that := on a returned map would always be safe, like with a string.
Making an empty map just to return it and later making a map of a set size,
seems odd. I also do not see why you would ever initialise a nil map.

After looking into the named return discussion, including Dave Cheney's blog. I
also considered that :=, seemed to be the real problem in the end and IMO, the
feature with least to offer.

> 
> My original thinking was that either the function call or
> initialisation could run make under the covers. 
> 
> From Ian in those threads copied above "While not requiring the 
> make
> call".
> 
> Why not require make by calling it, behind the scenes?
> 
> 
> But that is exactly the loss of "the zero value is all 0 bytes" we are
> talking about. 
AFAICT, it looks like I misread Ian's response as if make could always be used
then it would solve the problem rather than being a cause of a compiler
complication.

-- 
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/87d37b24-14ba-1d9c-35eb-eef9832a10bc%40gmail.com.

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

[Jan Mercl]

On Sat, Mar 13, 2021 at 1:44 PM Martin Schnabel  wrote:

> as far as i know there is no reason that anybody has to write code with
> generics when they are available. therefor i really don't understand the
> negative mails to this list.

That nonchalantly ignores that code is way more often read than written.

"Clever" use of preprocessing macros can make C code unreadable to
anyone other than its author unless learning the mindset behind the
macros. Symbols in the binary can have very little connection with the
symbols in the source code. Nice tar pit for transpiling/debugging
etc. I believe that's why Go does not have C macros or anything like
that.

The problem with generics is not the same, but it shares some of the
problems depicted above. The no more existing 1:1 symbol mapping is
the one I regret most by a wide margin. Goodbye easy and simple
grepping.

Good use of generics _will_ be good for Go, don't get me wrong about
this. But, when looking at random code in the wild, let me ask: What's
the ratio of poor vs good code one encounters at random?

And don't get me wrong the second time. I'm writing a lot of poor
code. Once I start using generics, my future self will be probably the
first one to curse me for that.

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

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

[Martin Schnabel]

(sorry space a, i didn't reply to list)

hi alex and space a.

as far as i know there is no reason that anybody has to write code with 
generics when they are available. therefor i really don't understand the 
negative mails to this list.


do you also want others not to use them? how would that help you? could 
you please explain to me your personal gain if generics are not added to 
go and not available to me and other users? many users have valid use 
cases for generics and custom code generation to deal with them now.


i personally never had a reason to use imaginary numbers in go, they are 
however part of the language as literals and accompanied by special 
built-ins. should i care, do you?


please explain

On 13.03.21 12:34, Space A. wrote:
There is no rationale. They decided, and they implemented. No one from 
Go team ever took the argument against it seriously because "community" 
demands, blabla. And because Russ Cox with friends written an academic 
paper so this is now a question of pure science. Write your own and they 
could listen. (No)


суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:

Hello,

Thank you for the answers.
Now I have something to read. :-)

So, sorry for my English.
Personally, I would add a dynamic dispatching into GO
and left language without generic in order to keep simplicity for GO
and to make life of the applied programmers easier :-)

What I'm looking for is the rationale behind the technical decision
to understand why the sort of decision has been taken.

Thank you again for the answers.

On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor wrote:

On Fri, Mar 12, 2021 at 7:31 AM alex-coder 
wrote:
 >
 > Hello again,
 > I apologize for being so intrusive.
 > Where it is possible to read about the evaluations of labor
and complexity for
 > GO itself for different implementations to introduce generic
in GO ?

LIke others, I'm not quite sure what you are asking, but perhaps
you
want to look at


https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md




https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md




https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md




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/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%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/c67e637e-6eea-de85-1d43-e2d775424044%40mb0.org.

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

[Space A.]

There is no rationale. They decided, and they implemented. No one from Go 
team ever took the argument against it seriously because "community" 
demands, blabla. And because Russ Cox with friends written an academic 
paper so this is now a question of pure science. Write your own and they 
could listen. (No)

суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder: 

> Hello,
>
> Thank you for the answers.
> Now I have something to read. :-)
>
> So, sorry for my English.
> Personally, I would add a dynamic dispatching into GO
> and left language without generic in order to keep simplicity for GO
> and to make life of the applied programmers easier :-)
>
> What I'm looking for is the rationale behind the technical decision
> to understand why the sort of decision has been taken.
>
> Thank you again for the answers.
>
> On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor wrote:
>
>> On Fri, Mar 12, 2021 at 7:31 AM alex-coder  wrote:
>> >
>> > Hello again,
>> > I apologize for being so intrusive.
>> > Where it is possible to read about the evaluations of labor and 
>> complexity for
>> > GO itself for different implementations to introduce generic in GO ?
>>
>> LIke others, I'm not quite sure what you are asking, but perhaps you
>> want to look at
>>
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
>>
>> 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/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%40googlegroups.com.

Re: [go-nuts] struct conversion, new fields, and incompatibility

[Brian Candler]

Thanks for the clarification, and I agree completely.

There are plenty of cases in the Go standard library where there is a 
public struct for bundling state, and I don't see adding a new member 
(whether it's private or public) as a breaking change.  Nobody's going to 
attempt to mirror the entire type tree, and generally they can't because 
there are private members too.

Equally, it's reasonable to allow a package to export a plain-old-data 
struct, certainly between packages that comprise a user application.

On Friday, 12 March 2021 at 12:15:15 UTC axel.wa...@googlemail.com wrote:

> On Fri, Mar 12, 2021 at 10:16 AM Brian Candler  wrote:
>
>> I can see two separate things under discussion - compatibility of struct 
>> types for conversion, and backwards-compatibility of serialization [JSON? 
>> Protobuf?]
>>
>
> Backwards-compatibility of serialization is a red herring. It is off-topic 
> as far as this thread is concerned, this is purely about language-level 
> compatibility of types.
>  
>
>> but I can't see what's being proposed to change.
>>
>
> I think the proposed change can be summarized as roughly
>
> Either
>> 1. Create consensus that adding an (exported) field to a struct should be 
>> considered a backwards incompatible change, or
>> 2. Create consensus that converting one struct type into a different 
>> struct type should be considered deprecated, as it makes you vulnerable to 
>> getting broken by someone adding a field.
>> Take either consensus and put it into the Go 1 compatibility promise and 
>> potentially encode it into a vet check.
>
>
> That is my understanding of what's "proposed". Personally, as I said, I'm 
> not in favor of either. I think both statements lack nuance.
>
> The logical conclusions of the arguments brought forth is that every 
> publicly visible change is a breaking change. So if we follow that logic 
> we'd end up (in my opinion) in an ecosystem where every module is 
> constantly incrementing their major versions because "we technically broke 
> the API". I think that is undesirable.
>
> Given that every publicly visible change to an exported identifier can be 
> considered a breaking change, I personally don't think it's all that useful 
> to talk about interface-changes vs. struct changes and which of them are 
> breaking. Both are - in some circumstances. And in some circumstance, 
> neither are. It's more useful to talk about *how frequently* any given 
> change leads to breakages. I think it's easy to make an argument that 
> changing in interface type will lead to very frequent breakages - it will 
> either break every implementation of the interface, or any usage of the 
> interface, or both.
>
> Meanwhile, I think it's also not that hard to make an argument that 
> breakages causing by converting one struct type into another and then 
> adding a field to one of them are *comparatively* rare. And even within 
> that, there is nuance, where it is more frequent for some kind of types 
> (POD - plain-old-data) than others (e.g. http.Server or other types used to 
> abstract and bundle state).
>
> That's why I don't think a vet check would work. It can't distinguish the 
> case of a struct being POD vs. the struct bundling state. And I would even 
> argue that generally, the "bundling state" case is more common in Go.
>
>
>> I don't follow the argument that "adding a field to a struct is *now* a 
>> backwards incompatible change".  Surely this was always the case, 
>> regardless of tags?  That is, if you have
>>
>> type T1 struct {
>> Foo string
>> }
>>
>> type T2 struct {
>> Foo string
>> Bar string
>> }
>>
>> then what would you expect to happen for:
>>
>> v1 := T1{}
>> v2 := T2(v1)   ??
>> ...
>> v2 := T2{}
>> v1 := T1(v2)  ??
>>
>> These two structures have different shapes.  In the first case, I suppose 
>> it could copy the matching members and create zero values for the new 
>> ones.  In the second case, I suppose it could copy the matching members and 
>> silently(!) discard the missing ones.  But either way, that just means the 
>> compiler magically writing code which copies member-by-member.  I'd rather 
>> do this by hand.
>>
>> Even with magic conversions, trying to use a *t1 as a *t2 or vice versa 
>> would definitely not work, as they have differing layout in memory. Indeed, 
>> even the ordering of fields in memory must be the same for two structs to 
>> be compatible:
>> https://play.golang.org/p/BTUc6mNJQKS
>>
>> However, if two structures have the same members in the same order, and 
>> differ only by tags, then they have the same shape.  Then it seems 
>> reasonable to me to treat a T1 as compatible with T2; copying can be done 
>> as a blob of bytes.  The change in 1.8 to omit comparing tags has made 
>> types more compatible, not less.
>>
>> Separately from that, there's the issue of serialization and 
>> forwards/backwards compatibility.  I don't see any problem here.  For 
>> example, if you serialize a 

Re: [go-nuts] Auto Make a named return map

['Axel Wagner' via golang-nuts]

On Sat, Mar 13, 2021 at 1:24 AM Matthew Holiday 
wrote:

> I don't think we should change creation; what about having the first
> insert make the map if it's nil?
>
> It seems that would be fairly transparent.
>

I assume you accidentally hit "Reply" instead of "Reply All".

This isn't as simple either, unfortunately:

func F(m map[int]int) {
m[42] = 23
}

func main() {
var m map[int]int
F(m)
fmt.Println(m[42])
}

F might create the map, but the change has to be propagated back somehow -
and all it got is a nil-pointer.

No offense, but again, if it was that simple, it would have already
happened :) No one is arguing that having to explicitly initialize a map
(the same, BTW, goes for channels) is not awkward. But any solution comes
with its own set of problems, be it having to write `*map` everywhere,
introducing call-by-reference semantics, but only for some types, not for
others or significant performance penalties. It's been over a decade and we
didn't find a panacea yet - it's becoming increasingly unlikely that we
find one. And if we where to go through the churn of orchestrating a deep
language change like this, breaking almost every Go program out there, it
really has to be worth it and not just trade one wart for another.


>
> On Fri, Mar 12, 2021 at 5:03 PM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>>
>>
>> On Sat, Mar 13, 2021 at 12:01 AM Kevin Chadwick 
>> wrote:
>>
>>> I do not need to understand the difficulties that exist, though I
>>> struggle to understand the zero bytes property as surely even an empty
>>> string has a 4 or 8 byte pointer.
>>>
>>
>> A string is effectively a
>> struct{
>> data *byte
>> len int
>> }
>> If you zero that, you get a nil pointer and a 0 length, which is a valid
>> representation of an empty string.
>>
>> The same is true for every Go type. A nil pointer is all zero bytes (so
>> pointing at address 0, which is not accessible), maps/funcs/chans are
>> de-facto pointers (we often say "they are pointer-shaped"), so their zero
>> value is also just a pointer to address 0. A nil slice is a
>> struct {
>> data *T
>> len int
>> cap int
>> }
>> which, if zeroed, points at 0 with length/capacity 0. And so on.
>>
>> The zero value of any Go type is just whatever it is represented as in
>> memory, with all bytes set to 0.
>>
>> My original thinking was that either the function call or initialisation
>>> could run make under the covers.
>>
>> From Ian in those threads copied above "While not requiring the make
>>> call".
>>>
>>> Why not require make by calling it, behind the scenes?
>>>
>>
>> But that is exactly the loss of "the zero value is all 0 bytes" we are
>> talking about. It would mean if you write `var m map[int]int` the compiler
>> needs to create instructions to initialize `m` to something that is not
>> zero bytes (a.k.a. "call make behind the scenes"). And if you do `m :=
>> make([]map[int]int, 1e6)` it needs to run those instructions a million
>> times - instead of just getting a block of 0-bytes from the runtime.
>>
>> Of course it's *possible* to abandon this property. Lots of languages
>> (dare I say most languages) don't have it. We'd just prefer not to.
>>
>>
>>>
>>> --
>>> 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/AAB589F5-DA04-4468-A745-77F9177EAF76%40gmail.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGUjnqSnBmKZ%3DH6UHWmK%3DSFTigNLnYiBi%3DcT2Km2UzskQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> *Matt Holiday*
> Senior Gopher, Marketing Technologies
>
> 620 Eighth Avenue
>
> New York, NY 10018
>
> matthew.holi...@nytimes.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/CAEkBMfEW2aS7cnUBnPWXqwVu5%3DGp9CqBjTapDRizzeOJ%2Bg2Y1Q%40mail.gmail.com.