[go-nuts] [Proposal] database/sql: add interface that unite DB and Tx

[Mhd Shulhan]

## Problem

At some point we have a function that receive an instance of database 
connection to query rows in specific table.

Let's say that function F() accept DB that query table T.

If function F() called with DB instance, it will query only rows that has been 
committed into database.

IF function F() called with Tx instance, it will query all rows including the 
one that has not been committed yet into database.

Since DB and Tx are different types, we will have two functions that almost 
have identical code,

func F(db *sql.DB) (output int) {
  q := `SELECT … FROM T WHERE …`
  err := db.QueryRow(q).Scan()
  …
  return output
}

func FWithTx(tx *sql.Tx)(output int) {
  q := `SELECT … FROM T WHERE …`
  err := tx.QueryRow(q).Scan()
  …
  return output
}


## Proposed solution

Add an interface Session (the name is not fixed yet) to package sql with the 
following signature,

type Session interface {
func Exec(query string, args ...interface{}) (Result, error)
func ExecContext(ctx context.Context, query string, args ...interface{}) 
(Result, error)
func Prepare(query string) (*Stmt, error)
func PrepareContext(ctx context.Context, query string) (*Stmt, error)
func Query(query string, args ...interface{}) (*Rows, error)
func QueryContext(ctx context.Context, query string, args ...interface{}) 
(*Rows, error)
func QueryRow(query string, args ...interface{}) *Row
func QueryRowContext(ctx context.Context, query string, args 
...interface{}) *Row
}

Session interface is combination of DB and Tx that contains all identical 
methods.


## Rationale

Without Session, user will have two functions that have the same code,

By using Session, we can minimise duplicate code in the user level. for example 
using the previous problems definition the function F() become one,

func F(session sql.Session)(output int) {
  q := `SELECT … FROM T WHERE …`
  err := session.QueryRow().Scan()
  …
  return output
}


## Discussion

Any thought about this proposal?

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

Re: [go-nuts] Quantum mechanics mindshare is low & ~flat, per Google Trends

[Michael Jones]



On Wed, Jan 15, 2020 at 1:49 PM Dan Kortschak  wrote:

> Google Trends graph showing past 5y of Mechanic, Quantum mechanics
>
>
> https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F03f_s3,%2Fm%2F069dx
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0c3eba037a2697b9d5d39bf502a171da98c4113c.camel%40kortschak.io
> .
>
-- 

*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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQx1bERdDwcP97bmLkQ5h%2B%2BxYGGJdxV6JcYHPbB%3DegE_ug%40mail.gmail.com.

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

[Liam]

That could affect the level of a term, but wouldn't impact its trend much. 
Trends are the important insight of this graph.

On Wednesday, January 15, 2020 at 2:58:31 PM UTC-8, Robert Engels wrote:
>
>
> Please look deeper into how these "trends" are calculated.
>
> For example, if everyone that uses product Y can't figure out how feature 
> X works, and they search for it. Product Y will be showing growth...
>
> -Original Message- 
> From: Liam 
> Sent: Jan 15, 2020 4:18 PM 
> To: golang-nuts 
> Subject: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends 
>
> My point is that Go should be rising, since Java & C# are falling. Python 
> has gained significant mindshare, and Go is way better.
>
> I think something's amiss with the public perception of Go, but it's hard 
> to say what.
>
> On Wednesday, January 15, 2020 at 12:34:54 PM UTC-8, Liam wrote:
>>
>> Google Trends graph showing past 5y of Java, Python, C#, Node.js, Go
>>
>>
>> https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr
>>
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/8dc0b035-d5fe-4ccf-87d3-84c0978c881d%40googlegroups.com
>  
> 
> .
>
>
>
>
>

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

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

[Robert Engels]

Please look deeper into how these "trends" are calculated.For example, if everyone that uses product Y can't figure out how feature X works, and they search for it. Product Y will be showing growth...-Original Message-
From: Liam 
Sent: Jan 15, 2020 4:18 PM
To: golang-nuts 
Subject: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

My point is that Go should be rising, since Java & C# are falling. Python has gained significant mindshare, and Go is way better.I think something's amiss with the public perception of Go, but it's hard to say what.On Wednesday, January 15, 2020 at 12:34:54 PM UTC-8, Liam wrote:Google Trends graph showing past 5y of Java, Python, C#, Node.js, Gohttps://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8dc0b035-d5fe-4ccf-87d3-84c0978c881d%40googlegroups.com.




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

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

[Daniela Petruzalek]

If you look at python’s trajectory it took a while for it to become
mainstream. I suppose Go’s curve will be somewhat similar.

This is a very interesting talk on usage trends among
programming languages:
https://youtu.be/QyJZzq0v7Z4

On Wed, 15 Jan 2020 at 22:18 Liam  wrote:

> My point is that Go should be rising, since Java & C# are falling. Python
> has gained significant mindshare, and Go is way better.
>
> I think something's amiss with the public perception of Go, but it's hard
> to say what.
>
> On Wednesday, January 15, 2020 at 12:34:54 PM UTC-8, Liam wrote:
>>
>> Google Trends graph showing past 5y of Java, Python, C#, Node.js, Go
>>
>>
>> https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8dc0b035-d5fe-4ccf-87d3-84c0978c881d%40googlegroups.com
> 
> .
>
-- 
Daniela Petruzalek
Software Engineer
github.com/danicat
twitter.com/danicat83

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

[go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

[Liam]

My point is that Go should be rising, since Java & C# are falling. Python 
has gained significant mindshare, and Go is way better.

I think something's amiss with the public perception of Go, but it's hard 
to say what.

On Wednesday, January 15, 2020 at 12:34:54 PM UTC-8, Liam wrote:
>
> Google Trends graph showing past 5y of Java, Python, C#, Node.js, Go
>
>
> https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8dc0b035-d5fe-4ccf-87d3-84c0978c881d%40googlegroups.com.

[go-nuts] Quantum mechanics mindshare is low & ~flat, per Google Trends

[Dan Kortschak]

Google Trends graph showing past 5y of Mechanic, Quantum mechanics

https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F03f_s3,%2Fm%2F069dx

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

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Tom Payne]

Thanks again - I'm learning a lot here!

For info, the background here is that I've been writing code like:

  type T struct {
  SomeField int
  }

  func NewTFromJSON(data []byte) (*T, error) {
  var t T
  return , json.Unmarshal(data, )
  }

which wraps up error handling into a single line. This works when T is a
non-simple type as  does not change, even if the value of t does.

Writing this with T being a simple type, like int, results in the case
described in the original post:

  // NewIntFromJSON relies on undefined behavior, don't use it!
  func NewIntFromJSON(data []byte) (int, error) {
  var i int
  return i, json.Unmarshal(data, )
  }

So, in these cases I will do as Axel suggests and avoid the implicit
dependence on evaluation order.

A go vet check for this would be wonderful, even if it's not perfect. As
long as there aren't any false positives (i.e. warning when the code does
not in fact rely on unspecified behavior), it matters less if there are
false negatives (i.e. not warning when the code actually relies on
unspecified behavior). Maybe a simple test could catch the most common
cases.

On Wed, 15 Jan 2020 at 21:29, Ian Lance Taylor  wrote:

> On Wed, Jan 15, 2020 at 12:24 PM Tom Payne  wrote:
> >
> > Thanks all for the insight and explanation. Could I suggest tweaking the
> Go language specification to emphasize the separation, so it reads:
> >
> >"when evaluating the operands of an expression, assignment, or return
> statement, then all function calls, method calls, and communication
> operations are evaluated in lexical left-to-right order. Any operands that
> are variables take the value of the variable after all function calls,
> methods calls, and communication operations have been evaluated."
>
> That suggested addition is not correct.  The language deliberately
> does not specify when operands that are variables are evaluated.  They
> may be evaluated before function calls, they may be evaluated after.
> Different Go compilers make different decisions here.
>
> If we decided to specify it, I'm sure we would specify that the
> variables are evaluated in left to right order.
>
> Personally I think one good approach would be a vet check that
> complains about statements that both read and write a variable in an
> unspecified order.  But it's fairly hard to catch all possible cases
> of this.
>
> Ian
>

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

[go-nuts] Go mindshare is low & ~flat, per Google Trends

[Liam]

Google Trends graph showing past 5y of Java, Python, C#, Node.js, Go

https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr


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

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Ian Lance Taylor]

On Wed, Jan 15, 2020 at 12:24 PM Tom Payne  wrote:
>
> Thanks all for the insight and explanation. Could I suggest tweaking the Go 
> language specification to emphasize the separation, so it reads:
>
>"when evaluating the operands of an expression, assignment, or return 
> statement, then all function calls, method calls, and communication 
> operations are evaluated in lexical left-to-right order. Any operands that 
> are variables take the value of the variable after all function calls, 
> methods calls, and communication operations have been evaluated."

That suggested addition is not correct.  The language deliberately
does not specify when operands that are variables are evaluated.  They
may be evaluated before function calls, they may be evaluated after.
Different Go compilers make different decisions here.

If we decided to specify it, I'm sure we would specify that the
variables are evaluated in left to right order.

Personally I think one good approach would be a vet check that
complains about statements that both read and write a variable in an
unspecified order.  But it's fairly hard to catch all possible cases
of this.

Ian

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

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Robert Engels]

That is why this should be tightened down imo. It’s obscure cruft that needs to 
be accounted for when refactoring. 

> On Jan 15, 2020, at 2:23 PM, Tom Payne  wrote:
> 
> 
> Thanks all for the insight and explanation. Could I suggest tweaking the Go 
> language specification to emphasize the separation, so it reads:
> 
>"when evaluating the operands of an expression, assignment, or return 
> statement, then all function calls, method calls, and communication 
> operations are evaluated in lexical left-to-right order. Any operands that 
> are variables take the value of the variable after all function calls, 
> methods calls, and communication operations have been evaluated."
> 
> The presence or absence of function calls does make a difference here. In 
> this example the use of the identity() function changes the result of f():
> 
>   func identity(i int) int {
>   return i
>   }
> 
>   func modify(i *int) error {
>   *i = 1
>   return nil
>   }
> 
>   func f() (int, error) {
>   i := 0
>   return identity(i), modify() // returns 0, nil
>   }
> 
> 
>> On Wed, 15 Jan 2020 at 20:50, Robert Engels  wrote:
>> I disagree here. Knowing the order of operations/evaluation is part of 
>> knowing the language. If that’s the case it should be undefined (which 
>> forces a rewrite) not chose a behavior that seems contrary to the 
>> documentation and common practice in this area. 
>> 
 On Jan 15, 2020, at 1:39 PM, Axel Wagner  
 wrote:
 
>>> 
>>> I don't think "clearly this behavior is not what you would want" is a valid 
>>> generalization.
>>> 
>>>   type MyStruct{
>>>   // …
>>>   }
>>> 
>>>   func (x *MyStruct) initialize() error {
>>>   // does some common verification and populates some internal data 
>>> structures
>>>   return nil
>>>   }
>>> 
>>>   func New() (*MyStruct, error) {
>>>   x := {
>>>// default fields
>>>   }
>>>   return x, x.initialize()
>>>   }
>>> 
>>>   func NewWithFoo(f Foo) (*MyStruct, error) {
>>>x := {
>>> Foo: f,
>>>}
>>>return x, x.intialize()
>>>   }
>>> 
>>> You can say that you shouldn't do something like this, but it's IMO 
>>> reasonable code to write and it expects different behavior.
>>> 
>>> However, as per my previous e-mail, I would still prefer to rewrite this, 
>>> of course :)
>>> 
>>> 
 On Wed, Jan 15, 2020 at 8:33 PM Robert Engels  
 wrote:
 I think the way to look at it is “what would be the behavior of if you 
 were inline creating and initializing a struct containing both values” - 
 clearly this behavior is not what you would want or expect. 
 
 > On Jan 15, 2020, at 1:25 PM, Paul Jolly  wrote:
 > 
 > 
 >> 
 >>  "when evaluating the operands of an expression, assignment, or return 
 >> statement, all function calls, method calls, and communication 
 >> operations are evaluated in lexical left-to-right order."
 > 
 > My understanding goes as follows: the operands of the return statement
 > are i and modify(). The comma after "return statement" in the above
 > sentence is then important: because the only "function calls, method
 > calls, and communication operations" in that list of operands are (is)
 > modify().
 > 
 > Hence when i (as in the first operand) is evaluated is not specified.
 > And therefore it's dangerous to rely on it being one value or another
 > (which it could be given the example you provide).
 > 
 > There was even some discussion at the London Gophers November 2019
 > meetup (where the conundrum was very related
 > https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
 > about whether it would be possible to statically flag potential errors
 > like this.
 > 
 > -- 
 > You received this message because you are subscribed to the Google 
 > Groups "golang-nuts" group.
 > To unsubscribe from this group and stop receiving emails from it, send 
 > an email to golang-nuts+unsubscr...@googlegroups.com.
 > To view this discussion on the web visit 
 > https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to golang-nuts+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.com.
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> 

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Tom Payne]

Thanks all for the insight and explanation. Could I suggest tweaking the Go
language specification to emphasize the separation, so it reads:

   "when evaluating the operands of an expression, assignment, or return
statement, *then* all function calls, method calls, and communication
operations are evaluated in lexical left-to-right order. *Any operands that
are variables take the value of the variable after all function calls,
methods calls, and communication operations have been evaluated.*"

The presence or absence of function calls does make a difference here. In this
example  the use of the identity()
function changes the result of f():

  func identity(i int) int {
  return i
  }

  func modify(i *int) error {
  *i = 1
  return nil
  }

  func f() (int, error) {
  i := 0
  return identity(i), modify() // returns 0, nil
  }


On Wed, 15 Jan 2020 at 20:50, Robert Engels  wrote:

> I disagree here. Knowing the order of operations/evaluation is part of
> knowing the language. If that’s the case it should be undefined (which
> forces a rewrite) not chose a behavior that seems contrary to the
> documentation and common practice in this area.
>
> On Jan 15, 2020, at 1:39 PM, Axel Wagner 
> wrote:
>
> 
> I don't think "clearly this behavior is not what you would want" is a
> valid generalization.
>
>   type MyStruct{
>   // …
>   }
>
>   func (x *MyStruct) initialize() error {
>   // does some common verification and populates some internal data
> structures
>   return nil
>   }
>
>   func New() (*MyStruct, error) {
>   x := {
>// default fields
>   }
>   return x, x.initialize()
>   }
>
>   func NewWithFoo(f Foo) (*MyStruct, error) {
>x := {
> Foo: f,
>}
>return x, x.intialize()
>   }
>
> You can say that you shouldn't do something like this, but it's IMO
> reasonable code to write and it expects different behavior.
>
> However, as per my previous e-mail, I would still prefer to rewrite this,
> of course :)
>
>
> On Wed, Jan 15, 2020 at 8:33 PM Robert Engels 
> wrote:
>
>> I think the way to look at it is “what would be the behavior of if you
>> were inline creating and initializing a struct containing both values” -
>> clearly this behavior is not what you would want or expect.
>>
>> > On Jan 15, 2020, at 1:25 PM, Paul Jolly  wrote:
>> >
>> > 
>> >>
>> >>  "when evaluating the operands of an expression, assignment, or return
>> statement, all function calls, method calls, and communication operations
>> are evaluated in lexical left-to-right order."
>> >
>> > My understanding goes as follows: the operands of the return statement
>> > are i and modify(). The comma after "return statement" in the above
>> > sentence is then important: because the only "function calls, method
>> > calls, and communication operations" in that list of operands are (is)
>> > modify().
>> >
>> > Hence when i (as in the first operand) is evaluated is not specified.
>> > And therefore it's dangerous to rely on it being one value or another
>> > (which it could be given the example you provide).
>> >
>> > There was even some discussion at the London Gophers November 2019
>> > meetup (where the conundrum was very related
>> >
>> https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1
>> )
>> > about whether it would be possible to statically flag potential errors
>> > like this.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to golang-nuts+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.com
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/Q7KVGTFt3nU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1388A9A2-F321-459A-893E-6D90D42E7255%40ix.netcom.com
> 
> .
>

-- 

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Robert Engels]

I disagree here. Knowing the order of operations/evaluation is part of knowing 
the language. If that’s the case it should be undefined (which forces a 
rewrite) not chose a behavior that seems contrary to the documentation and 
common practice in this area. 

> On Jan 15, 2020, at 1:39 PM, Axel Wagner  
> wrote:
> 
> 
> I don't think "clearly this behavior is not what you would want" is a valid 
> generalization.
> 
>   type MyStruct{
>   // …
>   }
> 
>   func (x *MyStruct) initialize() error {
>   // does some common verification and populates some internal data 
> structures
>   return nil
>   }
> 
>   func New() (*MyStruct, error) {
>   x := {
>// default fields
>   }
>   return x, x.initialize()
>   }
> 
>   func NewWithFoo(f Foo) (*MyStruct, error) {
>x := {
> Foo: f,
>}
>return x, x.intialize()
>   }
> 
> You can say that you shouldn't do something like this, but it's IMO 
> reasonable code to write and it expects different behavior.
> 
> However, as per my previous e-mail, I would still prefer to rewrite this, of 
> course :)
> 
> 
>> On Wed, Jan 15, 2020 at 8:33 PM Robert Engels  wrote:
>> I think the way to look at it is “what would be the behavior of if you were 
>> inline creating and initializing a struct containing both values” - clearly 
>> this behavior is not what you would want or expect. 
>> 
>> > On Jan 15, 2020, at 1:25 PM, Paul Jolly  wrote:
>> > 
>> > 
>> >> 
>> >>  "when evaluating the operands of an expression, assignment, or return 
>> >> statement, all function calls, method calls, and communication operations 
>> >> are evaluated in lexical left-to-right order."
>> > 
>> > My understanding goes as follows: the operands of the return statement
>> > are i and modify(). The comma after "return statement" in the above
>> > sentence is then important: because the only "function calls, method
>> > calls, and communication operations" in that list of operands are (is)
>> > modify().
>> > 
>> > Hence when i (as in the first operand) is evaluated is not specified.
>> > And therefore it's dangerous to rely on it being one value or another
>> > (which it could be given the example you provide).
>> > 
>> > There was even some discussion at the London Gophers November 2019
>> > meetup (where the conundrum was very related
>> > https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
>> > about whether it would be possible to statically flag potential errors
>> > like this.
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google Groups 
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to golang-nuts+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1388A9A2-F321-459A-893E-6D90D42E7255%40ix.netcom.com.

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

['Axel Wagner' via golang-nuts]

I don't think "clearly this behavior is not what you would want" is a valid
generalization.

  type MyStruct{
  // …
  }

  func (x *MyStruct) initialize() error {
  // does some common verification and populates some internal data
structures
  return nil
  }

  func New() (*MyStruct, error) {
  x := {
   // default fields
  }
  return x, x.initialize()
  }

  func NewWithFoo(f Foo) (*MyStruct, error) {
   x := {
Foo: f,
   }
   return x, x.intialize()
  }

You can say that you shouldn't do something like this, but it's IMO
reasonable code to write and it expects different behavior.

However, as per my previous e-mail, I would still prefer to rewrite this,
of course :)


On Wed, Jan 15, 2020 at 8:33 PM Robert Engels  wrote:

> I think the way to look at it is “what would be the behavior of if you
> were inline creating and initializing a struct containing both values” -
> clearly this behavior is not what you would want or expect.
>
> > On Jan 15, 2020, at 1:25 PM, Paul Jolly  wrote:
> >
> > 
> >>
> >>  "when evaluating the operands of an expression, assignment, or return
> statement, all function calls, method calls, and communication operations
> are evaluated in lexical left-to-right order."
> >
> > My understanding goes as follows: the operands of the return statement
> > are i and modify(). The comma after "return statement" in the above
> > sentence is then important: because the only "function calls, method
> > calls, and communication operations" in that list of operands are (is)
> > modify().
> >
> > Hence when i (as in the first operand) is evaluated is not specified.
> > And therefore it's dangerous to rely on it being one value or another
> > (which it could be given the example you provide).
> >
> > There was even some discussion at the London Gophers November 2019
> > meetup (where the conundrum was very related
> >
> https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1
> )
> > about whether it would be possible to statically flag potential errors
> > like this.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.com
> .
>

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

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

['Axel Wagner' via golang-nuts]

And, just as an addendum: IMO, if the result depends on the order of
operations in a statement, prefer to rewrite it. Like, even if you are
satisfied with the behavior you are seeing *and* you can rely on it - it
should be clear by now that anyone looking at it will have to expand new
effort understanding it (and, you know, there might still be bugs in the
future). Rewriting the function call into its own statement gets rid of the
ambiguity and makes clear what's happening either way.

On Wed, Jan 15, 2020 at 8:25 PM Paul Jolly  wrote:

> >   "when evaluating the operands of an expression, assignment, or return
> statement, all function calls, method calls, and communication operations
> are evaluated in lexical left-to-right order."
>
> My understanding goes as follows: the operands of the return statement
> are i and modify(). The comma after "return statement" in the above
> sentence is then important: because the only "function calls, method
> calls, and communication operations" in that list of operands are (is)
> modify().
>
> Hence when i (as in the first operand) is evaluated is not specified.
> And therefore it's dangerous to rely on it being one value or another
> (which it could be given the example you provide).
>
> There was even some discussion at the London Gophers November 2019
> meetup (where the conundrum was very related
>
> https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1
> )
> about whether it would be possible to statically flag potential errors
> like this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com
> .
>

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

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Robert Engels]

I think the way to look at it is “what would be the behavior of if you were 
inline creating and initializing a struct containing both values” - clearly 
this behavior is not what you would want or expect. 

> On Jan 15, 2020, at 1:25 PM, Paul Jolly  wrote:
> 
> 
>> 
>>  "when evaluating the operands of an expression, assignment, or return 
>> statement, all function calls, method calls, and communication operations 
>> are evaluated in lexical left-to-right order."
> 
> My understanding goes as follows: the operands of the return statement
> are i and modify(). The comma after "return statement" in the above
> sentence is then important: because the only "function calls, method
> calls, and communication operations" in that list of operands are (is)
> modify().
> 
> Hence when i (as in the first operand) is evaluated is not specified.
> And therefore it's dangerous to rely on it being one value or another
> (which it could be given the example you provide).
> 
> There was even some discussion at the London Gophers November 2019
> meetup (where the conundrum was very related
> https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
> about whether it would be possible to statically flag potential errors
> like this.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.com.

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Paul Jolly]

>   "when evaluating the operands of an expression, assignment, or return 
> statement, all function calls, method calls, and communication operations are 
> evaluated in lexical left-to-right order."

My understanding goes as follows: the operands of the return statement
are i and modify(). The comma after "return statement" in the above
sentence is then important: because the only "function calls, method
calls, and communication operations" in that list of operands are (is)
modify().

Hence when i (as in the first operand) is evaluated is not specified.
And therefore it's dangerous to rely on it being one value or another
(which it could be given the example you provide).

There was even some discussion at the London Gophers November 2019
meetup (where the conundrum was very related
https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
about whether it would be possible to statically flag potential errors
like this.

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

Re: [go-nuts] [ANN] github.com/perillo/workon command

[Robert Engels]

You might find visual studio code appealing for your Go development. 

> On Jan 15, 2020, at 11:58 AM, Manlio Perillo  wrote:
> 
> 
> Hi.
> 
> I have several relatively small personal projects.  Every time I want to work 
> on them I need to launch a new terminal emulator and then open all the source 
> files with an editor.
> Doing it N times starts to become annoying.
> 
> For this reason I wrote the workon command.
> It will automatically start a terminal emulator at a Go specified project 
> path and open all [1] the project files with an editor.
> 
> It is available at https://github.com/perillo/workon.
> 
> Feedback is welcomed.
> Currently there are some issues, described in the README.md and main.go file.
> 
> [1] Use the equivalent of `go list ./...`
> 
> 
> Thanks
> Manlio Perillo
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/21921938-1a02-4bb3-a42e-5127d9617717%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/350B974B-525D-4D4E-9F0F-33FE6396B362%40ix.netcom.com.

[go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Tom Payne]

The Go language specification on order of evaluation 
 states:

  "when evaluating the operands of an expression, assignment, or return 
statement, all function calls, method calls, and communication operations 
are evaluated in lexical left-to-right order."

Consider the following program (also in the Go Playground 
):

  package main

  import (
  "fmt"
  )

  func modify(i *int) error {
  *i = 1
  return nil
  }

  func f() (int, error) {
  i := 0
  return i, modify()
  }

  func main() {
  i, _ := f()
  fmt.Printf("i == %d\n", i)
  }

I would expect return value from f() to be 0, nil, as, evaluated left to 
right the operands have values 0 and nil, but instead the return value is 
1, nil.

What is the explanation for what's actually happening here? Can I rely on 
this behavior or might it change in future versions of Go?

Cheers,
Tom

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c257ce1c-49af-4a19-8bfd-601df759ffe1%40googlegroups.com.

[go-nuts] [ANN] github.com/perillo/workon command

[Manlio Perillo]

Hi.

I have several relatively small personal projects.  Every time I want to 
work on them I need to launch a new terminal emulator and then open all the 
source files with an editor.
Doing it N times starts to become annoying.

For this reason I wrote the workon command.
It will automatically start a terminal emulator at a Go specified project 
path and open all [1] the project files with an editor.

It is available at https://github.com/perillo/workon.

Feedback is welcomed.
Currently there are some issues, described in the README.md and main.go 
file.

[1] Use the equivalent of `go list ./...`


Thanks
Manlio Perillo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21921938-1a02-4bb3-a42e-5127d9617717%40googlegroups.com.

[go-nuts] No "official" documentation suggest to use annotated tags for releasing a new module version

[Manlio Perillo]

Today I release my first release of a module.

Following https://blog.golang.org/publishing-go-modules, I create a non 
annotated tag.
When I pushed the code to github I noticed that the tag was not sent to the 
remote repository.
The option --follow-tags refuse to send not annotated tag.

The only article I found that use annotated tags is 
https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases, 
published 3 years ago.

https://github.com/golang/go/wiki/PackagePublishing don't use semver and
https://github.com/golang/go/wiki/Modules seems to use local tagging.
so I'm not sure what to change.


Thanks
Manlio Perillo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21cc34c8-63ef-41ad-8eeb-d0cd6f8459f0%40googlegroups.com.

[go-nuts] liteide x36.3 released

[visualfc]

Hi all, liteide x36.3 released!
This version update gotools for support Go Module. 

* LiteIDE Source code
    https://github.com/visualfc/liteide

* Release downloads
    * https://github.com/visualfc/liteide/releases/latest
    * https://sourceforge.net/projects/liteide/files
    * [baidu pan](https://pan.baidu.com/s/1wYHSEfG1TJRC2iOkE_saJg) password: 
jzrc

### 2020.01.15 Ver X36.3
* LiteIDE
    * fix and update gotools for support Go Module. 
    * refactor option, update all plugin option page
* LiteApp
    * refactor option page, load/save and keep option page.
* LiteEditor
    * fix code complete escape for Qt5.12
* Markdown
    * add CommonMark/cmark for markdown to html, replace sundown
* GolangPackage
    * add GOPRIVATE,GONOPROXY,GONOSUMDB option
    * add goproxy.cn for GOPROXY list
    * merge GOPATH/GoModule setup to global options.
* LiteBuild
    * add `go mod vendor` action
* DlvDebugger
    * update stack frame to RPC api
* gotools & gocode
    * fix fastmod match full version, example `github.com/mypkg/v2`
    * types check add basic type

Sent from YoMail for Gmail

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

Re: [go-nuts] Getting from a string to an object value - how?

['Vinay Sajip' via golang-nuts]

On Tuesday, 14 January 2020 21:58:01 UTC, Ian Lance Taylor wrote: 

> In general this is not possible in Go.  Sorry. 
>
> If you can restrict yourself to exported package-scope variables, then 
> you can probably use the debug/pe (on Windows) package to look up the 
> symbol name and use that value as the variable's address. 
>
> Or in some cases you can keep a registry of names that you need to find. 
>

OK, thanks for the response.

Regards,

Vinay Sajip

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d9ec7956-91df-40c5-85c7-08ff191df2ae%40googlegroups.com.

[go-nuts] Re: Is there a way to limit number or requests on a KeepAlive connection on net/http server?

[hao dong]

I don't think you can limit the number of requests by the 
*MaxRequestsPerConn* of fasthttp, because the Conn in this func is new 
struct created by fasthttp which stores in pool. Real client connections 
will be send to channels which be processed by these Conns.

For @ Tamás , Server.ConnState applies to net connections, not request on 
the keep-live connection.

On Monday, January 13, 2020 at 3:00:10 PM UTC+8, zohaib...@doordash.com 
wrote:
>
> Hey folks,
>
>  I've been digging around for a while but could not find anything; is 
> there something with builtin HTTP server that I can do to limit the maximum 
> number of requests allowed with KeepAlive connection? I found fast http 
> provides an option *MaxRequestsPerConn* to do so, 
> https://github.com/valyala/fasthttp/blob/59b28fe0e54664073ac4e422511ca8af718b26b0/server.go#L233-L239
>  is 
> there something out of the box too? If not I really want to stick to stock 
> net/http package; is there a quick cheap way to do that?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/05a4ceba-5ed0-4be7-8c3c-3e2544c63ccb%40googlegroups.com.

Re: [go-nuts] Getting a function's linked address?

[Julio Guerra]

For the record, I could do what I needed using the `//go:linkname` 
directive.

My instrumentation tool injects statements that need features from another 
package that I cannot import. So I forward declare functions using a given 
link name that is implemented in another package - similarly to what can be 
found in the stdlib.

This way, the forward declarations get resolved at link time - similarly to 
what you can do with `extern` with GCC.

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

[go-nuts] Re: How to make a server being server and client simultaneously

[GopherNewbie]

An exercise I am trying to do.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5d9a1cbb-ef51-4d79-a1ee-63958f7e68d6%40googlegroups.com.

[go-nuts] Re: How to make a server being server and client simultaneously

[Amnon Baron Cohen]

Is this homework?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9a6e6ea3-1040-42e6-be2f-8d901ad04bb5%40googlegroups.com.