Re: [go-nuts] Golang equivalent of Python's context manager

[Justin Israel]

On Thu, Sep 13, 2018, 10:13 AM Mirko Friedenhagen 
wrote:

> Thanks again. I think some of the use cases, especially those which
> implement some kind of finally (which includes locking use case) may just
> be implemented with simple functions. At least throwing exceptions is a
> rare event in Golang (panicking is what I meant with rare).
>
> Are closures, like the one in the main method idiomatic?
>

I don't see why not.
Also when I was using the boltdb api, I found it relies heavily on passing
function closures to the view and batch functions. The signature of the
function can be minimal like just returning and error, and you can capture
arbitrary return values just by declaring them in the outer scope and
setting them in the closure.


> --
> You received this message because you are subscribed to the Google 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] Re: http client POST/GET.. will not save cookie before do redirect request

[Weeds Qian]

If you look at my sample code, you should know I only send one request by 
http.POST, the following request is done by golang http client automaticly, 
not issue by myself. 

You got the point , why the http client do that without cookie from last 
response, that's what I am asking

在 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=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.

Re: [go-nuts] Go memory usage inside containers

[robert engels]

This may be of interest.

https://lists.linuxfoundation.org/pipermail/containers/2012-May/029798.html 


https://www.spinics.net/lists/cgroups/msg16842.html 

https://github.com/lxc/lxcfs/issues/44 

so it doesn’t look like it will happen in base linux, but looks like lxc 
already does this.

> On Sep 12, 2018, at 6:03 PM, Wojciech S. Czarnecki  wrote:
> 
> On Tue, 11 Sep 2018 23:48:03 -0700 (PDT)
> Leigh McCulloch  wrote:
> 
>> Hi,
>> 
>> Does anyone here know how Go interacts with memory limits inside
>> containers? (e.g. Kubernetes, Docker)
> 
> Real box info - parse /proc/meminfo
> Inside Docker: use stats via socket. Mount /var/run/docker.sock into your
> container
> and push docker stats over it then from Go read live data from it:
> 
> docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker stats
> 
> See: https://docs.docker.com/config/containers/runmetrics/
> 
> IDNK current vmware, but eg Paralels containers can be run with /proc/meminfo
> virtualzed. i.e. giving info just about instance.
> 
>> Thanks,
>> Leigh
>> 
> 
> -- 
> 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.

-- 
You received this message because you are subscribed to the Google 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] Scrapping contracts (was: "Generics as bultin typeclasses")

[robert engels]

I think the idea of ‘field accessors’ is kind of scary. It is used all of the 
time in Java, but it happens there because Java has classes , so the generic 
can use a base class as a type - although most people do not do this for 
obvious reasons.

Go interfaces only have methods. If generics are based on interfaces, which 
they should be IMO, then you would need to add fields to interfaces. Poor 
choice IMO, and usually because the developer doesn’t spend enough time 
thinking about what the interface represents.

given the color example, why would I have Red,Grren, Blue, Opacity all as 
fields? When if I had a GetColor() method, then I can use composition to blend 
colors on the fly, etc. With direct field access this is not possible.

> On Sep 12, 2018, at 6:01 PM, Jonathan Amsterdam  wrote:
> 
> Not to be snide, but we are looking for examples, not kinds of examples. Do 
> you know of actual code where this would benefit?
> 
> For example, could field accessors improve the standard image and image/color 
> packages? 
> 
> On Wednesday, September 12, 2018 at 9:15:24 AM UTC-4, Mandolyte wrote:
> On field accessors...
> - Algorithms for X,Y points requiring them to be members of a struct type.
> 
> - Algorithms to manipulate colors, requiring R,G, and B to be members.
> 
> In an image processing library with its own rich set of struct types, such 
> accessors would prove productive.
> 
> Are these the kind of examples you meant?
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google 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] Go memory usage inside containers

[Wojciech S. Czarnecki]

On Tue, 11 Sep 2018 23:48:03 -0700 (PDT)
Leigh McCulloch  wrote:

> Hi,
> 
> Does anyone here know how Go interacts with memory limits inside
> containers? (e.g. Kubernetes, Docker)

Real box info - parse /proc/meminfo
Inside Docker: use stats via socket. Mount /var/run/docker.sock into your
container
and push docker stats over it then from Go read live data from it:
 
docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker stats

See: https://docs.docker.com/config/containers/runmetrics/

IDNK current vmware, but eg Paralels containers can be run with /proc/meminfo
virtualzed. i.e. giving info just about instance.

> Thanks,
> Leigh
> 

-- 
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] Scrapping contracts (was: "Generics as bultin typeclasses")

[Jonathan Amsterdam]

Not to be snide, but we are looking for examples, not kinds of examples. Do 
you know of actual code where this would benefit?

For example, could field accessors improve the standard image and 
image/color packages? 

On Wednesday, September 12, 2018 at 9:15:24 AM UTC-4, Mandolyte wrote:
>
> On field accessors... 
>
> - Algorithms for X,Y points requiring them to be members of a struct type.
>
> - Algorithms to manipulate colors, requiring R,G, and B to be members.
>
> In an image processing library with its own rich set of struct types, such 
> accessors would prove productive.
>
> Are these the kind of examples you meant?
>
>

-- 
You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[Mirko Friedenhagen]

Thanks again. I think some of the use cases, especially those which implement 
some kind of finally (which includes locking use case) may just be implemented 
with simple functions. At least throwing exceptions is a rare event in Golang 
(panicking is what I meant with rare).

Are closures, like the one in the main method idiomatic?

-- 
You received this message because you are subscribed to the Google 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 memory usage inside containers

[Henrik Johansson]

taskset works for sure and I managed to crash a program with ulimit.
I thought these stuff was what the container runtimes used under the hood.
Am I missing something?

ons 12 sep. 2018 kl 16:14 skrev Ian Lance Taylor :

> On Wed, Sep 12, 2018 at 7:07 AM, robert engels 
> wrote:
> > With the Azul VM (and I believe the G1 collector in Java), the VM is
> definitely aware of memory pressure as it approaches the maximum limit -
> then it will increase the concurrent GC activity trying to avoid a
> potential huge pause if the limit was reached - so throughput is lowered.
> >
> > I would think the Go GC needs to do this as well in order to limit pause
> times.
>
> That does not sound precisely correct to me.  The Go GC pause time is
> independent of the heap size, and I would expect that Java's pause
> time is as well.  It's certainly true that Go could run the GC harder
> when coming closer to a memory limit, which will tend to starve the
> program, but it won't actually pause the program.  As I mentioned
> earlier, though, when the program is coming close to its memory
> limits, it needs to react.  If it's a network server, it needs to stop
> accepting new connections.  If it has cached data, it needs to discard
> it.  And so forth.  The GC can try harder but if the program keeps
> allocating more memory there is nothing the GC can do to save it.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> 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] Re: Go modules: go get installs binary

['Bryan Mills' via golang-nuts]

Per the documentation 
, “Get resolves and 
adds dependencies to the current development module and then builds and 
installs them.”

If you want it to only update dependencies, use the -m flag; to only update 
and download, use -d.


On Sunday, September 9, 2018 at 8:59:47 AM UTC-4, asv...@gmail.com wrote:
>
> Does it correct that go get (with modules enabled) installs binary. I 
> thought it must only download / update dependencies in modules mode?
>

-- 
You received this message because you are subscribed to the Google 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] Generics - Min challenge

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 10:05:06 -0700
Ian Lance Taylor  wrote:

> a compile-time decision as to which code should be compiled.
Note that this decision making is needed only for outstanding cases
usually in user own code. For many generic implementation a simple
for type contract is enough:

// Sum method 

func (x type []K) Sum() (total type K) {
for type K range int64(), float64(), complex128() // whole contract

for _, v := range x {
  total += v.Value
}
return
}

Sum func differs only in signature:

func Sum(x type []K) (total type K) {

> 
> Ian

-- 
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] Golang equivalent of Python's context manager

[Justin Israel]

For about the same amount of typing that you have to do to create a closure
for using with a predefined WithContext handler, I tend to do this inline:

func start() { fmt.Println("start") }
func stop() { fmt.Println("stop") }

func main() {
func() (string, error) {
start()
defer stop()
fmt.Println("run")
return "hi", nil
}()
}

https://play.golang.org/p/3B63iTY4pla

It means I can return any signature, as long as I have the enter/exit
functions defined already.

Justin

On Thu, Sep 13, 2018, 7:35 AM Sam Whited  wrote:

> On Wed, Sep 12, 2018, at 14:12, Mirko Friedenhagen wrote:
> > However, coming from Java lately, retrieving a DB-connection from a
> pool,
> > opening a transaction and committing/aborting and returningafterwards
> seems
> > something which could be handled with such a construct. How would you do
> > this in Golang?
>
> I frequently do something similar to this:
>
> https://gist.github.com/SamWhited/d81d081aed0351a1c1d128acf3a16b5c
>
> (there may be some extra parameters, I cut out some row-level-security
> stuff from something being used in prod and pasted everything into the gist
> without really checking it)
>
> —Sam
>
> --
> You received this message because you are subscribed to the Google 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] Generics - Min challenge

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 10:05:06 -0700
Ian Lance Taylor  wrote:

> I agree that no code is produced by the program, but you're suggesting
> a compile-time decision as to which code should be compiled.  

How does it differ from unused code eliding go compiler and linker do
already? Used `for type case` code will compile and run. Unused will be
elided, just a bit earlier.

> but it is something unlike what can be done in Go today.

I thought we're discussing changes. And if we're at it, "Craftsman's
proposal" adds almost **no new[1] concepts** to the language.
Adds no new keywords. 
`For type` constraints can be checked with current compiler.
Old Go1 code can use future generic version of current library
without touching a comma: If it calls r := util.Min(a, b) for ints now,
it will be calling generic Min as r := util.Min(a, b) not even knowing
that Min is now string, FooBoos and Mermaids capable. 

[1] the actual **single** new thing in the user's code is a generic method
call via package selector:

r := a.util.Min(b) // calls generic Min from util package.

New things in CGG **generic code** are:
- (x type T) declarations (as in team's proposal)
- `for type` contract
- `for type` switch
- a bunch of constrains. But ALL for type constraints are based
  on already familiar Go type definitions and casts. 

> 
> Ian

TC,

-- 
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] golang gRPC question

[Robert Engels]

The streaming mechanism seems to be the solution. Appears to be how cockroachdb 
does it. 

Sent from my iPhone

> On Sep 12, 2018, at 2:47 PM, Josh Humphries  wrote:
> 
> 
>> On Wed, Sep 12, 2018 at 9:05 AM robert engels  wrote:
>> Hi, I am adding a remote component to my github.com/robaho/keydb project and 
>> decided to use gRPC.
>> 
>> I’ve reviewed the docs, and it appears to want to be stateless - which given 
>> the nature of Google makes sense.
>> 
>> But for something like a database connection, where there could be 
>> substantial connection setup costs that you wouldn’t want to pay on every 
>> request, what is the best way to accomplish this with gRPC?
>> 
>> There are issues like https://github.com/grpc/grpc-go/issues/297 that are 
>> closed with no resolution ???
>> 
>> There doesn’t seem to be a way to access the connection state on the server 
>> - to know the associated user, register a close handler, etc.
>> 
>> The only solutions I see is are
>> 
>> 1) that the client must send heartbeat message, if the server doesn’t 
>> receive a heartbeat in X, clean-up the connection, AND the client must send 
>> a connectionID along with every request (but even this seems problematic for 
>> security reasons).
>> 
>> 2) use the bidirectional streaming mode, and so the connection is treated as 
>> one long stream of messages in and out, and when the rpc finishes the 
>> connection is cleaned up
> 
> I think you want this mechanism -- the stream. Since gRPC clients assume 
> statelessness, approach #1 will not only need some keep-alive mechanism, but 
> it also requires "smart" routing/affinity, so that all requests for the same 
> "connection ID" get routed on the same socket. Otherwise, you will not be 
> able to do any sort load balancing, since different requests can be scattered 
> to different backends. With a single stream, all messages sent on the stream 
> will be destined for the same backend. For an example of a bidi streaming RPC 
> call that sends/receives sequential request-response pairs on its stream, 
> checkout service reflection.
> 
> On a separate note: I've actually started toying around with a library for 
> "tunneling" with gRPC. This library would provide helpers to wrap a 
> protoc-generated stream interface in a more user-friendly API, if you choose 
> to define a streaming endpoint similar to reflection. But it also provides 
> the ability to create a "tunnel" from client to server that acts like a 
> normal gRPC connection but guarantees that all requests are always routed to 
> the same server (basically, gRPC-over-gRPC). It will even support "reverse 
> tunnels", where a gRPC server can act as a client to invoke services exposed 
> by the gRPC client. If any of that is interesting to you, let me know, and I 
> can share some in-progress code with you.
>  
>> 
>> Is there an example of this type of usage someone can point me 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.
>> 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] golang gRPC question

[Josh Humphries]

On Wed, Sep 12, 2018 at 9:05 AM robert engels  wrote:

> Hi, I am adding a remote component to my github.com/robaho/keydb project
> and decided to use gRPC.
>
> I’ve reviewed the docs, and it appears to want to be stateless - which
> given the nature of Google makes sense.
>
> But for something like a database connection, where there could be
> substantial connection setup costs that you wouldn’t want to pay on every
> request, what is the best way to accomplish this with gRPC?
>
> There are issues like https://github.com/grpc/grpc-go/issues/297 that are
> closed with no resolution ???
>
> There doesn’t seem to be a way to access the connection state on the
> server - to know the associated user, register a close handler, etc.
>
> The only solutions I see is are
>
> 1) that the client must send heartbeat message, if the server doesn’t
> receive a heartbeat in X, clean-up the connection, AND the client must send
> a connectionID along with every request (but even this seems problematic
> for security reasons).
>
> 2) use the bidirectional streaming mode, and so the connection is treated
> as one long stream of messages in and out, and when the rpc finishes the
> connection is cleaned up
>

I think you want this mechanism -- the stream. Since gRPC clients assume
statelessness, approach #1 will not only need some keep-alive mechanism,
but it also requires "smart" routing/affinity, so that all requests for the
same "connection ID" get routed on the same socket. Otherwise, you will not
be able to do any sort load balancing, since different requests can be
scattered to different backends. With a single stream, all messages sent on
the stream will be destined for the same backend. For an example of a bidi
streaming RPC call that sends/receives sequential request-response pairs on
its stream, checkout service reflection

.

On a separate note: I've actually started toying around with a library for
"tunneling" with gRPC. This library would provide helpers to wrap a
protoc-generated stream interface in a more user-friendly API, if you
choose to define a streaming endpoint similar to reflection. But it also
provides the ability to create a "tunnel" from client to server that acts
like a normal gRPC connection but guarantees that all requests are always
routed to the same server (basically, gRPC-over-gRPC). It will even support
"reverse tunnels", where a gRPC server can act as a client to invoke
services exposed by the gRPC client. If any of that is interesting to you,
let me know, and I can share some in-progress code with you.


>
> Is there an example of this type of usage someone can point me 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.
> 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] Golang equivalent of Python's context manager

[Sam Whited]

On Wed, Sep 12, 2018, at 14:12, Mirko Friedenhagen wrote:
> However, coming from Java lately, retrieving a DB-connection from a pool, 
> opening a transaction and committing/aborting and returningafterwards seems 
> something which could be handled with such a construct. How would you do 
> this in Golang?

I frequently do something similar to this:

https://gist.github.com/SamWhited/d81d081aed0351a1c1d128acf3a16b5c

(there may be some extra parameters, I cut out some row-level-security stuff 
from something being used in prod and pasted everything into the gist without 
really checking it)

—Sam

-- 
You received this message because you are subscribed to the Google 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: golang gRPC question

[Tamás Gulácsi]

2018. szeptember 12., szerda 15:05:43 UTC+2 időpontban Robert Engels a 
következőt írta:
>
> Hi, I am adding a remote component to my github.com/robaho/keydb project 
> and decided to use gRPC.
>
> I’ve reviewed the docs, and it appears to want to be stateless - which 
> given the nature of Google makes sense.
>
> But for something like a database connection, where there could be 
> substantial connection setup costs that you wouldn’t want to pay on every 
> request, what is the best way to accomplish this with gRPC?
>
> There are issues like https://github.com/grpc/grpc-go/issues/297 that are 
> closed with no resolution ???
>
> There doesn’t seem to be a way to access the connection state on the 
> server - to know the associated user, register a close handler, etc.
>
> The only solutions I see is are
>
> 1) that the client must send heartbeat message, if the server doesn’t 
> receive a heartbeat in X, clean-up the connection, AND the client must send 
> a connectionID along with every request (but even this seems problematic 
> for security reasons).
>
> 2) use the bidirectional streaming mode, and so the connection is treated 
> as one long stream of messages in and out, and when the rpc finishes the 
> connection is cleaned up
>
> Is there an example of this type of usage someone can point me to?
>
>
1) is the only usable way, as I see. What's the security concern? 

-- 
You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[Mirko Friedenhagen]

First of all, thanks for all the answers. A standard use case in Python is 
to use with the a closing context manager which will just call close on a 
given object. That one could be easily done with a defer statement. 
However, coming from Java lately, retrieving a DB-connection from a pool, 
opening a transaction and committing/aborting and returningafterwards seems 
something which could be handled with such a construct. How would you do 
this in Golang?

Am Mittwoch, 12. September 2018 15:37:12 UTC+2 schrieb Robert Engels:
>
> Agree it can be done - not sure I would want to maintain that in a large 
> system as you are paying the LOC penalty at every call site. Seems easier 
> to just add the context callback in the methods themselves so then you are 
> in control of the code penalty.
>
> On Sep 12, 2018, at 8:17 AM, Sebastien Binet > 
> wrote:
>
>
>
> On Wed, Sep 12, 2018 at 2:55 PM robert engels  > wrote:
>
>> Ok, now the coffee has kicked in, and it still has problems, because you 
>> cannot call a method and use a return value other than error without 
>> multiple signatures, unless you move all of the return values outside of 
>> the closure - like his example does with var a. 
>>
>
>> This would be extremely tedious (and probably error prone) to use IMO, 
>> especially with Go’s multiple return values.
>>
>
> one has to be careful, yes. but it's not completely out of reach.
>
> func Foo(a, b int) (int, error) { ... }
>
> func Do() {
> var out = 0
> With(ctx, func() error {
> var err error
> out, err = Foo(42, 66)
> return err
> })
> }
>
> closures are great! (like fezzes and bowties, actually :P)
>
> -s
>  
>
>>
>> On Sep 12, 2018, at 7:50 AM, robert engels > > wrote:
>>
>> Too early, and the coffee had not kicked in...
>>
>> On Sep 12, 2018, at 7:49 AM, robert engels > > wrote:
>>
>> Yes, you are correct. My bad :)
>>
>> On Sep 12, 2018, at 7:34 AM, Sebastien Binet > 
>> wrote:
>>
>>
>>
>> On Wed, Sep 12, 2018 at 2:23 PM robert engels > > wrote:
>>
>>> I am pretty sure that is not correct, I am referring to:
>>>
>>> func WithContext(context Context, f func() error) error {
>>> context.__entry__()
>>> defer context.__exit__()
>>> return f()
>>> }
>>>
>>>
>>> You will need a lot of WithContext methods - based on the different 
>>> signatures of function f.
>>>
>>> See the main method… I am assuming this is attempting to be a general 
>>> facility - and thus the signature of f will vary.
>>>
>>
>> you just need to wrap it with a closure, just as Eric did:
>>
>> e.g.:
>>  func QueryDB(a,b int) error { ... }
>>  
>>  WithContext(ctx, func() error {
>> return QueryDB(42, 666)
>>  })
>>
>> and voila.
>>
>> -s
>>
>>
>>
>> -- 
>> You received this message because you are subscribed 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...@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] Re: Generic types - functions and methods on instantions

[Patrick Smith]

On Wed, Sep 12, 2018 at 7:49 AM Ian Lance Taylor  wrote:

> On Tue, Sep 11, 2018 at 5:38 PM, Patrick Smith 
> wrote:
> > First, please consider requiring the 'type' keyword in definitions of
> > methods on generic types:
> >
> > func (x Foo(type T)) method() {}
> >
> Interesting idea, but even if we adopt specialization it seems to me
> that an ordinary non-specialized method is the normal case, and a
> method specialized to a specific type is the unusual case.  We should
> try to avoid making the normal case be more verbose.
>

My own preference would be to require the keyword. But this is a very minor
point and definitely not worth arguing about at this stage, so I've added a
note to the feedback page and will now shut up about it.

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

Re: [go-nuts] Generics - Min challenge

[Patrick Smith]

On Wed, Sep 12, 2018 at 6:34 AM Ian Lance Taylor  wrote:

> That said, if we move forward with something like contracts, I think
> that it may be possible to introduce contract adaptors in the future:
> a mechanism that says "if the type argument does not implement
> contract C1, but does implement contract C2, then use this code to
> implement the requirements of C1 in terms of C2."  This sort of
> automatically applied adaptor code seems to me to be less potentially
> confusing than metaprogramming.  Maybe.  I'm not at all sure.
>

Yes.

I've been toying (just in my head) with an idea for using adaptors instead
of contracts, and then building support into the language for automatically
choosing a default adaptor. I guess I'll have to write up the idea so
people can evaluate it. That will take a day or three.

-- 
You received this message because you are subscribed to the Google 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] A thought on contracts

[Larry Clapp]

>
> we should have a tool that, given a contract body, produces a minimal 
> contract body that expresses the same contract.


And run it on save, like gofmt.  Or just make it part of gofmt.

On Thursday, September 6, 2018 at 4:22:34 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips  > wrote: 
> > Interesting idea, but has the Go team expressed interest in creating 
> such a tool? 
>
> Yes, I think it's become clear that we should have a tool that, given 
> a contract body, produces a minimal contract body that expresses the 
> same contract.  I believe that if we are able to write a type checker 
> for the design draft, it will be a minor straightforward extension to 
> that code to produce such a tool. 
>
> And, of course, given such a tool, it's a trivial extension to take an 
> arbitrary function body and produce a minimal contract body for that 
> function.
>

-- 
You received this message because you are subscribed to the Google 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] A thought on contracts

[Ian Lance Taylor]

On Mon, Sep 10, 2018 at 5:32 AM, komuW  wrote:
>
> On Thursday, 6 September 2018 23:22:34 UTC+3, Ian Lance Taylor wrote:
>>
>> On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips  wrote:
>> > Interesting idea, but has the Go team expressed interest in creating
>> > such a tool?
>>
>> Yes, I think it's become clear that we should have a tool that, given
>> a contract body, produces a minimal contract body that expresses the
>> same contract.  I believe that if we are able to write a type checker
>> for the design draft, it will be a minor straightforward extension to
>> that code to produce such a tool.
>>
>> And, of course, given such a tool, it's a trivial extension to take an
>> arbitrary function body and produce a minimal contract body for that
>> function.
>>
>> Ian
>
>
> I think these words would have been very comforting if they were(or at least
> alluded to) in the original draft document.

Unfortunately we didn't know it then (hence my use of "it's become clear").

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.

Re: [go-nuts] Generics - Why contracts?

[Eric S. Raymond]

alanfo :
> I suspect that you could achieve 90% coverage with just 4 built-in 
> contracts: 
> 
> 
> 1. integer (any integer type) 
> 
> 2. real (any integer or floating point type)
> 
> 3. ordered (any integer, floating point or string type)
> 
> 4. comparable (any type which supports == and !=)

Experience with Python suggests two others:

5. indexable (indexable by integers)

6. maplike (supports indexing by any valid map key).

You would also want to make "ordered" applicable to any type that
can support a < relation, for sorting purposes.

I'm saying this from a lot of experience with Python's facility for
binding operators to class methods.  A lot of that facility turns out
to be decorative fluff. These parts are not.

I would be happy with this set of contracts.  It would certainly
fulfil Ian's goal of being able to write min() and max() as generics.

Yes, I would prefer this 90% to the elaborate, fragile schemes for
user-defined contracts that are under discussion.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
You received this message because you are subscribed to the Google 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] Contracts and fused multiply add

[jimmy frasche]

On Wed, Sep 12, 2018 at 11:02 AM Ian Lance Taylor  wrote:
> You could perhaps choose an implementation based on unsafe.Sizeof.
> But I agree that it's pretty ugly.

Only if the contract were t * t + t < .1

Part of the construction was that it accepted more than just floating points.

-- 
You received this message because you are subscribed to the Google 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] Contracts and fused multiply add

[Ian Lance Taylor]

On Wed, Sep 12, 2018 at 10:54 AM, jimmy frasche  wrote:
>
> Given a platform that supports the fused multiply add (FMA)
> instruction and the code:
>
>   contract MA(t T) {
> t * t + t
>   }
>
>   func ma(type T MA)(a, b, c T) T {
> return a*b + c
>   }
>
> Does the compiled-for-any-type version support the FMA optimization
> when called with a floating-point type?

I think that in practice it's going to be up to the compiler.  The
language spec permits but does not require using an FMA instruction
for the expression `x*y + z`.  Whether that specific expression
appears in a contract is going to be irrelevant.  If it appears in the
body of the generic function, the compiler may or may not recognize
it.


> If I specifically want to not use the optimization when instantiated
> with floats, can I do:
>
>   func maNoFMA(type T MA)(a, b, c T) T {
> return T(a*b) + c
>   }

Yes, adding an explicit type conversion always disables the use of
FMA, as explained in the language spec.  Again, that is independent of
whether the expression appears in the contract.


> If I need it to use the guaranteed FMA intrinsic (see
> https://github.com/golang/go/issues/25819 ) when instantiated with
> floats, I can't do
>
>   func maMustFMA(type T MA)(a, b, c T) T {
> switch a.(type) {
> case float32:
>   return T(math.Fma(
> float64(a.(float32)),
> float64(b.(float32)),
> float64(c.(float32)),
>   ))
> case float64:
>   return T(math.Fma(a.(float64), b.(float64), c.(float64)))
> }
> return a*b + c
>   }
>
> because that misses cases like
>   type Float float64
> so I have to use reflect which can't be dead-code eliminated during
> specialization.

You could perhaps choose an implementation based on unsafe.Sizeof.
But I agree that it's pretty ugly.

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] Contracts and fused multiply add

[jimmy frasche]

Given a platform that supports the fused multiply add (FMA)
instruction and the code:

  contract MA(t T) {
t * t + t
  }

  func ma(type T MA)(a, b, c T) T {
return a*b + c
  }

Does the compiled-for-any-type version support the FMA optimization
when called with a floating-point type?

If not, does a specialized version, making the two different based on
whether the compiler chooses to specialize the function?

If I specifically want to not use the optimization when instantiated
with floats, can I do:

  func maNoFMA(type T MA)(a, b, c T) T {
return T(a*b) + c
  }

If I need it to use the guaranteed FMA intrinsic (see
https://github.com/golang/go/issues/25819 ) when instantiated with
floats, I can't do

  func maMustFMA(type T MA)(a, b, c T) T {
switch a.(type) {
case float32:
  return T(math.Fma(
float64(a.(float32)),
float64(b.(float32)),
float64(c.(float32)),
  ))
case float64:
  return T(math.Fma(a.(float64), b.(float64), c.(float64)))
}
return a*b + c
  }

because that misses cases like
  type Float float64
so I have to use reflect which can't be dead-code eliminated during
specialization.

I'm sure there are other cases where similar questions could be asked,
but this seems like a good proxy for the whole class.

-- 
You received this message because you are subscribed to the Google 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] Generics - Min challenge

[Michael Jones]

Compile-time logic feels like a baby/bathwater issue to me.

With M4 and then CPP on the scene, new kinds of adaptable code became
possible in C. It was such a compelling benefit (I still have the CSTRs)
that it grew to ubiquity and finally to a monsterous horror in C++ that in
recent decades, through bost-style all-header code and huge
autoconfiguration, leads to source code where it is impossible to know by
inspection what source code is being compiled.

The benefits are still phenomenal but now the cost of obscurity is as
phenomenal. Go came to life in the time of backlash against such problems.
Even so. might we not consider the problems as "bathwater" and still love
the baby?

There is an inherent 'switch' in any kind of generality. It might be hidden
at compile time, as in the different meaning and opcode in addition of
"5+5" and "3.1+6.7", or at runtime type switches, or in magical JIT Java
compilation, or in the core Smalltalk message dispatch, or exposed nakedly
in "#ifdef", but it is still there. In generics it must still be there as
well, some way to say "to de-abstract this do X."

Might there not be a clean/clear/comprehensible, Go-worthy, way to specify
compile-time logic?

On Wed, Sep 12, 2018 at 10:05 AM Ian Lance Taylor  wrote:

> On Wed, Sep 12, 2018 at 7:49 AM, Wojciech S. Czarnecki 
> wrote:
> > On Wed, 12 Sep 2018 06:33:59 -0700
> > Ian Lance Taylor  wrote:
> >
> > Addenum:
> >
> >>  You need to have a way to say "compile this code under certain
> >> conditions based on the type argument, otherwise compile this code."
> >> That is, the compiler is directed, at compile time, as to which code
> >> should be compiled.  That is metaprogramming.
> >
> > This is not metaprogramming!
> >
> > Every and each statement is written by the human author in plain Go
> > and no code is produced by the program itself.
> >
> > https://en.wikipedia.org/wiki/Metaprogramming
>  Metaprogramming is a programming technique in which computer programs
> have
>  the ability to treat programs as their data. It means that a program
> can
>  be designed to read, generate, analyse or transform other programs,
> and
>  even modify itself while running.
>
> I agree that no code is produced by the program, but you're suggesting
> a compile-time decision as to which code should be compiled.  We don't
> have to call that metaprogramming if you don't want to, but it is
> something unlike what can be done in Go today.
>
> 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.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics - Why contracts?

[jake6502]

Some of the reasons for contracts have been covered by others in this 
thread already. But somehow one of the biggest has not. Contracts make it 
possible to change the implementation of a generic function in a published 
package. Without a contract it would be super easy for a seemingly simple 
change to a published generic function to break clients of that function. 
While not foolproof, the presence of a contract means that, if the contract 
does not change, then changes to the generic code should, minimally, not 
cause compilation errors in client code. And, if intelligently created, 
should offer a degree of confidence that such changes won't functionally 
break client code either. 

Personally, I don't expect they will be hard to write. After decades of 
experience with many languages, my gut tells me that the vast majority of 
contracts written by the vast majority of "general" programmers will be 
trivial. Easily written and read. More advanced contracts would be less 
common, but I suspect that common idioms will quickly emerge for the more 
advanced constraints.

I do have some concerns about reading more complicated contracts. However, 
that can be alleviated by reasonable line commenting of complicated 
contracts. Additionally, if the error messages for violating a constraint 
when calling generic function  are well crafted, that should make it even 
easier. But I would rather have to do some extra thinking on rare occasion, 
than have to learn some whole new language for contracts. 

As for:

It runs parallel to my concerns about language compactness, too.
>
 
Again, I predict  that most contracts will be a few lines long. Secondly, 
golang is not a language of compactness. Many of the design decisions make 
that clear. And idiomatic go favors clarity over brevity. It can be hard to 
adjust to, but overall it's a win. Finally, if you are writing so much 
generic code that the contracts are any appreciable percentage of your code 
base, then you are probably way off the rails anyway. 

My 2¢


On Tuesday, September 11, 2018 at 10:57:30 AM UTC-4, Jeff wrote:

> I am a semi-advanced hobbyist. I have a BSCEE degree, but no professional 
> programming experience.  I have been programming for > 30 years and have 
> written small programs in easily 20+ different languages during that time. 
>  So, while not a professional programmer, I am not exactly a novice.
>
> I've been following some of the contracts proposal discussions and frankly 
> I have been a bit lost.  I think I have a good handle on interfaces, but 
> this contracts stuff confuses me.  One of Go's strengths is that the 
> language is relatively easy to grasp.  The code is generally relatively 
> straightforward.  People seem to draft code that leans more toward 
> readability instead of toward "clever" but less easily understood.  I have 
> looked at the source code of many packages.  It is rare that I cannot 
> follow the code.  I cannot say this about many other languages.  My fear is 
> this contracts proposal will kill my ability to read and understood code of 
> others.
>
> I recall using generics many years ago in Ada and did not recall them 
> being so confusing.  So, I went back and looked at the Ada implementation. 
>  See, e.g., https://en.wikibooks.org/wiki/Ada_Programming/Generics 
> .
>  
>  Honestly, I find this general approach to be easier to follow than 
> contracts.  Based on the link, it has some similarities with C++ templates. 
>  I have some basic experience with C++, but I have no experience with C++ 
> templates.
>
> TLDR; So why contracts and not templates or something else?  Is there a 
> benefit to contracts that I don't appreciate (very likely, cause I don't 
> understand them)?  Are there issues with a template approach?  If this has 
> been addressed elsewhere, please provide links.  I'd like a better 
> understanding as to why the Go team has chosen to explore contracts over 
> other approaches.
>
> Jeff
>

-- 
You received this message because you are subscribed to the Google 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] Generics - Min challenge

[Ian Lance Taylor]

On Wed, Sep 12, 2018 at 7:49 AM, Wojciech S. Czarnecki  wrote:
> On Wed, 12 Sep 2018 06:33:59 -0700
> Ian Lance Taylor  wrote:
>
> Addenum:
>
>>  You need to have a way to say "compile this code under certain
>> conditions based on the type argument, otherwise compile this code."
>> That is, the compiler is directed, at compile time, as to which code
>> should be compiled.  That is metaprogramming.
>
> This is not metaprogramming!
>
> Every and each statement is written by the human author in plain Go
> and no code is produced by the program itself.
>
> https://en.wikipedia.org/wiki/Metaprogramming
 Metaprogramming is a programming technique in which computer programs have
 the ability to treat programs as their data. It means that a program can
 be designed to read, generate, analyse or transform other programs, and
 even modify itself while running.

I agree that no code is produced by the program, but you're suggesting
a compile-time decision as to which code should be compiled.  We don't
have to call that metaprogramming if you don't want to, but it is
something unlike what can be done in Go today.

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.

Re: [go-nuts] Generics - Min challenge

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 07:40:37 -0700
Ian Lance Taylor  wrote:

> The difference I see is that in one case we write code that can not be
> compiled, and then tell the compiler not to compile it.

> we direct the compiler to automatically insert wrappers that
> make the type fit the contract.

Who is supposed to write such wrapper, how does author of automata knows how
to make any type fit the contract? What if automata decides to "make type
fit" where author of the "unfit" contract **consciously** made her contract
in a way to get some possible type(s) excluded? (eg due to implementation
needs)

And most important: How I as a code reader can know what kind of wrappers
compiler may threw under the code that **I see**.

> We never write code that can not be compiled.
If an author of the `for type case` wrote the case she supposedly wrote a
test case for that branch. So she will see because this branch will be tried. 
[ 
If "We never write code that can not be compiled" referred to
  CGG proposal's constraint clauses, I wholeheartedly agree to get them in
  backticks and name it "constraint identifiers".
 Syntax highliters can cope with that, too 
]


> I understand if you disagree but I would hope that you can express
> your disagreement while avoiding language like "direction of doom."

I humbly apologize for heavy words, I did not meant them to be insult to
anyone.

I love Go for its simplicity. I love Go for its readability. I did not miss
generics much but I was happy seeing "generics proposal" from the team. 

I must admit that the idea of ‘lets infer constraint from a statement’
is so clever one. I see (or I think I see) how this approach can give
an easy, lightweight and fast path to get working compiler.

But now we are discussing contracts that are confusing even for developers
that cut their teeth on Go (often after decades in other languages).
Contracts that on one path say 'Generic Min is impossible' on other path
(Alex') says 'generic methods are not welcome nor needed'. 

So, this brilliant idea that recently gave hope unfortunately outputs
something that just does not read as Go, something that wrings my mind and
swirl around instead of just telling constraints straight.

Is it possible that it's abstruse only for me? 

That's why I am somewhat reluctant to back off on my doom premonitions, at
least entirely, at least now. I apologize again for heavy words. Don't take
them personally.

> Thanks.
> 
> Ian

TC

-- 
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] Generics "craftsman approach" proposal update

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 07:05:55 -0700
Ian Lance Taylor  wrote:

> I don't see a description of generic types, I only see generic functions.

CGG in its current shape does not allow for **declaring** generic named types
out of thin air. But it allows for instantiating such types
(now p 3.2 in draft):

// likely to be seen in generic package
func NewBarTuple(type T, type V) ( r type R ) {
var r = struct { a T; b V }
return
}

I am open to suggestions
 
> I don't understand how you handle a named type like `type MyInt int`.

MyInt in the contract scope "is assignable" to int via int(MyInt);
thats why the constraint is written **as a cast** [ T = TypeX() constraint ].

type MyInt int
var a MyInt
var b int
b = int(a)


> Such a type is neither identical to `int` nor assignable to `int`.
But if the base agrees it can be casted to. Hence "assignable to type()"

> You don't have a way of saying "convertible to `int`", and if you did
> it's not clear how it would handle, say, `float64`.

And I will likely not have "convertible to" because it needs from the reader
knowledge about peculiarities of any given conversion.

I am open to suggestions. Readability first.

(In fact I had convertible in my first sketch but I removed it
exactly because of float/int snafu memories)

The `for type` contract allows me to specify a method, so explicit function
like "ConvertTo" or "GetAs" are better **for reader**.

Constraint list is not closed. Only restriction on this list is that a
constrain (as for now) must be expressed as **known** Go
construct involving a type or part of it (ie field). No operators or code.

> 
> Ian

TC,

-- 
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] Generics - Min challenge

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 06:33:59 -0700
Ian Lance Taylor  wrote:

Addenum:

>  You need to have a way to say "compile this code under certain
> conditions based on the type argument, otherwise compile this code."
> That is, the compiler is directed, at compile time, as to which code
> should be compiled.  That is metaprogramming.

This is not metaprogramming!

Every and each statement is written by the human author in plain Go
and no code is produced by the program itself.

https://en.wikipedia.org/wiki/Metaprogramming
>>> Metaprogramming is a programming technique in which computer programs have
>>> the ability to treat programs as their data. It means that a program can
>>> be designed to read, generate, analyse or transform other programs, and
>>> even modify itself while running.

> Ian
> 

TC,

-- 
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: Generic types - functions and methods on instantions

[Ian Lance Taylor]

On Tue, Sep 11, 2018 at 5:38 PM, Patrick Smith  wrote:
>
> First, please consider requiring the 'type' keyword in definitions of
> methods on generic types:
>
> func (x Foo(type T)) method() {}
>
> This adds a small amount of verbiage, but makes the intent crystal clear. It
> also allows for easy extension of the syntax if some far future version of
> the language does allow adding methods to template instantiations.

Interesting idea, but even if we adopt specialization it seems to me
that an ordinary non-specialized method is the normal case, and a
method specialized to a specific type is the unusual case.  We should
try to avoid making the normal case be more verbose.

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.

Re: [go-nuts] Generics - Min challenge

[Ian Lance Taylor]

On Wed, Sep 12, 2018 at 7:32 AM, Wojciech S. Czarnecki  wrote:
> On Wed, 12 Sep 2018 06:33:59 -0700
> Ian Lance Taylor  wrote:
>
>> I don't think there is any way to solve this problem as stated without
>> taking a step toward metaprogramming: making decisions at compile time.
>
> Excuse me, how and where below stated artificial "contract adaptors"
> are NOT "making decisions at compile time."?

The difference I see is that in one case we write code that can not be
compiled, and then tell the compiler not to compile it.  With contract
adaptors--which are, of course, just a thought, not a fully fledged
idea--we direct the compiler to automatically insert wrappers that
make the type fit the contract.  We never write code that can not be
compiled.

I understand if you disagree but I would hope that you can express
your disagreement while avoiding language like "direction of doom."
Thanks.

Ian

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

Re: [go-nuts] Generics - Min challenge

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 06:33:59 -0700
Ian Lance Taylor  wrote:

> I don't think there is any way to solve this problem as stated without
> taking a step toward metaprogramming: making decisions at compile time.

Excuse me, how and where below stated artificial "contract adaptors"
are NOT "making decisions at compile time."?

> contract adaptors in the future: a mechanism that says "if the type argument
> does not implement contract C1, but does implement contract C2, then use
> this code to implement the requirements of C1 in terms of C2."

>  You need to have a way to say "compile this code under certain
> conditions based on the type argument, otherwise compile this code."

What allows for concise Min implementation I gave in this thread earlier.


> That is, the compiler is directed, at compile time, as to which code
> should be compiled. 

That is, the code user is directed, at reading time, as to which code will
compile for given type argument. Easy to see, easy to understand.

> That is metaprogramming.

That is readability.


>  I don't think this is a direction that Go should take.

Personally I think that it is the direction of doom. Ie. having an artificial
contract that is incomprehensible to the casual reader. To someone who do not
care how clever and knowledgeable contract's author was but cares much about
"what this piece of code might do".


> This sort of  automatically applied adaptor code seems to me to be less
> potentially confusing than metaprogramming.  Maybe.  I'm not at all sure.

"Sort of automatically applied adaptor code" is confusing ** right now**.
By the very "" cited description.

> Ian
> 

TC,

https://github.com/ohir/gonerics

-- 
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] Go memory usage inside containers

[Ian Lance Taylor]

On Wed, Sep 12, 2018 at 7:07 AM, robert engels  wrote:
> With the Azul VM (and I believe the G1 collector in Java), the VM is 
> definitely aware of memory pressure as it approaches the maximum limit - then 
> it will increase the concurrent GC activity trying to avoid a potential huge 
> pause if the limit was reached - so throughput is lowered.
>
> I would think the Go GC needs to do this as well in order to limit pause 
> times.

That does not sound precisely correct to me.  The Go GC pause time is
independent of the heap size, and I would expect that Java's pause
time is as well.  It's certainly true that Go could run the GC harder
when coming closer to a memory limit, which will tend to starve the
program, but it won't actually pause the program.  As I mentioned
earlier, though, when the program is coming close to its memory
limits, it needs to react.  If it's a network server, it needs to stop
accepting new connections.  If it has cached data, it needs to discard
it.  And so forth.  The GC can try harder but if the program keeps
allocating more memory there is nothing the GC can do to save it.

Ian

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

Re: [go-nuts] Go memory usage inside containers

[Ian Lance Taylor]

On Wed, Sep 12, 2018 at 6:58 AM, Leigh McCulloch  wrote:
>
> Thanks for the link and answering. I'll look more into understanding the
> issue. I'm mostly trying to reconcile that there are so many articles about
> not using Java inside containers because it does nothing to stay in the
> memory limits, but then I see no other articles about Go, giving the
> appearance it plays well with container memory limits. Maybe Go's garbage
> collector is more aggressive at keeping memory usage down?

I wouldn't know.


> In regards to CPU, I was running an app in a Kubernetes cluster on a node
> that had 16 CPUs. Even if I limited the apps access to 1 CPU, the
> runtime.NumCPU() call still returned 16.

I don't know what Kubernetes does to limit access to a CPU.  Perhaps
there is something to be fixed in the Go runtime 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

['Axel Wagner' via golang-nuts]

On Wed, Sep 12, 2018 at 3:55 PM Tristan Colgate  wrote:

> I'll leave the grown up to discuss after this I promise)
>

Don't worry. I'm not grown up by any measure.


> I guess if I were going to critique this I would say that optimising for
> ease of compiler implementation may not be the best thing.
>

I tend to agree. And I wouldn't optimize for it, if I wouldn't *also* be of
the opinion that it's simultaneously optimizing for ease of use. My
criticism of the contracts design is motivated by the user-perspective. And
it just so happens, that what I perceive as a fix also ends up making the
implementation easier.

But I also don't think these two are actually in any way contradictory. The
simpler algorithm is not only easier to implement, it's also easier to
understand, debug and understand the failure modes of. In the same way as
eliminating SAT search from Go modules doesn't only serve the implementer,
but also serves the user, because things run faster, failures are simpler
to understand and error messages are better - in the same way, I perceive a
simple interface-based constraint checker to be user-friendly.

Having a package of pre-defined contracts, and a tool and that can produce,
> and reduce contracts, if possible, would simplify things.
>

But that's kind of the crux. If that's needed or how they are usually used
- then a) why even have a way to have user-specified contracts and b)
doesn't that negate the argument of "not wanting to add a bunch of new
identifiers people need to learn"?


> To be completely honest, I think I'd be happy with your design if it just
> stopped before "Getting rid o boilerplate", I'd rather just live with the
> boilerplate than introduce the taxonomy that comes after.
>

That's why I split it :)


> It could, but this would change how people currently understand interfaces
> to work, e.g. in regard to nil-ness of interface values.
>

No, it wouldn't. I don't understand what you mean by that, what I described
is purely an optimization, not a semantic change :) That's just as with the
contracts design. Both designs make no semantic prescriptions about what
implementations are possible and leave that totally up as an optimization
to the compiler.

As said above excellently by Jimmy Frasche: The idea is to use interface
types to specify constraints, not interface values to pass generic values.
In
func Foo(type T SomeInterface) (v T)
v is still semantically of the type specified at instantiation time, not
just a SomeInterface value.

But, as I said above, I agree that there is need to polish the phrasing
here. If I would put this forth as an actual contending proposal, I
probably *would* end up adding a separate declaration (say "constraint")
too, which works similar to interface-declarations, can embed constraints,
interfaces or "pre-declared constraints" (the "pseudo-interfaces") and I
would allow using interfaces as constraints, instead of having to wrap them
separately - as a convenience.

I don't know. We'll see :)

-- 
You received this message because you are subscribed to the Google 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 memory usage inside containers

[robert engels]

You would need to refer me to those articles. We used Java in containers all of 
the time. You need to set a proper -Xmx though.

> On Sep 12, 2018, at 9:07 AM, robert engels  wrote:
> 
> With the Azul VM (and I believe the G1 collector in Java), the VM is 
> definitely aware of memory pressure as it approaches the maximum limit - then 
> it will increase the concurrent GC activity trying to avoid a potential huge 
> pause if the limit was reached - so throughput is lowered.
> 
> I would think the Go GC needs to do this as well in order to limit pause 
> times.
> 
>> On Sep 12, 2018, at 8:46 AM, Ian Lance Taylor  wrote:
>> 
>> On Tue, Sep 11, 2018 at 11:48 PM, Leigh McCulloch  wrote:
>>> 
>>> Does anyone here know how Go interacts with memory limits inside 
>>> containers? (e.g. Kubernetes, Docker)
>>> 
>>> Does the Go runtime have similar problems as the Java runtime, in that it 
>>> doesn't know what the container limit is, and only knows what the physical 
>>> limit is for the entire instance?
>>> 
>>> Or is Go aware of limits placed on the container?
>>> 
>>> (I've witnessed the Go runtime package say the NumCPU is the total physical 
>>> count when the app has been limited to many less CPUs, so it seems like it 
>>> doesn't have visibility into the CPU limitations.)
>> 
>> As far as I know, the current implementations of Go don't pay
>> attention to memory limits at all, whether running inside a container
>> or not.  You may be interested in following
>> https://golang.org/issue/23044 which could be a first step toward
>> fixing this.  In some sense the core issue is that using memory limits
>> in a garbage collected language is close to useless if the program
>> doesn't have a way to react when heap size is nearing the memory
>> limit.
>> 
>> On the other hand, on GNU/Linux systems, the CPU count is determined
>> by calling the sched_getaffinity system call, which as far as I know
>> is aware of container limits.  What leads you to believe otherwise?
>> 
>> 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.
> 

-- 
You received this message because you are subscribed to the Google 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 memory usage inside containers

[robert engels]

With the Azul VM (and I believe the G1 collector in Java), the VM is definitely 
aware of memory pressure as it approaches the maximum limit - then it will 
increase the concurrent GC activity trying to avoid a potential huge pause if 
the limit was reached - so throughput is lowered.

I would think the Go GC needs to do this as well in order to limit pause times.

> On Sep 12, 2018, at 8:46 AM, Ian Lance Taylor  wrote:
> 
> On Tue, Sep 11, 2018 at 11:48 PM, Leigh McCulloch  wrote:
>> 
>> Does anyone here know how Go interacts with memory limits inside containers? 
>> (e.g. Kubernetes, Docker)
>> 
>> Does the Go runtime have similar problems as the Java runtime, in that it 
>> doesn't know what the container limit is, and only knows what the physical 
>> limit is for the entire instance?
>> 
>> Or is Go aware of limits placed on the container?
>> 
>> (I've witnessed the Go runtime package say the NumCPU is the total physical 
>> count when the app has been limited to many less CPUs, so it seems like it 
>> doesn't have visibility into the CPU limitations.)
> 
> As far as I know, the current implementations of Go don't pay
> attention to memory limits at all, whether running inside a container
> or not.  You may be interested in following
> https://golang.org/issue/23044 which could be a first step toward
> fixing this.  In some sense the core issue is that using memory limits
> in a garbage collected language is close to useless if the program
> doesn't have a way to react when heap size is nearing the memory
> limit.
> 
> On the other hand, on GNU/Linux systems, the CPU count is determined
> by calling the sched_getaffinity system call, which as far as I know
> is aware of container limits.  What leads you to believe otherwise?
> 
> 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.

-- 
You received this message because you are subscribed to the Google 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] Generics "craftsman approach" proposal update

[Ian Lance Taylor]

On Wed, Sep 12, 2018 at 6:47 AM, Wojciech S. Czarnecki  wrote:
>
> https://github.com/ohir/gonerics
>
> Thanks to all for your insights and stated concerns.
>
> Changes:
>
> 1. "Out" (return) type constraints are out. Might return as optional.
> 2. enumerated "T is assignable to" constraint added
> 3. "Rationale" clarified.

I don't see a description of generic types, I only see generic functions.

I don't understand how you handle a named type like `type MyInt int`.
Such a type is neither identical to `int` nor assignable to `int`.
You don't have a way of saying "convertible to `int`", and if you did
it's not clear how it would handle, say, `float64`.

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.

Re: [go-nuts] [golang-dev] go doesn't need generics, but if they do...

[robert engels]

By the way, see the following quote and this page 
https://www.bytonic.de/html/benchmarks.html 
 and this quote,

"
November 28, 2005. Retrieved July 18, 2009. This is a great show of 3D prowess. 
Things like this, as well as the Narya 2D open source engine from ThreeRings 
really are starting to at least show Java can serve as a first-class gaming 
platform. More than that, just having seen all the… *cough* horrible code in 
games before, having things like Java’s threading model, network and database 
support might really make it a BETTER platform for a lot of forthcoming games 
than C.



When the Jake2 Java based Quake engine was released, it was just as fast at the 
C version and far easier to develop in.

Btw, I have also published gaming software, a long, long time ago… The 
algorithm matters more than the platform, but it needs to match the platform. 
You can trust the JIT to perform better code optimization than most 
developers...


> On Sep 12, 2018, at 8:34 AM, robert engels  wrote:
> 
> While I always appreciate a good presentation, a little color might be in 
> order to get me to watch a 1.5 hr presentation.
> 
> I’ll disagree on ByteBuffer. The prime motivation for ByteBuffer was to 
> abstract the concept of a memory buffer (usually bytes). The primary reason 
> is that byte[] has a defined meaning in the Java system, and to do NIO with 
> direct memory (or have off-heap memory to avoid GC) they needed an 
> abstraction layer - so you could implement DirectByteBuffer. Nothing to do 
> with generics. Then with this specialized class, the VM can use intrinsics to 
> make ByteBuffer perform as well as Java memory, or native memory.
> 
> Go doesn’t need this, since the byte[] in Go is already a native pointer.
> 
>> On Sep 12, 2018, at 8:15 AM, Egon > > wrote:
>> 
>> On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote:
>> I am well aware of mechanical sympathy and the techniques (like the 
>> disrupter) used (I would counter that in many cases you are not writing 
>> “Java” due to the object pooling ,etc.)
>> 
>> What I’ve shown is that Java is already more performant than Go without 
>> using those techniques for many application aspects - specifically in terms 
>> of method dispatch, but still Go direct methods vs interface methods are 5x 
>> faster, so you if you need ultra performance critical code you need to keep 
>> that in mind, but RARELY is this the case (except for some people in HFT but 
>> even they have moved on to FPGAs) and you are far better structuring your 
>> code for maintainability and functionality rather than worrying about slower 
>> method dispatch...
>> 
>> https://www.youtube.com/watch?v=rX0ItVEVjHc 
>> 
>>  
>> 
>> ArrayList is not “correct” Java - because you are going to encode 
>> every byte as an object in an object[] behind the scenes, and each would 
>> need to be managed as an Object. Java has arrays, you would simply use a 
>> byte[]. If you need expandable arrays, you would probably use a ByteBuffer.
>> 
>> That is exactly the boxing overhead that the generics dilemma talks about. 
>> ByteBuffer is an example where the generics weren't good enough and people 
>> ended up manually implemented a specialized version.
>> 
>> Remember you shouldn't be comparing performance of Java generics vs Go 
>> status quo... you should be comparing Java generics vs C++ generics vs Swift 
>> generics vs D generics vs Zig generics. That way the trade-offs of different 
>> approaches becomes visible.
>>  
>> 
>> Your point highlights an important consideration - most people don’t know 
>> how to write REALLY performant software in a given language unless it is an 
>> area of focus and experience, which is why I distribute the tests publicly 
>> because I will grant that there may be techniques in Go that I am not 
>> understanding or misusing - but at this point I think I have a pretty good 
>> handle on the internal workings of Go.
>> 
>> I completely agree that most people can live with the current state.
>>  
>> 
>> The biggest performance advantage for Go will be the garbage collector due 
>> to the “value type” of array struct, since there is only a single reference 
>> to be GC managed regardless of the number of elements. That is not possible 
>> in Java - at least not now. That being said, there are Java VMs like Azul 
>> Zing that are far more performant than Go in terms of GC pauses without any 
>> restricting on the layout of the memory being managed. As soon as you start 
>> using array of interface in Go, you are going to put pressure on the GC, as 
>> the number of references that need to be managed expands proportional to the 
>> size of the array - at least I think so - but there may be behind the scenes 
>> escape analysis that determines if any references escape the array, and if 
>> not it can still manage it is a single 

Re: [go-nuts] Go memory usage inside containers

[Leigh McCulloch]

Hi Ian,

Thanks for the link and answering. I'll look more into understanding the 
issue. I'm mostly trying to reconcile that there are so many articles about 
not using Java inside containers because it does nothing to stay in the 
memory limits, but then I see no other articles about Go, giving the 
appearance it plays well with container memory limits. Maybe Go's garbage 
collector is more aggressive at keeping memory usage down?

In regards to CPU, I was running an app in a Kubernetes cluster on a node 
that had 16 CPUs. Even if I limited the apps access to 1 CPU, the 
runtime.NumCPU() call still returned 16.

Leigh

On Wednesday, September 12, 2018 at 6:46:34 AM UTC-7, Ian Lance Taylor 
wrote:
>
> On Tue, Sep 11, 2018 at 11:48 PM, Leigh McCulloch  > wrote: 
> > 
> > Does anyone here know how Go interacts with memory limits inside 
> containers? (e.g. Kubernetes, Docker) 
> > 
> > Does the Go runtime have similar problems as the Java runtime, in that 
> it doesn't know what the container limit is, and only knows what the 
> physical limit is for the entire instance? 
> > 
> > Or is Go aware of limits placed on the container? 
> > 
> > (I've witnessed the Go runtime package say the NumCPU is the total 
> physical count when the app has been limited to many less CPUs, so it seems 
> like it doesn't have visibility into the CPU limitations.) 
>
> As far as I know, the current implementations of Go don't pay 
> attention to memory limits at all, whether running inside a container 
> or not.  You may be interested in following 
> https://golang.org/issue/23044 which could be a first step toward 
> fixing this.  In some sense the core issue is that using memory limits 
> in a garbage collected language is close to useless if the program 
> doesn't have a way to react when heap size is nearing the memory 
> limit. 
>
> On the other hand, on GNU/Linux systems, the CPU count is determined 
> by calling the sched_getaffinity system call, which as far as I know 
> is aware of container limits.  What leads you to believe otherwise? 
>
> 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.

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

(I'm acutely aware that there's a limit to how useful endless back and
forth on this stuff is, and I definitely have to yield on the technical
details here, I'll leave the grown up to discuss after this I promise)

On Tue, 11 Sep 2018 at 14:26 Axel Wagner 
wrote:

> There is no accounting for taste, of course, but I wildly disagree. In
> particular, the constraint solver and type-checker for what I described is
> trivial to write and understand, including good error messages. AIUI it is
> currently not clear whether the contract design can actually be
> type-checked in practice (and, personally, I am predicting the things I and
> others are bringing up to be exactly the things that will come up as
> difficultlies).
>

I guess if I were going to critique this I would say that optimising for
ease of compiler implementation may not be the best thing. *If* the
existing design can be made to work (and that's clearly a big "if"), then I
think I would still find it preferable, as you say, no accounting for taste.

Having a package of pre-defined contracts, and a tool and that can produce,
and reduce contracts, if possible, would simplify things.

To be completely honest, I think I'd be happy with your design if it just
stopped before "Getting rid o boilerplate", I'd rather just live with the
boilerplate than introduce the taxonomy that comes after. Also, personally,
I'd rather leave interfaces alone and have the typed interfaces be a
separate thing, but I don't understand this well enough to know if that
really works.

func Foo(w io.Writer) { fmt.Fprintln(w, "Hello world") }
> func main() { Foo(os.Stdout) }
>
> The compiler could decide to devirtualize the interface, to generate a
> boxed version or to do a hybrid approach (e.g. compile a boxed version and
> devirtualize for certain types based on usage). Exactly like with the
> contract designs.
>

It could, but this would change how people currently understand interfaces
to work, e.g. in regard to nil-ness of interface values. This is already a
bit of  a hurdle for beginners.


> I still believe that if there's a simpler alternative (and I consider my
> design simpler, for the implementation, the author and the user of generic
> code. But I'm obviously biased) that creates higher levels of type-safety,
> while not giving up a significant amount of expressive power, then that
> should be at least considered. Because it's just as much not obvious that
> contracts provide the wrong level of type-safety, as it's obvious that they
> provide the only correct level of type-safety.
>

Things certainly look hopeful.

-- 
You received this message because you are subscribed to the Google 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] Generics "craftsman approach" proposal update

[Wojciech S. Czarnecki]

https://github.com/ohir/gonerics

Thanks to all for your insights and stated concerns.

Changes:

1. "Out" (return) type constraints are out. Might return as optional.
2. enumerated "T is assignable to" constraint added 
3. "Rationale" clarified.

-- 
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] Go memory usage inside containers

[Ian Lance Taylor]

On Tue, Sep 11, 2018 at 11:48 PM, Leigh McCulloch  wrote:
>
> Does anyone here know how Go interacts with memory limits inside containers? 
> (e.g. Kubernetes, Docker)
>
> Does the Go runtime have similar problems as the Java runtime, in that it 
> doesn't know what the container limit is, and only knows what the physical 
> limit is for the entire instance?
>
> Or is Go aware of limits placed on the container?
>
> (I've witnessed the Go runtime package say the NumCPU is the total physical 
> count when the app has been limited to many less CPUs, so it seems like it 
> doesn't have visibility into the CPU limitations.)

As far as I know, the current implementations of Go don't pay
attention to memory limits at all, whether running inside a container
or not.  You may be interested in following
https://golang.org/issue/23044 which could be a first step toward
fixing this.  In some sense the core issue is that using memory limits
in a garbage collected language is close to useless if the program
doesn't have a way to react when heap size is nearing the memory
limit.

On the other hand, on GNU/Linux systems, the CPU count is determined
by calling the sched_getaffinity system call, which as far as I know
is aware of container limits.  What leads you to believe otherwise?

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] Re: I want to run a go project called syncthing on iOS , but I have some issues

[m18742049357]

I got the project from https://github.com/pangliang/syncthing-ios  ,it can 
work 2years ago, and the synching.a can be used now.

在 2018年9月12日星期三 UTC+8下午8:58:01，Elias Naur写道：
>
> Tamás is right: go install or go build should be enough. Mare sure you 
> have a recent version of Xcode (I use version 9.x) installed.
>
> Here's my attempt:
>
> $ go get -u github.com/syncthing/syncthing/cmd/syncthing
> $ GOARCH=arm64 CGO_ENABLED=1 ~/go-tip/bin/go build -tags ios -o syncthing 
> github.com/syncthing/syncthing/cmd/syncthing
> # github.com/syncthing/syncthing/vendor/github.com/syncthing/notify
> ../go/src/
> github.com/syncthing/syncthing/vendor/github.com/syncthing/notify/watcher_fsevents_cgo.go:10:10:
>  
> fatal error: 'CoreServices/CoreServices.h' file not found
> #include 
>  ^
> 1 error generated.
>
> The CoreServices error is probably because CoreServices is not available 
> until iOS 12.
>
> What are you trying to do? Command line programs are not supported on iOS, 
> unless your device is jailbroken.
>
>  - elias
>
> On Wednesday, September 12, 2018 at 6:28:12 AM UTC+2, m18742...@163.com 
> wrote:
>>
>> *I run the shell *
>>
>>
>> *set -eecho "Done 1"*
>>
>>
>> *HOME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd 
>> )"GO=$HOME/golang/bin/go*
>>
>>
>>
>> *if [ ! -d "$HOME/cgo-obj" ]; thenmkdir $HOME/cgo-objfi*
>>
>>
>>
>> *if [ ! -d "$HOME/go-obj" ]; thenmkdir $HOME/go-objfi*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *echo "Done 2"CGO_ENABLED=1 GOARCH=arm64 GOARM=7 $GO tool cgo -objdir 
>> $HOME/cgo-obj 
>> $HOME/syncthing/src/github.com/syncthing/syncthing/cmd/syncthing/main.go 
>> echo "Done 
>> 3"GOPATH=$HOME/syncthing CGO_ENABLED=1 GOARCH=arm64 $GO build -v -o 
>> syncthing-exc -ldflags "-tmpdir $HOME/go-obj -linkmode 
>> external" github.com/syncthing/syncthing/cmd/syncthing 
>> echo "Done 4"when I 
>> run it on xcode  *
>>
>>   runtime/cgo
>>
>> # runtime/cgo
>>
>> In file included from _cgo_export.c:3:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/stdlib.h:63:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/_types.h:27:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:32:
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/cdefs.h:761:2:
>>  
>> error: Unsupported architecture
>>
>> In file included from _cgo_export.c:3:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/stdlib.h:63:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/_types.h:27:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:33:
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/machine/_types.h:34:2:
>>  
>> error: architecture not supported
>>
>> In file included from _cgo_export.c:3:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/stdlib.h:63:
>>
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/_types.h:27:
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:55:9:
>>  
>> error: unknown type name '__int64_t'; did you mean '__int128_t'?
>>
>> note: '__int128_t' declared here
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:56:9:
>>  
>> error: unknown type name '__int32_t'; did you mean '__int128_t'?
>>
>> note: '__int128_t' declared here
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:57:9:
>>  
>> error: unknown type name '__int32_t'; did you mean '__int128_t'?
>>
>> note: '__int128_t' declared here
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:60:9:
>>  
>> error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
>>
>> note: '__uint128_t' declared here
>>
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:61:9:
>>  
>> error: 

Re: [go-nuts] Golang equivalent of Python's context manager

[robert engels]

Agree it can be done - not sure I would want to maintain that in a large system 
as you are paying the LOC penalty at every call site. Seems easier to just add 
the context callback in the methods themselves so then you are in control of 
the code penalty.

> On Sep 12, 2018, at 8:17 AM, Sebastien Binet  wrote:
> 
> 
> 
> On Wed, Sep 12, 2018 at 2:55 PM robert engels  > wrote:
> Ok, now the coffee has kicked in, and it still has problems, because you 
> cannot call a method and use a return value other than error without multiple 
> signatures, unless you move all of the return values outside of the closure - 
> like his example does with var a. 
> 
> This would be extremely tedious (and probably error prone) to use IMO, 
> especially with Go’s multiple return values.
> 
> one has to be careful, yes. but it's not completely out of reach.
> 
> func Foo(a, b int) (int, error) { ... }
> 
> func Do() {
> var out = 0
> With(ctx, func() error {
> var err error
> out, err = Foo(42, 66)
> return err
> })
> }
> 
> closures are great! (like fezzes and bowties, actually :P)
> 
> -s
>  
> 
>> On Sep 12, 2018, at 7:50 AM, robert engels > > wrote:
>> 
>> Too early, and the coffee had not kicked in...
>> 
>>> On Sep 12, 2018, at 7:49 AM, robert engels >> > wrote:
>>> 
>>> Yes, you are correct. My bad :)
>>> 
 On Sep 12, 2018, at 7:34 AM, Sebastien Binet >>> > wrote:
 
 
 
 On Wed, Sep 12, 2018 at 2:23 PM robert engels >>> > wrote:
 I am pretty sure that is not correct, I am referring to:
 
> func WithContext(context Context, f func() error) error {
>   context.__entry__()
>   defer context.__exit__()
>   return f()
> }
 
 You will need a lot of WithContext methods - based on the different 
 signatures of function f.
 
 See the main method… I am assuming this is attempting to be a general 
 facility - and thus the signature of f will vary.
 
 you just need to wrap it with a closure, just as Eric did:
 
 e.g.:
  func QueryDB(a,b int) error { ... }
  
  WithContext(ctx, func() error {
 return QueryDB(42, 666)
  })
 
 and voila.
 
 -s
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google 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] Re: [golang-dev] go doesn't need generics, but if they do...

[robert engels]

While I always appreciate a good presentation, a little color might be in order 
to get me to watch a 1.5 hr presentation.

I’ll disagree on ByteBuffer. The prime motivation for ByteBuffer was to 
abstract the concept of a memory buffer (usually bytes). The primary reason is 
that byte[] has a defined meaning in the Java system, and to do NIO with direct 
memory (or have off-heap memory to avoid GC) they needed an abstraction layer - 
so you could implement DirectByteBuffer. Nothing to do with generics. Then with 
this specialized class, the VM can use intrinsics to make ByteBuffer perform as 
well as Java memory, or native memory.

Go doesn’t need this, since the byte[] in Go is already a native pointer.

> On Sep 12, 2018, at 8:15 AM, Egon  wrote:
> 
> On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote:
> I am well aware of mechanical sympathy and the techniques (like the 
> disrupter) used (I would counter that in many cases you are not writing 
> “Java” due to the object pooling ,etc.)
> 
> What I’ve shown is that Java is already more performant than Go without using 
> those techniques for many application aspects - specifically in terms of 
> method dispatch, but still Go direct methods vs interface methods are 5x 
> faster, so you if you need ultra performance critical code you need to keep 
> that in mind, but RARELY is this the case (except for some people in HFT but 
> even they have moved on to FPGAs) and you are far better structuring your 
> code for maintainability and functionality rather than worrying about slower 
> method dispatch...
> 
> https://www.youtube.com/watch?v=rX0ItVEVjHc 
> 
>  
> 
> ArrayList is not “correct” Java - because you are going to encode every 
> byte as an object in an object[] behind the scenes, and each would need to be 
> managed as an Object. Java has arrays, you would simply use a byte[]. If you 
> need expandable arrays, you would probably use a ByteBuffer.
> 
> That is exactly the boxing overhead that the generics dilemma talks about. 
> ByteBuffer is an example where the generics weren't good enough and people 
> ended up manually implemented a specialized version.
> 
> Remember you shouldn't be comparing performance of Java generics vs Go status 
> quo... you should be comparing Java generics vs C++ generics vs Swift 
> generics vs D generics vs Zig generics. That way the trade-offs of different 
> approaches becomes visible.
>  
> 
> Your point highlights an important consideration - most people don’t know how 
> to write REALLY performant software in a given language unless it is an area 
> of focus and experience, which is why I distribute the tests publicly because 
> I will grant that there may be techniques in Go that I am not understanding 
> or misusing - but at this point I think I have a pretty good handle on the 
> internal workings of Go.
> 
> I completely agree that most people can live with the current state.
>  
> 
> The biggest performance advantage for Go will be the garbage collector due to 
> the “value type” of array struct, since there is only a single reference to 
> be GC managed regardless of the number of elements. That is not possible in 
> Java - at least not now. That being said, there are Java VMs like Azul Zing 
> that are far more performant than Go in terms of GC pauses without any 
> restricting on the layout of the memory being managed. As soon as you start 
> using array of interface in Go, you are going to put pressure on the GC, as 
> the number of references that need to be managed expands proportional to the 
> size of the array - at least I think so - but there may be behind the scenes 
> escape analysis that determines if any references escape the array, and if 
> not it can still manage it is a single reference.
> 
> But all of this is off-topic from the original post - which was to suggest to 
> keep it simple and use interfaces/closures at runtime to support generics and 
> not worrying about the performance overhead - the really performance critical 
> coders can always write non-generic/interface containers if they absolutely 
> think they need it, but most likely they don’t...
> 
> I tend to agree, but having specializing generics makes some of that code 
> easier to manage.
>  
>  
> 
>> On Sep 11, 2018, at 11:57 PM, Egon gmail.com 
>> > wrote:
>> 
>> 
>> 
>> On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote:
>> 
>>> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts >> <>googlegroups.com > wrote:
>>> 
>>> [golang-nuts to CC, golang-dev to BCC]
>>> 
>>> On Mon, Sep 10, 2018 at 5:33 PM robert engels ix.netcom.com 
>>> > wrote:
>>> In the entire codebase of Docker I could find only one obvious use of 
>>> interface{}, and no type casts.
>>> 
>>> Generics are not only useful for functions taking interface{}. They are 
>>> also useful for functions taking 

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

On Tue, 11 Sep 2018, 18:12 jimmy frasche,  wrote:

> Using the interface type to constrain type parameters at compile-time
> does not necessarily imply using the interface value to implement
> generics at runtime.


No, but this does imply that we override what an interface is. They are
already one of the more awkward parts of the language for beginners (e.g.
nil interfaces vs an interface with a nil dynamic value). Overloading the
syntax will make this situation worse.

-- 
You received this message because you are subscribed to the Google 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] Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

I think the point is that by implementing Getter/Setter methods, which are
trivially inline-able there's no real downside to skipping fields and just
allowing method calls.
If it makes it easier to unify contracts and interfaces, I think that may
be a hit worth taking (though I still say, getters and setters are terribly
idiomatic, and have been actively discouraged in the past. This will make
them far more common, I'm not really sure that's a good thing.

On Wed, 12 Sep 2018 at 14:15 Mandolyte  wrote:

> On field accessors...
>
> - Algorithms for X,Y points requiring them to be members of a struct type.
>
> - Algorithms to manipulate colors, requiring R,G, and B to be members.
>
> In an image processing library with its own rich set of struct types, such
> accessors would prove productive.
>
> Are these the kind of examples you meant?
>
> --
> You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[Sebastien Binet]

On Wed, Sep 12, 2018 at 2:55 PM robert engels  wrote:

> Ok, now the coffee has kicked in, and it still has problems, because you
> cannot call a method and use a return value other than error without
> multiple signatures, unless you move all of the return values outside of
> the closure - like his example does with var a.
>

> This would be extremely tedious (and probably error prone) to use IMO,
> especially with Go’s multiple return values.
>

one has to be careful, yes. but it's not completely out of reach.

func Foo(a, b int) (int, error) { ... }

func Do() {
var out = 0
With(ctx, func() error {
var err error
out, err = Foo(42, 66)
return err
})
}

closures are great! (like fezzes and bowties, actually :P)

-s


>
> On Sep 12, 2018, at 7:50 AM, robert engels  wrote:
>
> Too early, and the coffee had not kicked in...
>
> On Sep 12, 2018, at 7:49 AM, robert engels  wrote:
>
> Yes, you are correct. My bad :)
>
> On Sep 12, 2018, at 7:34 AM, Sebastien Binet  wrote:
>
>
>
> On Wed, Sep 12, 2018 at 2:23 PM robert engels 
> wrote:
>
>> I am pretty sure that is not correct, I am referring to:
>>
>> func WithContext(context Context, f func() error) error {
>> context.__entry__()
>> defer context.__exit__()
>> return f()
>> }
>>
>>
>> You will need a lot of WithContext methods - based on the different
>> signatures of function f.
>>
>> See the main method… I am assuming this is attempting to be a general
>> facility - and thus the signature of f will vary.
>>
>
> you just need to wrap it with a closure, just as Eric did:
>
> e.g.:
>  func QueryDB(a,b int) error { ... }
>
>  WithContext(ctx, func() error {
> return QueryDB(42, 666)
>  })
>
> and voila.
>
> -s
>
>
>
> --
> You received this message because you are subscribed to the Google 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] Scrapping contracts (was: "Generics as bultin typeclasses")

[Mandolyte]

On field accessors... 

- Algorithms for X,Y points requiring them to be members of a struct type.

- Algorithms to manipulate colors, requiring R,G, and B to be members.

In an image processing library with its own rich set of struct types, such 
accessors would prove productive.

Are these the kind of examples you meant?

-- 
You received this message because you are subscribed to the Google 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: [golang-dev] go doesn't need generics, but if they do...

[Egon]

On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote:
>
> I am well aware of mechanical sympathy and the techniques (like the 
> disrupter) used (I would counter that in many cases you are not writing 
> “Java” due to the object pooling ,etc.)
>
> What I’ve shown is that Java is already more performant than Go without 
> using those techniques for many application aspects - specifically in terms 
> of method dispatch, but still Go direct methods vs interface methods are 5x 
> faster, so you if you need ultra performance critical code you need to keep 
> that in mind, but RARELY is this the case (except for some people in HFT 
> but even they have moved on to FPGAs) and you are far better structuring 
> your code for maintainability and functionality rather than worrying about 
> slower method dispatch...
>

https://www.youtube.com/watch?v=rX0ItVEVjHc
 

>
> ArrayList is not “correct” Java - because you are going to encode 
> every byte as an object in an object[] behind the scenes, and each would 
> need to be managed as an Object. Java has arrays, you would simply use a 
> byte[]. If you need expandable arrays, you would probably use a ByteBuffer.
>

That is exactly the boxing overhead that the generics dilemma talks about. 
ByteBuffer is an example where the generics weren't good enough and people 
ended up manually implemented a specialized version.

Remember you shouldn't be comparing performance of Java generics vs Go 
status quo... you should be comparing Java generics vs C++ generics vs 
Swift generics vs D generics vs Zig generics. That way the trade-offs of 
different approaches becomes visible.
 

>
> Your point highlights an important consideration - most people don’t know 
> how to write REALLY performant software in a given language unless it is an 
> area of focus and experience, which is why I distribute the tests publicly 
> because I will grant that there may be techniques in Go that I am not 
> understanding or misusing - but at this point I think I have a pretty good 
> handle on the internal workings of Go.
>

I completely agree that most people can live with the current state.
 

>
> The biggest performance advantage for Go will be the garbage collector due 
> to the “value type” of array struct, since there is only a single reference 
> to be GC managed regardless of the number of elements. That is not possible 
> in Java - at least not now. That being said, there are Java VMs like Azul 
> Zing that are far more performant than Go in terms of GC pauses without any 
> restricting on the layout of the memory being managed. As soon as you start 
> using array of interface in Go, you are going to put pressure on the GC, as 
> the number of references that need to be managed expands proportional to 
> the size of the array - at least I think so - but there may be behind the 
> scenes escape analysis that determines if any references escape the array, 
> and if not it can still manage it is a single reference.
>
> But all of this is off-topic from the original post - which was to suggest 
> to keep it simple and use interfaces/closures at runtime to support 
> generics and not worrying about the performance overhead - the really 
> performance critical coders can always write non-generic/interface 
> containers if they absolutely think they need it, but most likely they 
> don’t...
>

I tend to agree, but having specializing generics makes some of that code 
easier to manage.
 

>  
>

> On Sep 11, 2018, at 11:57 PM, Egon > 
> wrote:
>
>
>
> On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote:
>>
>>
>> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > googlegroups.com> wrote:
>>
>> [golang-nuts to CC, golang-dev to BCC]
>>
>> On Mon, Sep 10, 2018 at 5:33 PM robert engels  
>> wrote:
>>
>>> In the entire codebase of Docker I could find only one obvious use of 
>>> interface{}, and no type casts.
>>>
>>
>> Generics are not only useful for functions taking interface{}. They are 
>> also useful for functions taking non-empty interfaces, for cases where you 
>> could re-use an existing generic implementation and forego re-implementing 
>> it for your concrete type and for reducing boilerplate across many types 
>> (e.g. the famous sort.Interface).
>>
>>
>> True, and reviewing cockroachdb shows the sort.Interface used a lot, and 
>> a generic container could avoid that, but in most cases this could be 
>> solved by only having to implement Less and having ’sort’ work on slices - 
>> as the vast majority are slices to begin with.
>>
>> I am just attempting to point out that the original Go designers offered 
>> ’typed’ collections (slice, map) as part of the language. They fall short 
>> in some ways but it may be possible for a simpler solution to expand their 
>> abilities, or add others, without resorting to generics. I like the 
>> simplicity and readability “no surprises for the most part” of Go, and I 
>> think it should try to stay that way.
>>
>>
>> 

[go-nuts] golang gRPC question

[robert engels]

Hi, I am adding a remote component to my github.com/robaho/keydb 
 project and decided to use gRPC.

I’ve reviewed the docs, and it appears to want to be stateless - which given 
the nature of Google makes sense.

But for something like a database connection, where there could be substantial 
connection setup costs that you wouldn’t want to pay on every request, what is 
the best way to accomplish this with gRPC?

There are issues like https://github.com/grpc/grpc-go/issues/297 
 that are closed with no resolution 
???

There doesn’t seem to be a way to access the connection state on the server - 
to know the associated user, register a close handler, etc.

The only solutions I see is are

1) that the client must send heartbeat message, if the server doesn’t receive a 
heartbeat in X, clean-up the connection, AND the client must send a 
connectionID along with every request (but even this seems problematic for 
security reasons).

2) use the bidirectional streaming mode, and so the connection is treated as 
one long stream of messages in and out, and when the rpc finishes the 
connection is cleaned up

Is there an example of this type of usage someone can point me 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: I want to run a go project called syncthing on iOS , but I have some issues

[Elias Naur]

Tamás is right: go install or go build should be enough. Mare sure you have 
a recent version of Xcode (I use version 9.x) installed.

Here's my attempt:

$ go get -u github.com/syncthing/syncthing/cmd/syncthing
$ GOARCH=arm64 CGO_ENABLED=1 ~/go-tip/bin/go build -tags ios -o syncthing 
github.com/syncthing/syncthing/cmd/syncthing
# github.com/syncthing/syncthing/vendor/github.com/syncthing/notify
../go/src/github.com/syncthing/syncthing/vendor/github.com/syncthing/notify/watcher_fsevents_cgo.go:10:10:
 
fatal error: 'CoreServices/CoreServices.h' file not found
#include 
 ^
1 error generated.

The CoreServices error is probably because CoreServices is not available 
until iOS 12.

What are you trying to do? Command line programs are not supported on iOS, 
unless your device is jailbroken.

 - elias

On Wednesday, September 12, 2018 at 6:28:12 AM UTC+2, m18742...@163.com 
wrote:
>
> *I run the shell *
>
>
> *set -eecho "Done 1"*
>
>
> *HOME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd 
> )"GO=$HOME/golang/bin/go*
>
>
>
> *if [ ! -d "$HOME/cgo-obj" ]; thenmkdir $HOME/cgo-objfi*
>
>
>
> *if [ ! -d "$HOME/go-obj" ]; thenmkdir $HOME/go-objfi*
>
>
>
>
>
>
>
>
>
>
> *echo "Done 2"CGO_ENABLED=1 GOARCH=arm64 GOARM=7 $GO tool cgo -objdir 
> $HOME/cgo-obj 
> $HOME/syncthing/src/github.com/syncthing/syncthing/cmd/syncthing/main.go 
> echo "Done 
> 3"GOPATH=$HOME/syncthing CGO_ENABLED=1 GOARCH=arm64 $GO build -v -o 
> syncthing-exc -ldflags "-tmpdir $HOME/go-obj -linkmode 
> external" github.com/syncthing/syncthing/cmd/syncthing 
> echo "Done 4"when I 
> run it on xcode  *
>
>   runtime/cgo
>
> # runtime/cgo
>
> In file included from _cgo_export.c:3:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/stdlib.h:63:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/_types.h:27:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:32:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/cdefs.h:761:2:
>  
> error: Unsupported architecture
>
> In file included from _cgo_export.c:3:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/stdlib.h:63:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/_types.h:27:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:33:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/machine/_types.h:34:2:
>  
> error: architecture not supported
>
> In file included from _cgo_export.c:3:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/stdlib.h:63:
>
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/_types.h:27:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:55:9:
>  
> error: unknown type name '__int64_t'; did you mean '__int128_t'?
>
> note: '__int128_t' declared here
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:56:9:
>  
> error: unknown type name '__int32_t'; did you mean '__int128_t'?
>
> note: '__int128_t' declared here
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:57:9:
>  
> error: unknown type name '__int32_t'; did you mean '__int128_t'?
>
> note: '__int128_t' declared here
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:60:9:
>  
> error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
>
> note: '__uint128_t' declared here
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:61:9:
>  
> error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
>
> note: '__uint128_t' declared here
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk/usr/include/sys/_types.h:62:9:
>  
> error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
>
> note: '__uint128_t' 

Re: [go-nuts] Golang equivalent of Python's context manager

[robert engels]

Ok, now the coffee has kicked in, and it still has problems, because you cannot 
call a method and use a return value other than error without multiple 
signatures, unless you move all of the return values outside of the closure - 
like his example does with var a.

This would be extremely tedious (and probably error prone) to use IMO, 
especially with Go’s multiple return values.

> On Sep 12, 2018, at 7:50 AM, robert engels  wrote:
> 
> Too early, and the coffee had not kicked in...
> 
>> On Sep 12, 2018, at 7:49 AM, robert engels > > wrote:
>> 
>> Yes, you are correct. My bad :)
>> 
>>> On Sep 12, 2018, at 7:34 AM, Sebastien Binet >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Sep 12, 2018 at 2:23 PM robert engels >> > wrote:
>>> I am pretty sure that is not correct, I am referring to:
>>> 
 func WithContext(context Context, f func() error) error {
context.__entry__()
defer context.__exit__()
return f()
 }
>>> 
>>> You will need a lot of WithContext methods - based on the different 
>>> signatures of function f.
>>> 
>>> See the main method… I am assuming this is attempting to be a general 
>>> facility - and thus the signature of f will vary.
>>> 
>>> you just need to wrap it with a closure, just as Eric did:
>>> 
>>> e.g.:
>>>  func QueryDB(a,b int) error { ... }
>>>  
>>>  WithContext(ctx, func() error {
>>> return QueryDB(42, 666)
>>>  })
>>> 
>>> and voila.
>>> 
>>> -s
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[robert engels]

Too early, and the coffee had not kicked in...

> On Sep 12, 2018, at 7:49 AM, robert engels  wrote:
> 
> Yes, you are correct. My bad :)
> 
>> On Sep 12, 2018, at 7:34 AM, Sebastien Binet > > wrote:
>> 
>> 
>> 
>> On Wed, Sep 12, 2018 at 2:23 PM robert engels > > wrote:
>> I am pretty sure that is not correct, I am referring to:
>> 
>>> func WithContext(context Context, f func() error) error {
>>> context.__entry__()
>>> defer context.__exit__()
>>> return f()
>>> }
>> 
>> You will need a lot of WithContext methods - based on the different 
>> signatures of function f.
>> 
>> See the main method… I am assuming this is attempting to be a general 
>> facility - and thus the signature of f will vary.
>> 
>> you just need to wrap it with a closure, just as Eric did:
>> 
>> e.g.:
>>  func QueryDB(a,b int) error { ... }
>>  
>>  WithContext(ctx, func() error {
>> return QueryDB(42, 666)
>>  })
>> 
>> and voila.
>> 
>> -s
> 
> 
> -- 
> You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[robert engels]

Yes, you are correct. My bad :)

> On Sep 12, 2018, at 7:34 AM, Sebastien Binet  wrote:
> 
> 
> 
> On Wed, Sep 12, 2018 at 2:23 PM robert engels  > wrote:
> I am pretty sure that is not correct, I am referring to:
> 
>> func WithContext(context Context, f func() error) error {
>>  context.__entry__()
>>  defer context.__exit__()
>>  return f()
>> }
> 
> You will need a lot of WithContext methods - based on the different 
> signatures of function f.
> 
> See the main method… I am assuming this is attempting to be a general 
> facility - and thus the signature of f will vary.
> 
> you just need to wrap it with a closure, just as Eric did:
> 
> e.g.:
>  func QueryDB(a,b int) error { ... }
>  
>  WithContext(ctx, func() error {
> return QueryDB(42, 666)
>  })
> 
> and voila.
> 
> -s

-- 
You received this message because you are subscribed to the Google 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 want to run a go project called syncthing on iOS , but I have some issues

[m18742049357]

I tried to use "go install" but I got the same probrom.
I'm the first time using golang.I think if I have set the wrong go 
environment.But I set go environment for at least eight times.
I want to konw if I can run go project on iOS.I am a little sad.
在 2018年9月12日星期三 UTC+8下午2:18:51，Tamás Gulácsi写道：
>
> Why not just "go install" ?

-- 
You received this message because you are subscribed to the Google 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: [golang-dev] go doesn't need generics, but if they do...

[robert engels]

I am well aware of mechanical sympathy and the techniques (like the disrupter) 
used (I would counter that in many cases you are not writing “Java” due to the 
object pooling ,etc.)

What I’ve shown is that Java is already more performant than Go without using 
those techniques for many application aspects - specifically in terms of method 
dispatch, but still Go direct methods vs interface methods are 5x faster, so 
you if you need ultra performance critical code you need to keep that in mind, 
but RARELY is this the case (except for some people in HFT but even they have 
moved on to FPGAs) and you are far better structuring your code for 
maintainability and functionality rather than worrying about slower method 
dispatch...

ArrayList is not “correct” Java - because you are going to encode every 
byte as an object in an object[] behind the scenes, and each would need to be 
managed as an Object. Java has arrays, you would simply use a byte[]. If you 
need expandable arrays, you would probably use a ByteBuffer.

Your point highlights an important consideration - most people don’t know how 
to write REALLY performant software in a given language unless it is an area of 
focus and experience, which is why I distribute the tests publicly because I 
will grant that there may be techniques in Go that I am not understanding or 
misusing - but at this point I think I have a pretty good handle on the 
internal workings of Go.

The biggest performance advantage for Go will be the garbage collector due to 
the “value type” of array struct, since there is only a single reference to be 
GC managed regardless of the number of elements. That is not possible in Java - 
at least not now. That being said, there are Java VMs like Azul Zing that are 
far more performant than Go in terms of GC pauses without any restricting on 
the layout of the memory being managed. As soon as you start using array of 
interface in Go, you are going to put pressure on the GC, as the number of 
references that need to be managed expands proportional to the size of the 
array - at least I think so - but there may be behind the scenes escape 
analysis that determines if any references escape the array, and if not it can 
still manage it is a single reference.

But all of this is off-topic from the original post - which was to suggest to 
keep it simple and use interfaces/closures at runtime to support generics and 
not worrying about the performance overhead - the really performance critical 
coders can always write non-generic/interface containers if they absolutely 
think they need it, but most likely they don’t...

> On Sep 11, 2018, at 11:57 PM, Egon  wrote:
> 
> 
> 
> On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote:
> 
>> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > <>googlegroups.com > wrote:
>> 
>> [golang-nuts to CC, golang-dev to BCC]
>> 
>> On Mon, Sep 10, 2018 at 5:33 PM robert engels ix.netcom.com 
>> > wrote:
>> In the entire codebase of Docker I could find only one obvious use of 
>> interface{}, and no type casts.
>> 
>> Generics are not only useful for functions taking interface{}. They are also 
>> useful for functions taking non-empty interfaces, for cases where you could 
>> re-use an existing generic implementation and forego re-implementing it for 
>> your concrete type and for reducing boilerplate across many types (e.g. the 
>> famous sort.Interface).
> 
> True, and reviewing cockroachdb shows the sort.Interface used a lot, and a 
> generic container could avoid that, but in most cases this could be solved by 
> only having to implement Less and having ’sort’ work on slices - as the vast 
> majority are slices to begin with.
> 
> I am just attempting to point out that the original Go designers offered 
> ’typed’ collections (slice, map) as part of the language. They fall short in 
> some ways but it may be possible for a simpler solution to expand their 
> abilities, or add others, without resorting to generics. I like the 
> simplicity and readability “no surprises for the most part” of Go, and I 
> think it should try to stay that way.
> 
>> 
>> In my opinion, Go isn’t suitable for large enterprise systems with million+ 
>> lines of code
>> 
>> No offense, but empirically, the existence of such systems written in Go 
>> seems to contradict you here. Kubernetes has 3.5M lines of code in just the 
>> single main repository. And that's just open source software - most of the 
>> actual million+ lines of code systems written in Go you won't know about, 
>> because they are not open (I work on one of those).
> 
> This seems to contradict this a bit, 
> https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container
>  
> 
>  but it may be an indictment that 

Re: [go-nuts] Golang equivalent of Python's context manager

[Sebastien Binet]

On Wed, Sep 12, 2018 at 2:23 PM robert engels  wrote:

> I am pretty sure that is not correct, I am referring to:
>
> func WithContext(context Context, f func() error) error {
> context.__entry__()
> defer context.__exit__()
> return f()
> }
>
>
> You will need a lot of WithContext methods - based on the different
> signatures of function f.
>
> See the main method… I am assuming this is attempting to be a general
> facility - and thus the signature of f will vary.
>

you just need to wrap it with a closure, just as Eric did:

e.g.:
 func QueryDB(a,b int) error { ... }

 WithContext(ctx, func() error {
return QueryDB(42, 666)
 })

and voila.

-s

-- 
You received this message because you are subscribed to the Google 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 Developer contract opportunity at a Digital Ventures/Start-up Hub : backed by FTSE100 company

[alfie]

Hi, I'm a recruiter currently looking for Go developers to join a really 
innovative team working on market disruptive products, based in Central 
London. It's a contract opportunity for 6 months with strong cope of 
extensions, offering a negotiable day rate that depends on experience 
(ideally c.£600 per day).

I've not used a Google group to post an opportunity before, so sorry if 
it's not the done thing to do! But i'm trying new avenues as available Go 
developers are rare to come by (as you probably know!).

You must have previous commercial experience with Go to join this team.

What you’ll do:

- Build a range of APIs to serve multiple internal consumers ranging from 
customer facing
apps to machine learning pipelines
- Deliver high-quality, well-tested code
- Communicate with other teams and individuals to plan, coordinate and seek 
feedback
- Pitch in where needed as a valued member of an autonomous, 
cross-functional team

Please email me on al...@eaglecliff.co.uk with a copy of your CV ideally if 
you're interested in hearing more. I'll be very happy to share full job 
details and have a chat.

Many thanks!
Alfie

-- 
You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[robert engels]

I am pretty sure that is not correct, I am referring to:

> func WithContext(context Context, f func() error) error {
>   context.__entry__()
>   defer context.__exit__()
>   return f()
> }

You will need a lot of WithContext methods - based on the different signatures 
of function f.

See the main method… I am assuming this is attempting to be a general facility 
- and thus the signature of f will vary.


> On Sep 12, 2018, at 7:18 AM, Sebastien Binet  wrote:
> 
> 
> 
> On Wed, Sep 12, 2018 at 2:10 PM robert engels  > wrote:
> I think it would be problematic, as the callee signature is limited - func() 
> error - and with lack of method overloading you will need a lot of With 
> methods…
> 
> apart from the non-Go idiomatic names for the enter/exit interface method 
> set, I'd say it's fine.
> (well, Context is now kind of "reserved" to the context.Context interface, 
> but ok.)
> 
> it's also relatively easy to adapt to other functions that do not return an 
> error (as you show in your example.)
> that's what golang.org/x/sync/errgroup  
> does:
> - https://godoc.org/golang.org/x/sync/errgroup#Group.Go 
> 
> 
> > and with lack of method overloading you will need a lot of With methods…
> no need for that: it's an interface.
> 
> -s

-- 
You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[Sebastien Binet]

On Wed, Sep 12, 2018 at 2:10 PM robert engels  wrote:

> I think it would be problematic, as the callee signature is limited -
> func() error - and with lack of method overloading you will need a lot of
> With methods…
>

apart from the non-Go idiomatic names for the enter/exit interface method
set, I'd say it's fine.
(well, Context is now kind of "reserved" to the context.Context interface,
but ok.)

it's also relatively easy to adapt to other functions that do not return an
error (as you show in your example.)
that's what golang.org/x/sync/errgroup does:
- https://godoc.org/golang.org/x/sync/errgroup#Group.Go

> and with lack of method overloading you will need a lot of With
methods…
no need for that: it's an interface.

-s

-- 
You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[robert engels]

I think it would be problematic, as the callee signature is limited - func() 
error - and with lack of method overloading you will need a lot of With 
methods…

> On Sep 12, 2018, at 6:58 AM, Mirko Friedenhagen  wrote:
> 
> Hello,
> 
> in Python I may define context managers which do stuff before and after an 
> action has taken place.
> 
> E.g.:
> 
> ```
> class MyContext(object):
> def __enter__(self):
> print("Entering context")
> def __exit__(self, extype_unused, value_unused, traceback_unused):
> print("Exiting context")
> 
> if __name__ == "__main__":
> with MyContext():
> print("Inside the context")
> ```
> 
> will print:
> Entering context
> Inside the context
> Exiting context
> 
> A Golang equivalent I came up with is something like (see 
> https://play.golang.org/p/epBGtwZWuln as well)
> 
> ```
> package main
> 
> import "log"
> 
> type Context interface {
>   __entry__()
>   __exit__()
> }
> 
> func WithContext(context Context, f func() error) error {
>   context.__entry__()
>   defer context.__exit__()
>   return f()
> }
> 
> type MyContext struct {
>   message string
> }
> 
> func (context *MyContext) __entry__() {
>   log.Print("Entering ", context.message)
> }
> 
> func (context *MyContext) __exit__() {
>   log.Print("Exiting ", context.message)
> }
> 
> func main() {
>   var a string
>   WithContext({"Hallo"}, func() error {
>   log.Print("Inside context")
>   a = "Var from context"
>   return nil
>   })
>   log.Print(a)
> }
> ```
> 
> Is this idiomatic or are there better ways to implement stuff like this?
> 
> Regards
> Mirko
> 
> 
> -- 
> You received this message because you are subscribed to the Google 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] Golang equivalent of Python's context manager

[Mirko Friedenhagen]

Hello,

in Python I may define context managers which do stuff before and after an 
action has taken place.

E.g.:

```
class MyContext(object):
def __enter__(self):
print("Entering context")
def __exit__(self, extype_unused, value_unused, traceback_unused):
print("Exiting context")

if __name__ == "__main__":
with MyContext():
print("Inside the context")
```

will print:
Entering context
Inside the context
Exiting context

A Golang equivalent I came up with is something like 
(see https://play.golang.org/p/epBGtwZWuln as well)

```
package main

import "log"

type Context interface {
__entry__()
__exit__()
}

func WithContext(context Context, f func() error) error {
context.__entry__()
defer context.__exit__()
return f()
}

type MyContext struct {
message string
}

func (context *MyContext) __entry__() {
log.Print("Entering ", context.message)
}

func (context *MyContext) __exit__() {
log.Print("Exiting ", context.message)
}

func main() {
var a string
WithContext({"Hallo"}, func() error {
log.Print("Inside context")
a = "Var from context"
return nil
})
log.Print(a)
}
```

Is this idiomatic or are there better ways to implement stuff like this?

Regards
Mirko

-- 
You received this message because you are subscribed to the Google 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] Generics - Min challenge

['Axel Wagner' via golang-nuts]

ISTM that your requirements can't work. 2) and 3) imply that the expression
`x < y` with x,y of type T has to appear at least once in the function
body, which means it can never work for a type that doesn't have it.

I don't think that has anything to do with changing the type-checking rules
though. It's exactly what prevents contracts to be able to do it. In fact,
if it *would* be working, you could also make it work with contracts, by
just copying the function body into a contract.

On Wed, Sep 12, 2018 at 3:22 AM Patrick Smith  wrote:

> This is a hypothetical question. Suppose generics were implemented as in
> the draft proposal, but without contracts. Instead, the rule is that if an
> instantiation of a generic function with a specific type argument doesn't
> compile, then it can't be used.
>
> Under those circumstances, is there any way to write a function
>
> func Min(type T) (a, b T) T {...}
>
>
> that returns the smaller of its two arguments, and meets _all_ of these
> criteria?
>
> 1) If a specific type X has a suitable Less() method, then Min(X) uses
> that.
> 2) Otherwise, if the < operator can be applied to X, then Min(X) uses that.
> 3) Otherwise, any use of Min(X) fails to compile. (A run-time panic does
> not satisfy this criterion.)
>
> By "X has a suitable Less() method", I mean that this function should
> compile successfully:
>
> func XMin(a, b X) bool {
>
>return a.Less(b)
> }
>
>
> I'm fairly sure there's no way to write Min, but perhaps someone can prove
> me wrong?
>
> (With contracts I'm doubly sure it can't be done, as the contract for Min
> would have to permit both Less and <, so then Min(X) would only be allowed
> for types X having both Less and <.)
>

> --
> You received this message because you are subscribed to the Google 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] Generics - Min challenge

[Wojciech S. Czarnecki]

On Tue, 11 Sep 2018 18:22:12 -0700
Patrick Smith  wrote:

> I'm fairly sure there's no way to write Min, but perhaps someone can prove
> me wrong?

Within "Craftsman Go Generics" proposal its trivial:

func Min(a, b T) T {
  for type switch {
  case T func(T) Less(T) T:
  return a.Less(b)
  }
  if a < b {
   return a
  }
  return b
}

How does it work:

At compile time when compiler sees call to Min(a, b) with
any given type RTA compiler:

1. checks the first (and here single) case of whether T has
  Less method defined. If its true, then a Min variant of

  Min(a, b __TbyLess) __TbyLess {
return a.Less(b)
  }
  
  is instantiated. "__TbyLess" denotes that its an internal compiler
  representation and reminds that only single piece/part of code will ever
  be produced out of single "for type switch" case.
 
2. If it does not (have Less method) "for type switch" case does not match
   so "it does not exist" in regards to current type check, so now we have  

  func Min(a, b __TbyOtherMeans) __TbyOtherMeans {
if a < b {
   return a
}
   return b
}
  }

  Now if the type is NOT comparable, compiler says to us that we can not
  use Min with type RTA. (CGG  contracts operate on types, not on artificial
  statements).

  If RTA type is comparable, compiler makes variant of output code, hopefully
  marking it internally for reuse with wide class of base types.

  https://github.com/ohir/gonerics

> (With contracts I'm doubly sure it can't be done, as the contract for Min
> would have to permit both Less and <, so then Min(X) would only be allowed
> for types X having both Less and <.)

TC,

-- 
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] Go memory usage inside containers

[Henrik Johansson]

Afaik it works fine for Go programs  as long as these limits translates to
things like taskset etc.

ons 12 sep. 2018 kl 08:48 skrev Leigh McCulloch :

> Hi,
>
> Does anyone here know how Go interacts with memory limits inside
> containers? (e.g. Kubernetes, Docker)
>
> Does the Go runtime have similar problems as the Java runtime, in that it
> doesn't know what the container limit is, and only knows what the physical
> limit is for the entire instance?
>
> Or is Go aware of limits placed on the container?
>
> (I've witnessed the Go runtime package say the NumCPU is the total
> physical count when the app has been limited to many less CPUs, so it seems
> like it doesn't have visibility into the CPU limitations.)
>
> Thanks,
> Leigh
>
> --
> You received this message because you are subscribed to the Google 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] Re: http client POST/GET.. will not save cookie before do redirect request

[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=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] Go memory usage inside containers

[Leigh McCulloch]

Hi,

Does anyone here know how Go interacts with memory limits inside containers? 
(e.g. Kubernetes, Docker)

Does the Go runtime have similar problems as the Java runtime, in that it 
doesn't know what the container limit is, and only knows what the physical 
limit is for the entire instance?

Or is Go aware of limits placed on the container?

(I've witnessed the Go runtime package say the NumCPU is the total physical 
count when the app has been limited to many less CPUs, so it seems like it 
doesn't have visibility into the CPU limitations.)

Thanks,
Leigh

-- 
You received this message because you are subscribed to the Google 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] I want to run a go project called syncthing on iOS , but I have some issues

[Tamás Gulácsi]

Why not just "go install" ?

-- 
You received this message because you are subscribed to the Google 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.