Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

[Bakul Shah]

On Wed, 19 Sep 2018 22:30:11 -0700 Sathish VJ  wrote:
>
> I've been asked this question a few times and I haven't been able to find 
> an answer.  Why does go reverse the order of variable declaration:  "i int" 
> vs "int i"
>
> Is there anything in the language design that requires this or was it based 
> on readability/writability or related to the parsing process or something 
> else?

It is a bit like Pascal except Go authors unfortunately
removed the ":" separating variables from their type. The main
benefit is you can read a declaration from left to right.

var foo, bar []int // foo and bar are slices of ints

Contrast:

int (*(*f)())[] // f is ptr to func returning ptr to array of ptr to int
vs
var f func()*[]*int // f is func returning ptr to slice of ptr to int

Both can be invoked as "f();" and return a ptr to a slice of
ptrs to int.

This is why you need cdecl to make sense of C declarations.

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

Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

['Axel Wagner' via golang-nuts]

There is a full blog article with the answer to this question :)
https://blog.golang.org/gos-declaration-syntax
It's so good, that I actually use it as a reference to people asking me
about C's declaration syntax.

On Thu, Sep 20, 2018 at 8:03 AM Tristan Colgate  wrote:

> But every aspect of that still reads unambiguously in a left to right
> order. Actually understanding C declarations can be extremely challenging.
>
> On Thu, 20 Sep 2018, 06:47 Sathish VJ,  wrote:
>
>> So, you are saying it is only for readability?
>>
>> But even in go we can write convoluted functions like:
>> func f(func(*int, *string) *int, []*byte) (func(*int, *float32), error)
>>
>>
>> On Thursday, 20 September 2018 11:09:23 UTC+5:30, kortschak wrote:
>>>
>>> To avoid having to have something like this:
>>>
>>> http://c-faq.com/decl/spiral.anderson.html
>>>
>>> On Wed, 2018-09-19 at 22:30 -0700, Sathish VJ wrote:
>>> > I've been asked this question a few times and I haven't been able to
>>> > find
>>> > an answer.  Why does go reverse the order of variable
>>> > declaration:  "i int"
>>> > vs "int i"
>>> >
>>> > Is there anything in the language design that requires this or was it
>>> > based
>>> > on readability/writability or related to the parsing process or
>>> > something
>>> > else?
>>> >
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

[Tristan Colgate]

But every aspect of that still reads unambiguously in a left to right
order. Actually understanding C declarations can be extremely challenging.

On Thu, 20 Sep 2018, 06:47 Sathish VJ,  wrote:

> So, you are saying it is only for readability?
>
> But even in go we can write convoluted functions like:
> func f(func(*int, *string) *int, []*byte) (func(*int, *float32), error)
>
>
> On Thursday, 20 September 2018 11:09:23 UTC+5:30, kortschak wrote:
>>
>> To avoid having to have something like this:
>>
>> http://c-faq.com/decl/spiral.anderson.html
>>
>> On Wed, 2018-09-19 at 22:30 -0700, Sathish VJ wrote:
>> > I've been asked this question a few times and I haven't been able to
>> > find
>> > an answer.  Why does go reverse the order of variable
>> > declaration:  "i int"
>> > vs "int i"
>> >
>> > Is there anything in the language design that requires this or was it
>> > based
>> > on readability/writability or related to the parsing process or
>> > something
>> > else?
>> >
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

[Sathish VJ]

So, you are saying it is only for readability?

But even in go we can write convoluted functions like: 
func f(func(*int, *string) *int, []*byte) (func(*int, *float32), error)


On Thursday, 20 September 2018 11:09:23 UTC+5:30, kortschak wrote:
>
> To avoid having to have something like this: 
>
> http://c-faq.com/decl/spiral.anderson.html 
>
> On Wed, 2018-09-19 at 22:30 -0700, Sathish VJ wrote: 
> > I've been asked this question a few times and I haven't been able to 
> > find  
> > an answer.  Why does go reverse the order of variable 
> > declaration:  "i int"  
> > vs "int i" 
> > 
> > Is there anything in the language design that requires this or was it 
> > based  
> > on readability/writability or related to the parsing process or 
> > something  
> > else? 
> > 
>

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

Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

[Dan Kortschak]

To avoid having to have something like this:

http://c-faq.com/decl/spiral.anderson.html

On Wed, 2018-09-19 at 22:30 -0700, Sathish VJ wrote:
> I've been asked this question a few times and I haven't been able to
> find 
> an answer.  Why does go reverse the order of variable
> declaration:  "i int" 
> vs "int i"
> 
> Is there anything in the language design that requires this or was it
> based 
> on readability/writability or related to the parsing process or
> something 
> else?
> 

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

[go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

[Sathish VJ]

I've been asked this question a few times and I haven't been able to find 
an answer.  Why does go reverse the order of variable declaration:  "i int" 
vs "int i"

Is there anything in the language design that requires this or was it based 
on readability/writability or related to the parsing process or something 
else?

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

[go-nuts] Re: Local variable escapes to heap

[Dave Cheney]

If you pass more -m's to the compiler it will explain why

Daves-MacBook-Pro(~/src) % go build -gcflags=-m=2 buffer.go
# command-line-arguments
./buffer.go:12:6: cannot inline main: function too complex: cost 108 
exceeds budget 80
./buffer.go:15:21: buffer escapes to heap
./buffer.go:15:21:  from Builder literal (struct literal element) at 
./buffer.go:15:14
./buffer.go:15:21:  from b (assigned) at ./buffer.go:15:4
./buffer.go:15:21:  from b.meta.Index() (receiver in indirect call) at 
./buffer.go:18:15
./buffer.go:13:6: moved to heap: buffer
:1: leaking param: .this
:1:  from .this.Index() (receiver in indirect call) at 
:1

I recommend raising a bug https://golang.org/issue/new if you feel the 
compiler could prove that main.buffer did not escape.

On Thursday, 20 September 2018 12:39:33 UTC+10, Alex Bahdanau wrote:
>
> Hi all,
>
> I've read a lot about escape analysis in golang, but still couldn't find 
> an answer to this question
> here is the sample :
>
> package main
>
> type IMeta interface {
> Index() int
> }
>
> type Builder struct {
> buf  []byte
> meta IMeta
> }
>
> func main() {
> var buffer [512]byte
>
> b := Builder{buffer[:0], nil}
>
> if b.meta != nil {
> b.meta.Index()
> }
> }
>
> escape analyzer says:
> .\main.go:15:21: buffer escapes to heap
> .\main.go:13:6: moved to heap: buffer
> :1:0: leaking param: .this
>
> Could anyone please clarify why local buffer escapes here?
>
> Thx in advance
>
>

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

Re: [go-nuts] Re: Time Zone changes over time & the standard library

[joe . blubaugh]

On Tuesday, September 18, 2018 at 10:18:34 AM UTC-7, Ian Lance Taylor wrote:
>
>
> In any case the answer the original question is the same: when the 
> timezone files update, Go will automatically adapt.  Just like any 
> other program on a Unix system. 
>
>  
Thanks for the education - I learned a new thing about Unices :)
 

> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] bufio.Writer's sticky errors & lost data

[John Floren]

If bufio.Writer.Flush() ever sees an error, it sets b.err and will 
immediately return that error on any future calls to Flush: 
https://golang.org/src/bufio/bufio.go?s=14569:14599#L558

Writer.Reset(w io.Writer) will clear the error and set the bufio.Writer to 
use the new io.Writer given, but it also *resets the buffer pointer to 0*, 
losing pending data.

Suppose I have a bufio.Writer wrapping a network connection. If I e.g. 
switch from WiFi to an ethernet connection on my laptop, Flush will return 
an error and thereafter refuse to write to that connection. I can 
re-establish the connection and call Writer.Reset with the new connection, 
but I will lose any pending data.

At bufio.go:580, Flush's error-handling code seems to be updating b.buf and 
b.n as if they might be used later, but a quick look through the code shows 
that if b.err is ever set, b.buf will never be written to the io.Writer.

The same applies if you've set a WriteDeadline on your connection; the 
connection itself may in fact be completely fine, but temporary network 
conditions meant you couldn't meet the deadline. The bufio.Writer, though, 
is broken if it misses a deadline.

What's the right way to handle this? Write our own bufio that lets us reset 
the error and io.Writer while preserving unwritten data?

Thanks,

John

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

[go-nuts] How much performance will be impacted for GC to be conservative by scanning externally allocated memory (mmap mostly desirable) for pointers ?

[Compl Yue]

Hi Gophers,

I'm new to Go and excited by it's elegancy and potentials :D

I'm investigating into the Go way to serve massive structured data which's 
backed by few huge files mmap-ed.

As I researched so far, boltdb has done similar things pretty successful, 
but it received criticism about its transactional performance, so I wonder 
if it is be coz of poor GC interactions (besides global write locking), and 
searched the actively maintained bbolt codebase, I found no GC related 
coordination code.

I read about in this group, that GC will scan memory with missing runtime 
type for any words look like pointers, as to be `conservative`, so I came 
to the question:

   1. If a regular `*struct{...}` pointer is obtained via 
   `unsafe.Pointer()` by reinterpreting a `[]byte` offset from mmap-ed memory, 
   obviously it has no runtime type info from Go allocator, then will it 
   invoke GC to scan the bytes it points to ?
   2. And if 1.=> True, will GC treat pointer-like words within the struct 
   as Go pointers thus keep pointed-to object alive ?

If both 1. and 2. are True, then those structs living in mmap-ed memory can 
fully function as Go objects (i.e. with pointer fields), but I worry about 
too much performance impact will limit number of such pointers to be held 
at runtime, then Go pointers need to be reinterpreted on-demand, from 
offsets on-the-fly, at last not easily be correct to hold pointer fields.

So I hope 1.=>False then intensive use of such pointers causes no 
performance penalty, but that also means no regular Go pointer should be 
defined into such structs. I think boltdb did this and I can live with it.

Thanks with best regards,
Compl

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

[go-nuts] Local variable escapes to heap

[alex . bahdanau]

Hi all,

I've read a lot about escape analysis in golang, but still couldn't find an 
answer to this question
here is the sample :

package main

type IMeta interface {
Index() int
}

type Builder struct {
buf  []byte
meta IMeta
}

func main() {
var buffer [512]byte

b := Builder{buffer[:0], nil}

if b.meta != nil {
b.meta.Index()
}
}

escape analyzer says:
.\main.go:15:21: buffer escapes to heap
.\main.go:13:6: moved to heap: buffer
:1:0: leaking param: .this

Could anyone please clarify why local buffer escapes here?

Thx in advance

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

[go-nuts] Re: proposal: generic generics proposal

[alan . fox6]

Not really, TBH, though I'll soon be posting a link to my new treatise: "De 
rebus genericis golangi dvo" to the feedback page. 

I thought it might gain more attention if the title were written in Latin .

Alan  

On Thursday, September 20, 2018 at 12:59:27 AM UTC+1, kortschak wrote:
>
> It's pretty clear for the flood of emails to golang-nuts and golang-dev 
> regarding the recent generics/contracts proposal that there are many 
> ways to implement generics proposals. 
>
> Because of this and risks associated with copy pasting generics 
> proposals to modify and re-propose, I would like to propose a mechanism 
> for implementing generics proposals generically — that is a parametric 
> proposal proposal (possibly with either metacontracts or nested 
> boxing). 
>
> Is anyone adequately versed in metaphysics and the philosophy of self- 
> reference to help me out with this? 
>
> thanks 
> Dan 
>

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

[go-nuts] Generic alternatives: new basic types?

[Randall O'Reilly]

Given all the challenges associated with generics, it might be productive to 
follow up on this alternative approach of identifying a (small set) of new 
primitive containers and functions that would otherwise have been written using 
generics, that are of sufficiently general applicability as to merit inclusion 
in Go2?  I know this kind of discussion is had frequently on this list, e.g., 
recently in the case of tuples and ternary expressions, and the outcome is 
usually a pretty convincing “not gonna happen”, but MAYBE in the light of the 
generics discussion there might be some fresh insights along these lines?

It seems like one of the fundamental reasons generics are so “contrary” for Go 
is that they require exposing a bunch of low-level internal special-case logic 
(e.g., operator semantics, etc) in a “meta” explicit way.  Doing so in a clean, 
simple, elegant way may be impossible.  The current Go1 alternative strategy is 
to bury all that logic well out-of-sight and provide a simple, elegant “magic” 
set of language primitives that seamlessly interoperate with all the other 
basic types.  For those things that are supported in this way, the result is 
pure joy and simplicity :)  So, a logical alternative to generics is to think 
about anything of sufficient generality that is missing, and just add it in 
with the same kind of existing magic.

Another way of framing the issue is: if you give people generics, they will 
each write the same kind of functionality in slightly different ways.  Instead, 
the “Go” way is to figure out the *best* way to do something, and build that 
right on into the language as a primitive, which fully interoperates and deals 
with all the necessary idiosyncrasies of the other types.  I doubt anyone would 
argue that the existing “minimal basis set” of functionality is truly minimal 
and truly covers the vast majority of needs.

The list of plausible additions is likely quite small, and the draft generics 
proposal suggests what most of these might be:

* binary trees (llrb?) — can anyone really argue AGAINST this?

* sets — really map[T]struct{} seems fine here — probably not worth it?

* linked lists??  probably not given llrb?  also I’ve written many stacks and 
they seem trivial and painless using slices..

* tensors (n-dimensional arrays) — this would be GREAT for numerical stuff — 
there is an existing heroic implementation https://github.com/gorgonia/tensor 
but a minimal core builtin support for the basic slice-level functionality 
extended to multiple dimensions would be really nice!  Here’s a proposal: 
https://go.googlesource.com/proposal/+/master/design/6282-table-data.md

Functions:

* insert() primitive for slices — I wasn’t able to find prior discussion of 
this, but this is the ONLY major pain point for me in dealing with slices — it 
is 3 repetitive, relatively opaque lines of code every time, and seems well 
worth the “investment” in a new keyword..  I did find some debate about whether 
delete() should operate on slices too — seems like that would be a simple 
semantic convenience that makes code more explicit and the counter-arguments 
from the previous debate weren’t that strong IMO 
https://grokbase.com/t/gg/golang-nuts/1366rkp7ef/go-nuts-why-not-provide-a-delete-function-in-slices-just-like-in-maps

* max(), min(), abs() — how about it?  these seem like the main focus of 
generics discussion, and are a “safe” special case form of the ternary 
operator.  When I first found out that there wasn’t a max operator for ints in 
Go I was really shocked.. I got over it, but still, these are really basic 
mathematical operators that I use all the time..

* most of the other examples in the generics proposal seem like such trivial 
one-liners (sorting, map / reduce, the various channel functions) that it 
doesn’t quite seem worth it…  

Anyway, that is really it for my list — if these were in the language, it would 
make my code easier and simpler to write and understand.  I’m not sure I could 
say the same for any of the existing generics proposals.. :)

- Randy

> On Sep 18, 2018, at 2:05 PM, Michael Jones  wrote:
> 
> I believe average Go code will be better if there are map-quality llrb trees, 
> stacks, sets, ... for the taking, just as if tuples were a first class thing. 
> There were horrors in STL's evolution, but by now, everyone gets such data 
> structures right the first time they use them, just as they do now with Go 
> maps.
> 

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

[go-nuts] proposal: generic generics proposal

[Dan Kortschak]

It's pretty clear for the flood of emails to golang-nuts and golang-dev 
regarding the recent generics/contracts proposal that there are many
ways to implement generics proposals.

Because of this and risks associated with copy pasting generics
proposals to modify and re-propose, I would like to propose a mechanism
for implementing generics proposals generically — that is a parametric
proposal proposal (possibly with either metacontracts or nested
boxing).

Is anyone adequately versed in metaphysics and the philosophy of self-
reference to help me out with this?

thanks
Dan

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

Re: [go-nuts] go modules and Dockerfile

[Sotirios Mantziaris]

Awesome thanks

On Wednesday, September 19, 2018 at 10:40:30 PM UTC+3, Justin Israel wrote:
>
>
>
> On Thu, Sep 20, 2018, 6:09 AM Sotirios Mantziaris  > wrote:
>
>> hi,
>>
>> i am trying to build a container that supports modules and i get the 
>> following error:
>>
>> ↳ docker build . -t test  
>> 
>>  1 ↵  
>> 4.91G RAM  0.00K SWP  21:04:00
>> Sending build context to Docker daemon  16.65MB
>> Step 1/6 : FROM golang:latest as builder
>>  ---> fb7a47d8605b
>> Step 2/6 : COPY . ./
>>  ---> Using cache
>>  ---> 95a6b0284991
>> Step 3/6 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o 
>> test ./cmd/test/main.go
>>  ---> Running in f09b924aa3e9
>> $GOPATH/go.mod exists but should not
>> The command '/bin/sh -c CGO_ENABLED=0 GOOS=linux go build -a 
>> -installsuffix cgo -o test ./cmd/test/main.go' returned a non-zero code: 1
>>
>> The docker file looks like this.
>>
>> FROM golang:latest as builder
>> COPY . ./
>> RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o test 
>> ./cmd/test/main.go 
>>
>> FROM scratch
>> COPY --from=builder test .
>> CMD ["./test"]
>>
>> any ideas how to solve this?
>>
>
> The golang image sets WORKDIR $GOPATH, and you don't modify it at all. So 
> you are copying your project files to $GOPATH
>
> Try doing 
>
> WORKDIR $GOPATH/src/myapp
>
> Or to some location outside $GOPATH
>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] go modules and Dockerfile

[Justin Israel]

On Thu, Sep 20, 2018, 6:09 AM Sotirios Mantziaris 
wrote:

> hi,
>
> i am trying to build a container that supports modules and i get the
> following error:
>
> ↳ docker build . -t test
>
>  1 ↵ 
> 4.91G RAM  0.00K SWP  21:04:00
> Sending build context to Docker daemon  16.65MB
> Step 1/6 : FROM golang:latest as builder
>  ---> fb7a47d8605b
> Step 2/6 : COPY . ./
>  ---> Using cache
>  ---> 95a6b0284991
> Step 3/6 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o
> test ./cmd/test/main.go
>  ---> Running in f09b924aa3e9
> $GOPATH/go.mod exists but should not
> The command '/bin/sh -c CGO_ENABLED=0 GOOS=linux go build -a
> -installsuffix cgo -o test ./cmd/test/main.go' returned a non-zero code: 1
>
> The docker file looks like this.
>
> FROM golang:latest as builder
> COPY . ./
> RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o test
> ./cmd/test/main.go
>
> FROM scratch
> COPY --from=builder test .
> CMD ["./test"]
>
> any ideas how to solve this?
>

The golang image sets WORKDIR $GOPATH, and you don't modify it at all. So
you are copying your project files to $GOPATH

Try doing

WORKDIR $GOPATH/src/myapp

Or to some location outside $GOPATH

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

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

[go-nuts] go modules and Dockerfile

[Sotirios Mantziaris]

hi,

i am trying to build a container that supports modules and i get the 
following error:

↳ docker build . -t test

   1 ↵  
4.91G RAM  0.00K SWP  21:04:00
Sending build context to Docker daemon  16.65MB
Step 1/6 : FROM golang:latest as builder
 ---> fb7a47d8605b
Step 2/6 : COPY . ./
 ---> Using cache
 ---> 95a6b0284991
Step 3/6 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o 
test ./cmd/test/main.go
 ---> Running in f09b924aa3e9
$GOPATH/go.mod exists but should not
The command '/bin/sh -c CGO_ENABLED=0 GOOS=linux go build -a -installsuffix 
cgo -o test ./cmd/test/main.go' returned a non-zero code: 1

The docker file looks like this.

FROM golang:latest as builder
COPY . ./
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o test 
./cmd/test/main.go 

FROM scratch
COPY --from=builder test .
CMD ["./test"]

any ideas how to solve 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: I am not in favor of generics.

[Dave Cheney]

Thank you to everyone who has contributed to this thread. 

It is time for everyone to take a break for 48 hours. After this time if you 
feel strongly that there is a point which you must continue to debate please do 
so, but be mindful that many words have already been spent in this thread and 
the points of view expressed are unlikely to change. 

Thank you

Dave

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

Re: [go-nuts] Re: I am not in favor of generics.

[Wojciech S. Czarnecki]

On Wed, 19 Sep 2018 09:32:39 -0500
Robert Engels  wrote:

> This is not what I am referring to. I am stating that with N generics types
> in a method the developer needs to write NxN case methods. Not feasible. 

Wrong. On two axis.

1. As stated in proposal, CGG has no "generic type" (generic data).

CGG stays entirely within comfort zone of the current Go type system.
No new things. CGG allows for readable generic **code** only.

Within CGG proposal you can **not** describe generic data using 
blocks of more grained generic data; i.e. in c++/java's matrioshka style.
By design. 

2. CGG generic code will operate "on types or part thereof".

Example Sum, in its most compact version

func (x type []K) Sum() (r type K) {
  for type K range int64(), uint64(), float64(), complex128()
  for _, v := range x {
r += v
  }
  return
}

operates on any member of **infinite** set of concrete types
that has base type of either: int8, int16, int32, int64, uint8,
uint16, uint32, uint64, float32, float64, complex64 or complex128.

The developer implementing generic solution needs to write 
`for _, v := range x {;r+=v;};return;};` source. 

Above source makes to object code that will run alike for
`type my1 int8` and `type my2 int64`. Possible that it will be
a single variant for "all signed integers".

( From the contract one can infer, that Sum as stated may have up to 4,
and **at most** 12 emitted variants. None of which written directly
by the developer. )

In the second version, one that is meant to act also on some outstanding
type, the specialization is the devoloper's to decide. She decided to make
it for something like big.Int /T = big.Int/? Hmm.. I only need Add, so make
it more generic. `(*K) Add(K, K)` constraint allows for an x being a member
of infinite set of concrete types that "have method Add" of given signature.
Big.Int just happens to be member of that set.

func (x type []K) Sum() (r type K) {
 for type switch {
 case K range int64(), uint64(), float64(), complex128():
  for _, v := range x {
 r += v
  }
 case K (*K) Add(K, K): 
  for _, v := range x {
 r.Add(r,v)
  }
 break
 }
 return
}

CGG allows for specialized generic code. With "all types something that
allowed types have in common" occupying a single case.

Within other generic package, eg. webcommerce one, developer is free
to define and use other Sum - domain specific. Eg one that sums all
posible types of virtual "items" kind:

package "webo"

func (x type []K) Sum() (r int) {
 for type K.Value = int()
 for _, v := range x {
r += v.Value
 }
 return
}

this Sum will take as x any struct with Value field that happens
to be int based. So Ticket (s) of below can be webo.Summed too.

type Reward int8
type Ticket struct { 
n string 
Value Reward
}


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

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

Re: [go-nuts] Re: I am not in favor of generics.

[Robert Engels]

There is a reason that Google has moved to Angular2 from AngularJS. As 
applications get larger you need more structure in order to maintain them. 
Implements is one of the ways to provide the needed structure. I know having 
structure goes against hacking. Try having a conversation in a room with 
speakers in a hundred languages. Not easy. Structure, consistency, common 
language. Staying explicating what something represents is going to be a better 
communication tool. 

Sent from my iPhone

> On Sep 19, 2018, at 10:02 AM, Thomas Bushnell, BSG  
> wrote:
> 
>> On Wed, Sep 19, 2018 at 4:04 PM robert engels  wrote:
>> 
>> The opinion that well, since there is no implements I can define my own 
>> interface, and pass some stdlib struct that I can’t control as an 
>> “implementor” is hogwash. Because you also don’t control this code, the API 
>> is free to change - breaking your code. This is why the “backwards 
>> implements” is a bad idea.
> 
> I have experience in a millions-of-lines connected code base which uses 
> exactly the strategy that you say can't work. I can confirm that it does work 
> if you use it correctly. 

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

Re: [go-nuts] Re: I am not in favor of generics.

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

On Wed, Sep 19, 2018 at 4:04 PM robert engels  wrote:

>
> The opinion that well, since there is no implements I can define my own
> interface, and pass some stdlib struct that I can’t control as an
> “implementor” is hogwash. Because you also don’t control this code, the API
> is free to change - breaking your code. This is why the “backwards
> implements” is a bad idea.
>

I have experience in a millions-of-lines connected code base which uses
exactly the strategy that you say can't work. I can confirm that it does
work if you use it correctly.

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

Re: [go-nuts] Re: I am not in favor of generics.

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

That's a different case than one which "implements" addresses. You don't
need "implements" to address that problem, if you think it's a problem.

Adding "implements" doesn't help. I understand there are people who think
adding generics might help, but that's a different thing.

On Wed, Sep 19, 2018 at 4:04 PM robert engels  wrote:

> That is not true. Often, due to lack of generics things are passed as
> interface{} or a sub interface, and then type checked/casted in the method.
> When you refactor you will get no warnings that X no longer meets the
> contract. You have no obvious way either by looking at the code to know
> which interfaces a developer needs (or wants it) to implement. Things will
> fail at runtime,
>
> People state this is a plus - yes it is - for small easily
> contained/understood systems. As the application grows larger, this is a
> real bottleneck to productivity.
>
> Having ‘implements’ does nothing to harm the productivity - not having it
> hurts.
>
> The opinion that well, since there is no implements I can define my own
> interface, and pass some stdlib struct that I can’t control as an
> “implementor” is hogwash. Because you also don’t control this code, the API
> is free to change - breaking your code. This is why the “backwards
> implements” is a bad idea.
>
> Having implements is the easiest to understand large systems - if you use
> interface based design, you can get a full mental picture of the system,
> then by looking at implementors you can determine the concrete options
> (performance, capabilities, etc.)
>
> Try working with any dynamic language that has duck typing - it is
> impossible to refactor. Don’t take my word for it, just read any of the
> thousands of blog posts covering it.
>
> Go is no different.
>
> Go was designed to replace scripting tools, and C tools (usually systems
> level). It was not designed for large enterprise applications, and that is
> why it falls down in many places. It doesn’t mean it isn’t GREAT for what
> it was designed to do, and better than Java in many (most) of these cases.
> Large enterprise apps, no way.
>
>
> On Sep 19, 2018, at 8:39 AM, Thomas Bushnell, BSG 
> wrote:
>
> Huh? Type safety is still checked by the compiler. Implements does nothing
> except put a road-block in the way and prohibit you from making an
> interface that some other package happens to implement.
>
> On Wed, Sep 19, 2018 at 1:40 PM Robert Engels 
> wrote:
>
>> Go not having implements is a big problem when refactoring large Go
>> systems especially because it doesn’t have generics - all type safety is
>> gone and you fly by the seat of your pants.
>>
>> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki 
>> wrote:
>>
>> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
>> >
>> > The **stated** goal for adding some kind of generics to Go is
>> > and always was "how to not repeat writing same code just for a type".
>> >
>> > Now above practical goal, in minds of many, somewhat morphed
>> > to "Yeah, lets have real true generics so we can write/reuse
>> > smart and clever code we once upon a time wrote for c++/java".
>> > "So we need a way of expressing generic data in terms of other
>> > generic data then use abstract alghoritm on that".
>> > (Yep, team's proposal use: "in terms of operations")
>> >
>> > It now poisons all the proposals I've seen with syntax that
>> > forces **user** of the code to **repeat** at the **call site**
>> > type identifier for the sake of "code instantiation".
>> >
>> > Why? I think that's a mark of "one proper way for doing generics" burnt
>> > on the popular mindset. As hard to overcome as notion that one needs
>> > 'implements/implementing' to use interfaces.
>> >
>> > Does Go2 should have "implements" keyword added too?
>> > `type mytype struct{...} : implements io.Writer, ..., ...`
>> >
>> > What?! "Compiler knows whether your type satisfies an interface"
>> >
>> > Yeah, and at the call site compiler **does know** the parameter
>> > type too. This is the CGG basis.
>> >
>> >
>> > 1. Find a way to write "some Go code" that is suitable for set of
>> > types that have "something" in common.
>> >
>> > 2. Find a way to describe the set via the "something common"
>> > that implementation for said set will use on objects of matching types.
>> >
>> > 3. It **MUST** read as Go: no instantiation at call site.
>> >
>> >
>> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
>> > mhhc...@gmail.com wrote:
>> >
>> >> I was referring to this code
>> >>
>> >> func (x type []K) Sum() (r type K) {
>> >> }
>> >>
>> >
>> >> I did not understand how "// For var x []AnyType. ANY. " relates to
>> >> previous code.
>> >
>> > Previous code example was specific to `big.Int` type. Next I gave
>> > a really generic usage example via the constraint that already is
>> > described in CGG proposal: "type with given method implemented".
>> >
>> > With that constraint func Sum can be called on _any_ type that has
>> > a method (*T) Add(T,T). And some

[go-nuts] Re: I am not in favor of generics.

[Space A.]

+1 Go doesn't need generics, in fact it goes against its philosophy and 
core values. 
Lack of generics was one of the reasons I moved to Go, I worked with Java 
since version 3, and I do believe that generics just made Java worse.

Regards.



понедельник, 17 сентября 2018 г., 19:04:26 UTC+3 пользователь 
jucie@zanthus.com.br написал:
>
> Go core team is working hard to bring generics to the language because 
> several people asked for it. With all due respect for those users and for 
> people working hard to make generics a reality, I feel that a greater 
> number of people would suffer after generics adoption. So, I feel compeled 
> to manifest my opinion: sorry guys, Go with generics will be worse than Go 
> without generics.
>
> The language strives for simplicity since its inception and that is what 
> attracted a large part of its user base. We must think about who we will 
> want to have in our community 10 years from now. Supporting generics would 
> please a minority to the detriment of a large number of potential users.
>
> Today Go is easy to learn and tools are easy to implement. Please keep it 
> that way.
>
> Thanks.
>

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

Re: [go-nuts] Re: I am not in favor of generics.

[Robert Engels]

This is not what I am referring to. I am stating that with N generics types in 
a method the developer needs to write NxN case methods. Not feasible. 

Sent from my iPhone

> On Sep 19, 2018, at 9:25 AM, Wojciech S. Czarnecki  wrote:
> 
> On Wed, 19 Sep 2018 06:52:09 -0500
> Robert Engels  wrote:
> 
>> Also, I did read what you wrote. I questioned “what happens when you have N
>> different generic types in the call signature. The select type statement
>> has N*N cases. “. You did not respond. 
> 
> The object code (i.e. ssa then machine) is instantiated **only** when its
> **used** with given types set.
> 
> If you really do call f.genpkg.(x) method on 200 different types for f,
> each with 200 N typed vars x you will pollute symbol table **at compiling
> time** (4 entries you will not see until you dump the table).
> 
> But resulting object code will have at most as many variants as M
> and N have different base types / for-type-cases at most.
> 
> It further can be size-optimized by factoring out type-sized operations
> reusing a given code chunk for more than one base/case.
> 
> Hope this helps,
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE

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

Re: [go-nuts] Re: I am not in favor of generics.

[Wojciech S. Czarnecki]

On Wed, 19 Sep 2018 06:52:09 -0500
Robert Engels  wrote:

> Also, I did read what you wrote. I questioned “what happens when you have N
> different generic types in the call signature. The select type statement
> has N*N cases. “. You did not respond. 

The object code (i.e. ssa then machine) is instantiated **only** when its
**used** with given types set.

If you really do call f.genpkg.(x) method on 200 different types for f,
each with 200 N typed vars x you will pollute symbol table **at compiling
time** (4 entries you will not see until you dump the table).

But resulting object code will have at most as many variants as M
and N have different base types / for-type-cases at most.

It further can be size-optimized by factoring out type-sized operations
reusing a given code chunk for more than one base/case.

Hope this helps,

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

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

Re: [go-nuts] Re: I am not in favor of generics.

[robert engels]

That is not true. Often, due to lack of generics things are passed as 
interface{} or a sub interface, and then type checked/casted in the method. 
When you refactor you will get no warnings that X no longer meets the contract. 
You have no obvious way either by looking at the code to know which interfaces 
a developer needs (or wants it) to implement. Things will fail at runtime,

People state this is a plus - yes it is - for small easily contained/understood 
systems. As the application grows larger, this is a real bottleneck to 
productivity.

Having ‘implements’ does nothing to harm the productivity - not having it hurts.

The opinion that well, since there is no implements I can define my own 
interface, and pass some stdlib struct that I can’t control as an “implementor” 
is hogwash. Because you also don’t control this code, the API is free to change 
- breaking your code. This is why the “backwards implements” is a bad idea.

Having implements is the easiest to understand large systems - if you use 
interface based design, you can get a full mental picture of the system, then 
by looking at implementors you can determine the concrete options (performance, 
capabilities, etc.)

Try working with any dynamic language that has duck typing - it is impossible 
to refactor. Don’t take my word for it, just read any of the thousands of blog 
posts covering it.

Go is no different.

Go was designed to replace scripting tools, and C tools (usually systems 
level). It was not designed for large enterprise applications, and that is why 
it falls down in many places. It doesn’t mean it isn’t GREAT for what it was 
designed to do, and better than Java in many (most) of these cases. Large 
enterprise apps, no way.


> On Sep 19, 2018, at 8:39 AM, Thomas Bushnell, BSG  
> wrote:
> 
> Huh? Type safety is still checked by the compiler. Implements does nothing 
> except put a road-block in the way and prohibit you from making an interface 
> that some other package happens to implement.
> 
> On Wed, Sep 19, 2018 at 1:40 PM Robert Engels  > wrote:
> Go not having implements is a big problem when refactoring large Go systems 
> especially because it doesn’t have generics - all type safety is gone and you 
> fly by the seat of your pants. 
> 
> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki  > wrote:
> 
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com 
> >>  wrote:
> > 
> > The **stated** goal for adding some kind of generics to Go is
> > and always was "how to not repeat writing same code just for a type".
> > 
> > Now above practical goal, in minds of many, somewhat morphed
> > to "Yeah, lets have real true generics so we can write/reuse
> > smart and clever code we once upon a time wrote for c++/java".
> > "So we need a way of expressing generic data in terms of other
> > generic data then use abstract alghoritm on that". 
> > (Yep, team's proposal use: "in terms of operations")
> > 
> > It now poisons all the proposals I've seen with syntax that
> > forces **user** of the code to **repeat** at the **call site**
> > type identifier for the sake of "code instantiation".
> > 
> > Why? I think that's a mark of "one proper way for doing generics" burnt
> > on the popular mindset. As hard to overcome as notion that one needs
> > 'implements/implementing' to use interfaces.
> > 
> > Does Go2 should have "implements" keyword added too?
> > `type mytype struct{...} : implements io.Writer, ..., ...`
> > 
> > What?! "Compiler knows whether your type satisfies an interface"
> > 
> > Yeah, and at the call site compiler **does know** the parameter
> > type too. This is the CGG basis.
> > 
> > 
> > 1. Find a way to write "some Go code" that is suitable for set of
> > types that have "something" in common.
> > 
> > 2. Find a way to describe the set via the "something common" 
> > that implementation for said set will use on objects of matching types.
> > 
> > 3. It **MUST** read as Go: no instantiation at call site.
> > 
> > 
> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> > mhhc...@gmail.com  wrote:
> > 
> >> I was referring to this code
> >> 
> >> func (x type []K) Sum() (r type K) { 
> >> } 
> >> 
> > 
> >> I did not understand how "// For var x []AnyType. ANY. " relates to 
> >> previous code.
> > 
> > Previous code example was specific to `big.Int` type. Next I gave
> > a really generic usage example via the constraint that already is
> > described in CGG proposal: "type with given method implemented".
> > 
> > With that constraint func Sum can be called on _any_ type that has
> > a method (*T) Add(T,T). And someone writing new code needs not to
> > change generic lib (as imputed), but she needs to provide for her
> > non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> > 
> >> for your question about the rune, i guess it d be like this 
> > [...] 
> >> Consider Z,K as virtual types to be 

Re: [go-nuts] Re: I am not in favor of generics.

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

Huh? Type safety is still checked by the compiler. Implements does nothing
except put a road-block in the way and prohibit you from making an
interface that some other package happens to implement.

On Wed, Sep 19, 2018 at 1:40 PM Robert Engels  wrote:

> Go not having implements is a big problem when refactoring large Go
> systems especially because it doesn’t have generics - all type safety is
> gone and you fly by the seat of your pants.
>
> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki 
> wrote:
>
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
> >
> > The **stated** goal for adding some kind of generics to Go is
> > and always was "how to not repeat writing same code just for a type".
> >
> > Now above practical goal, in minds of many, somewhat morphed
> > to "Yeah, lets have real true generics so we can write/reuse
> > smart and clever code we once upon a time wrote for c++/java".
> > "So we need a way of expressing generic data in terms of other
> > generic data then use abstract alghoritm on that".
> > (Yep, team's proposal use: "in terms of operations")
> >
> > It now poisons all the proposals I've seen with syntax that
> > forces **user** of the code to **repeat** at the **call site**
> > type identifier for the sake of "code instantiation".
> >
> > Why? I think that's a mark of "one proper way for doing generics" burnt
> > on the popular mindset. As hard to overcome as notion that one needs
> > 'implements/implementing' to use interfaces.
> >
> > Does Go2 should have "implements" keyword added too?
> > `type mytype struct{...} : implements io.Writer, ..., ...`
> >
> > What?! "Compiler knows whether your type satisfies an interface"
> >
> > Yeah, and at the call site compiler **does know** the parameter
> > type too. This is the CGG basis.
> >
> >
> > 1. Find a way to write "some Go code" that is suitable for set of
> > types that have "something" in common.
> >
> > 2. Find a way to describe the set via the "something common"
> > that implementation for said set will use on objects of matching types.
> >
> > 3. It **MUST** read as Go: no instantiation at call site.
> >
> >
> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I was referring to this code
> >>
> >> func (x type []K) Sum() (r type K) {
> >> }
> >>
> >
> >> I did not understand how "// For var x []AnyType. ANY. " relates to
> >> previous code.
> >
> > Previous code example was specific to `big.Int` type. Next I gave
> > a really generic usage example via the constraint that already is
> > described in CGG proposal: "type with given method implemented".
> >
> > With that constraint func Sum can be called on _any_ type that has
> > a method (*T) Add(T,T). And someone writing new code needs not to
> > change generic lib (as imputed), but she needs to provide for her
> > non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> >
> >> for your question about the rune, i guess it d be like this
> > [...]
> >> Consider Z,K as virtual types to be inferred from the call site.
> > Progress! As to inferred :)
> >
> > But I wanted return to be a string with sum of runes from all
> > input strings :) Leave it.
> >
> > In CGG such specialization takes place in a single to find and simple
> > to **read** 'case' code. The proposal's example Sum already has a single
> > piece of code that will be **reused** for all numerical types that user
> > **might** declare off builtin. With only two for type cases CGG's generic
> > Sum spans all types with numerical base and all types that provide their
> own
> > "me plus operator". With one case more it allows for set of types that
> have
> > "plus me operator". Code that can and will run for multitude of user
> types.
> >
> > Yet I still hear stubborn "not reusable!, not reusable! not generic!".
> >
> >> In regards to Russ Cox proposal this code is missing
> >> their explicitly declared contracts and the function instances
> declaration.
> >> On the other hand, this is so much more readable *to me*.
> >
> > The "real true generics" proposals are readable to people who took the
> > time and the training to accommodate to such List>
> > syntactical mess. But it is **against** Go philosophy of "readability
> first".
> > It excludes the legion who finds mental instantiations cumbersome at
> > reading time. It shifts their thought from "what this will do" to "in
> what
> > shape it will be".
> >
> >
> >> maybe it looks likes c++, i did not think it was a concern
> >> as long as it respected desired behaviors of good error reporting,
> >
> > It IS a MAIN concern. In fact it is a concern that the Go
> > team explicitly stated as a reason why Go1 is generics free.
> >
> >> good readability,
> > It has **no** readability for all but c++/java conditioned
> > and is an inexhaustible source of confusion in other languages
> >
> >> ease of usage.
> > leading to ubiquitous C&P in java/c++ application of generic libs.
> >
> >> speed of compilation,
> > 

[go-nuts] go apps in Embedded linux - yocto

[R Srinivasan]

Anyone here using go apps in the embedded linux world? particularly yocto 
based systems? If so I am looking for guidance on the same. Thanks, srini

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

[go-nuts] Re: http client POST/GET.. will not save cookie before do redirect request

[Weeds Qian]

Thanks, that's solve my problem.

在 2018年9月12日星期三 UTC+8下午2:52:20，Volker Dobler写道：
>
> On Wednesday, 12 September 2018 06:28:12 UTC+2, Weeds Qian wrote:
>>
>> What did you expect to see?
>>
>> the cookie in response
>> What did you see instead?
>>
>> no cookie in response
>>
>>
>> --http tcp stream from wireshark 
>> -
>>
>> You can see that I only do the POST /login and the later is execute by 
>> http client implementation.
>>
>> From my point of view, I think the GET /home.html request should add the 
>> cookie from last response, but it didn't, since you don't do that, why 
>> don't just return the response to me instead of doing useless request cause 
>> we go the login page.
>>
>> POST /login HTTP/1.1
>> Host: 127.0.0.1:8081
>> User-Agent: Go-http-client/1.1
>> Content-Length: 28
>> Content-Type: application/x-www-form-urlencoded
>> Accept-Encoding: gzip
>>
>> username=admin&password=testHTTP/1.1 302 Found
>> Location: /home.html
>> Set-Cookie: 
>> user=MTUzNjY1NjA2MXxEdi1CQkFFQ180SUFBUkFCRUFBQUpfLUNBQUVHYzNSeWFXNW5EQW9BQ0hWelpYSnVZVzFsQm5OMGNtbHVad3dIQUFWaFpHMXBiZz09fKI-QQWYHP_ZywpgkIoDmTzL1eJhd7pk-i9FSUgwI89E;
>>  Path=/; HttpOnly
>> Date: Tue, 11 Sep 2018 08:54:21 GMT
>> Content-Length: 0
>>
>>  
> There is your cookie.
>
> The problem is not that the cookie is not part of the response
> you get from /login but that you do not keep the cookie and
> send it on subsequent requests:
>
>>
>> GET /home.html HTTP/1.1
>> Host: 127.0.0.1:8081
>> User-Agent: Go-http-client/1.1
>> Content-Type: application/x-www-form-urlencoded
>> Referer: http://127.0.0.1:8081/login
>> Accept-Encoding : gzip
>>
>>
> You see: No Cookie header here.
>
> To record Set-Cookie headers and generate appropriate Cookie headers
> from these set cookies you probably should use your own instance of
> net/http.Client with a non-nil Jar and use that client to Do a POST 
> request.
> You can create a Jar via net/http/cookiejar.New.
> If you are going to use this on arbitrary domains please consider setting
> the Jar's PublicSuffixList to e.g. golang.org/x/net/publicsuffix.List
>
> V.
>
>

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

[go-nuts] Re: I am not in favor of generics.

[prades . marq]

Anyone who doesn't want some form of generics is in favor of a bad status 
quo. Now I'll be fine without user defined generics if Go provided a dozens 
of built-in compile time safe generic data structures like trees, sets, 
tuples, ordered maps, weakmaps perhaps WITH a complete set of methods like 
map/reduce/filter/... it would be a good compromise. 

I'd be fine, if generics could only be functions as well and not structs 
with generic methods.

But the whole, "just use interface {}" gimmick in a statically typed 
language? NO.

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

Re: [go-nuts] Re: I am not in favor of generics.

[Robert Engels]

Also, I did read what you wrote. I questioned “what happens when you have N 
different generic types in the call signature. The select type statement has 
N*N cases. “. You did not respond. 

On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki  wrote:

>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
> 
> The **stated** goal for adding some kind of generics to Go is
> and always was "how to not repeat writing same code just for a type".
> 
> Now above practical goal, in minds of many, somewhat morphed
> to "Yeah, lets have real true generics so we can write/reuse
> smart and clever code we once upon a time wrote for c++/java".
> "So we need a way of expressing generic data in terms of other
> generic data then use abstract alghoritm on that". 
> (Yep, team's proposal use: "in terms of operations")
> 
> It now poisons all the proposals I've seen with syntax that
> forces **user** of the code to **repeat** at the **call site**
> type identifier for the sake of "code instantiation".
> 
> Why? I think that's a mark of "one proper way for doing generics" burnt
> on the popular mindset. As hard to overcome as notion that one needs
> 'implements/implementing' to use interfaces.
> 
> Does Go2 should have "implements" keyword added too?
> `type mytype struct{...} : implements io.Writer, ..., ...`
> 
> What?! "Compiler knows whether your type satisfies an interface"
> 
> Yeah, and at the call site compiler **does know** the parameter
> type too. This is the CGG basis.
> 
> 
> 1. Find a way to write "some Go code" that is suitable for set of
> types that have "something" in common.
> 
> 2. Find a way to describe the set via the "something common" 
> that implementation for said set will use on objects of matching types.
> 
> 3. It **MUST** read as Go: no instantiation at call site.
> 
> 
> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> mhhc...@gmail.com wrote:
> 
>> I was referring to this code
>> 
>> func (x type []K) Sum() (r type K) { 
>> } 
>> 
> 
>> I did not understand how "// For var x []AnyType. ANY. " relates to 
>> previous code.
> 
> Previous code example was specific to `big.Int` type. Next I gave
> a really generic usage example via the constraint that already is
> described in CGG proposal: "type with given method implemented".
> 
> With that constraint func Sum can be called on _any_ type that has
> a method (*T) Add(T,T). And someone writing new code needs not to
> change generic lib (as imputed), but she needs to provide for her
> non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> 
>> for your question about the rune, i guess it d be like this 
> [...] 
>> Consider Z,K as virtual types to be inferred from the call site. 
> Progress! As to inferred :)
> 
> But I wanted return to be a string with sum of runes from all
> input strings :) Leave it.
> 
> In CGG such specialization takes place in a single to find and simple
> to **read** 'case' code. The proposal's example Sum already has a single
> piece of code that will be **reused** for all numerical types that user
> **might** declare off builtin. With only two for type cases CGG's generic
> Sum spans all types with numerical base and all types that provide their own
> "me plus operator". With one case more it allows for set of types that have
> "plus me operator". Code that can and will run for multitude of user types.
> 
> Yet I still hear stubborn "not reusable!, not reusable! not generic!". 
> 
>> In regards to Russ Cox proposal this code is missing 
>> their explicitly declared contracts and the function instances declaration.
>> On the other hand, this is so much more readable *to me*.
> 
> The "real true generics" proposals are readable to people who took the
> time and the training to accommodate to such List>
> syntactical mess. But it is **against** Go philosophy of "readability first".
> It excludes the legion who finds mental instantiations cumbersome at
> reading time. It shifts their thought from "what this will do" to "in what
> shape it will be".
> 
> 
>> maybe it looks likes c++, i did not think it was a concern 
>> as long as it respected desired behaviors of good error reporting, 
> 
> It IS a MAIN concern. In fact it is a concern that the Go
> team explicitly stated as a reason why Go1 is generics free.
> 
>> good readability,
> It has **no** readability for all but c++/java conditioned
> and is an inexhaustible source of confusion in other languages 
> 
>> ease of usage.
> leading to ubiquitous C&P in java/c++ application of generic libs.
> 
>> speed of compilation, 
> [I assume it was not about c++ compiling]
> 
> With CGG a single significant change to current gc parsing will
> be in marking 'func' node so parser could swap the subtree when
> it will see 'for type' while in declaration body.  
> 
> The only bigger chunk of new code in gc will be for contract
> parsing and matching. Everything else needed for fast CGG
> implementation already is working in the current gc.
> 
> [ c++ and like app

Re: [go-nuts] Re: I am not in favor of generics.

[Robert Engels]

Go not having implements is a big problem when refactoring large Go systems 
especially because it doesn’t have generics - all type safety is gone and you 
fly by the seat of your pants. 

On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki  wrote:

>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
> 
> The **stated** goal for adding some kind of generics to Go is
> and always was "how to not repeat writing same code just for a type".
> 
> Now above practical goal, in minds of many, somewhat morphed
> to "Yeah, lets have real true generics so we can write/reuse
> smart and clever code we once upon a time wrote for c++/java".
> "So we need a way of expressing generic data in terms of other
> generic data then use abstract alghoritm on that". 
> (Yep, team's proposal use: "in terms of operations")
> 
> It now poisons all the proposals I've seen with syntax that
> forces **user** of the code to **repeat** at the **call site**
> type identifier for the sake of "code instantiation".
> 
> Why? I think that's a mark of "one proper way for doing generics" burnt
> on the popular mindset. As hard to overcome as notion that one needs
> 'implements/implementing' to use interfaces.
> 
> Does Go2 should have "implements" keyword added too?
> `type mytype struct{...} : implements io.Writer, ..., ...`
> 
> What?! "Compiler knows whether your type satisfies an interface"
> 
> Yeah, and at the call site compiler **does know** the parameter
> type too. This is the CGG basis.
> 
> 
> 1. Find a way to write "some Go code" that is suitable for set of
> types that have "something" in common.
> 
> 2. Find a way to describe the set via the "something common" 
> that implementation for said set will use on objects of matching types.
> 
> 3. It **MUST** read as Go: no instantiation at call site.
> 
> 
> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> mhhc...@gmail.com wrote:
> 
>> I was referring to this code
>> 
>> func (x type []K) Sum() (r type K) { 
>> } 
>> 
> 
>> I did not understand how "// For var x []AnyType. ANY. " relates to 
>> previous code.
> 
> Previous code example was specific to `big.Int` type. Next I gave
> a really generic usage example via the constraint that already is
> described in CGG proposal: "type with given method implemented".
> 
> With that constraint func Sum can be called on _any_ type that has
> a method (*T) Add(T,T). And someone writing new code needs not to
> change generic lib (as imputed), but she needs to provide for her
> non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> 
>> for your question about the rune, i guess it d be like this 
> [...] 
>> Consider Z,K as virtual types to be inferred from the call site. 
> Progress! As to inferred :)
> 
> But I wanted return to be a string with sum of runes from all
> input strings :) Leave it.
> 
> In CGG such specialization takes place in a single to find and simple
> to **read** 'case' code. The proposal's example Sum already has a single
> piece of code that will be **reused** for all numerical types that user
> **might** declare off builtin. With only two for type cases CGG's generic
> Sum spans all types with numerical base and all types that provide their own
> "me plus operator". With one case more it allows for set of types that have
> "plus me operator". Code that can and will run for multitude of user types.
> 
> Yet I still hear stubborn "not reusable!, not reusable! not generic!". 
> 
>> In regards to Russ Cox proposal this code is missing 
>> their explicitly declared contracts and the function instances declaration.
>> On the other hand, this is so much more readable *to me*.
> 
> The "real true generics" proposals are readable to people who took the
> time and the training to accommodate to such List>
> syntactical mess. But it is **against** Go philosophy of "readability first".
> It excludes the legion who finds mental instantiations cumbersome at
> reading time. It shifts their thought from "what this will do" to "in what
> shape it will be".
> 
> 
>> maybe it looks likes c++, i did not think it was a concern 
>> as long as it respected desired behaviors of good error reporting, 
> 
> It IS a MAIN concern. In fact it is a concern that the Go
> team explicitly stated as a reason why Go1 is generics free.
> 
>> good readability,
> It has **no** readability for all but c++/java conditioned
> and is an inexhaustible source of confusion in other languages 
> 
>> ease of usage.
> leading to ubiquitous C&P in java/c++ application of generic libs.
> 
>> speed of compilation, 
> [I assume it was not about c++ compiling]
> 
> With CGG a single significant change to current gc parsing will
> be in marking 'func' node so parser could swap the subtree when
> it will see 'for type' while in declaration body.  
> 
> The only bigger chunk of new code in gc will be for contract
> parsing and matching. Everything else needed for fast CGG
> implementation already is working in the current gc.
> 
> [ c++ and like approa

Re: [go-nuts] Re: I am not in favor of generics.

[Wojciech S. Czarnecki]

> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:

The **stated** goal for adding some kind of generics to Go is
and always was "how to not repeat writing same code just for a type".

Now above practical goal, in minds of many, somewhat morphed
to "Yeah, lets have real true generics so we can write/reuse
smart and clever code we once upon a time wrote for c++/java".
"So we need a way of expressing generic data in terms of other
generic data then use abstract alghoritm on that". 
(Yep, team's proposal use: "in terms of operations")

It now poisons all the proposals I've seen with syntax that
forces **user** of the code to **repeat** at the **call site**
type identifier for the sake of "code instantiation".

Why? I think that's a mark of "one proper way for doing generics" burnt
on the popular mindset. As hard to overcome as notion that one needs
'implements/implementing' to use interfaces.

Does Go2 should have "implements" keyword added too?
`type mytype struct{...} : implements io.Writer, ..., ...`

What?! "Compiler knows whether your type satisfies an interface"

Yeah, and at the call site compiler **does know** the parameter
type too. This is the CGG basis.


1. Find a way to write "some Go code" that is suitable for set of
types that have "something" in common.

2. Find a way to describe the set via the "something common" 
that implementation for said set will use on objects of matching types.

3. It **MUST** read as Go: no instantiation at call site.


On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
mhhc...@gmail.com wrote:

> I was referring to this code
> 
> func (x type []K) Sum() (r type K) { 
> } 
> 

> I did not understand how "// For var x []AnyType. ANY. " relates to 
> previous code.

Previous code example was specific to `big.Int` type. Next I gave
a really generic usage example via the constraint that already is
described in CGG proposal: "type with given method implemented".

With that constraint func Sum can be called on _any_ type that has
a method (*T) Add(T,T). And someone writing new code needs not to
change generic lib (as imputed), but she needs to provide for her
non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.

> for your question about the rune, i guess it d be like this 
[...] 
> Consider Z,K as virtual types to be inferred from the call site. 
Progress! As to inferred :)

But I wanted return to be a string with sum of runes from all
input strings :) Leave it.

In CGG such specialization takes place in a single to find and simple
to **read** 'case' code. The proposal's example Sum already has a single
piece of code that will be **reused** for all numerical types that user
**might** declare off builtin. With only two for type cases CGG's generic
Sum spans all types with numerical base and all types that provide their own
"me plus operator". With one case more it allows for set of types that have
"plus me operator". Code that can and will run for multitude of user types.

Yet I still hear stubborn "not reusable!, not reusable! not generic!". 

> In regards to Russ Cox proposal this code is missing 
> their explicitly declared contracts and the function instances declaration.
> On the other hand, this is so much more readable *to me*.

The "real true generics" proposals are readable to people who took the
time and the training to accommodate to such List>
syntactical mess. But it is **against** Go philosophy of "readability first".
It excludes the legion who finds mental instantiations cumbersome at
reading time. It shifts their thought from "what this will do" to "in what
shape it will be".


> maybe it looks likes c++, i did not think it was a concern 
> as long as it respected desired behaviors of good error reporting, 

It IS a MAIN concern. In fact it is a concern that the Go
team explicitly stated as a reason why Go1 is generics free.

> good readability,
It has **no** readability for all but c++/java conditioned
and is an inexhaustible source of confusion in other languages 

> ease of usage.
leading to ubiquitous C&P in java/c++ application of generic libs.

> speed of compilation, 
[I assume it was not about c++ compiling]

With CGG a single significant change to current gc parsing will
be in marking 'func' node so parser could swap the subtree when
it will see 'for type' while in declaration body.  

The only bigger chunk of new code in gc will be for contract
parsing and matching. Everything else needed for fast CGG
implementation already is working in the current gc.

[ c++ and like approach ]
> proven useful
Proven as a source of confusion and bugs in analysis
linked above in thread (thanks for the link, Robert :).

> and workable etc
Workable and ubiquitous. Like 'implements' before Go.

> Anyways, I am polluting the thread against this proposal, sorry for that.

It is not a pollution, really. I am glad I can discuss both "we need no
generics" and "we need practical approach" topics with avid users of
c++/java style generics. It may show