Re: [go-nuts] Re: Gathering Ideas for Go 2.

I may suffer from a "fundamental lack of understanding" about many things but there isn't much to misunderstand in Russ blog post. I have also seen the talk. I simply disagree wrt generics. I appreciate that he has thought a lot about it and needs more feedback to feel it worth continuing. I

Re: [go-nuts] Re: Gathering Ideas for Go 2.

Hi,All! We must remember the tragedy of python 3.x . We should not separate the Go into 2 versions. If we launch Go 2 whatever the situation is, we must drop Go 1 immediately. On Wed, Aug 23, 2017 at 5:12 AM, sfrancia via golang-nuts < golang-nuts@googlegroups.com> wrote: > As one of the few

Re: [go-nuts] check for *string that is nil

Yeah, sometimes it's better to use a pointer to a string when dealing with possible null|nil values and you plan on deserializing json or yaml, which I'm doing a lot of for an api. There are a few other instances where you'd probably want to also...

Re: [go-nuts] check for *string that is nil

Is there a reason to have the fields be *string rather than just string? On Tue, 2017-08-22 at 15:48 -0700, Eric Brown wrote: > Let's say I have a struct... > > type Contact struct { >  Id    int `json:"id"` >  FirstName *string `json:"firstname"` >  LastName  *string `json:"lastname"` >

[go-nuts] check for *string that is nil

Let's say I have a struct... type Contact struct { Idint `json:"id"` FirstName *string `json:"firstname"` LastName *string `json:"lastname"` Email *string `json:"email"` Phone *string `json:"phone"` Ext *string `json:"ext"` } I define contact... var contact

Re: [go-nuts] Re: Gathering Ideas for Go 2.

And I forgot to mention a key point: There must be a separation of problems and solutions. It is critical as the problems are personally experienced out of necessity. Solutions, alternatively, need to remain independent of any individual so they can be evaluated objectively. We can and

[go-nuts] Re: "go get -u" and branch behavior on go1.6

Ran into the same problem and used `git branch -u origin ` before `go get -u` to fix this problem. But of course you need to set up the remote branch first. On Thursday, March 3, 2016 at 11:47:55 AM UTC-8, Garrett Heel wrote: > > I've noticed that doing a "go get -u" on go1.6 fails when you

Re: [go-nuts] Re: Gathering Ideas for Go 2.

As one of the few people who participates in the proposal review meeting I thought I'd shed some light on this. Go is intentionally simple. A lot of work has gone into the small balanced set of features. In fact prior to 1.0 a good number of features were removed as they weren't needed. The

Re: [go-nuts] Re: Go 2 suggestion - Types like "int?"

What you are asking for is captured in https://golang.org/issue/7054 On Tuesday, August 22, 2017 at 12:28:41 PM UTC-7, Steven Blenkinsop wrote: > > Other places where Go relies on every type having a zero value: > > // Making slices with non-zero length. > s := make([]*int, 10) > > //

[go-nuts] Re: Calling Once (in the code)

Just for the record, today I really needed this so here is this - primitive pkg, yet works for this purpose (mostly, and opinionated). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

Re: [go-nuts] Re: Go 2 suggestion - Types like "int?"

Other places where Go relies on every type having a zero value: // Making slices with non-zero length. s := make([]*int, 10) // Reslicing a slice beyond its length. s := make([]*int, 0, 10)[:10] // Eliding fields from a composite literal. p := struct { x: int; y: *int }

[go-nuts] Re: Best way to truncate a ridiculously long string in GO

Thanks Peter, this is very interesting. Indeed I would not have anticipated (though it makes some sense) that calling append would outperform the manual loop, when the prefix is big, despite the overhead of a builtin func call. On Tuesday, August 22, 2017 at 7:22:42 PM UTC+2, peterGo wrote: >

[go-nuts] Re: Best way to truncate a ridiculously long string in GO

Val, That's a lot of speculation! The original benchmark applies to the original question: prefix := verylongstring[:3] If we change the parameters of the benchmark then we expect to get different results. For example, read the Go gc compiler code. There's a stack/heap optimization for 32

[go-nuts] Extending net/http to make managing security relevant HTTP response headers easier

I'd appreciate feedback on a Go library I'm planning that might be of interest to people who write Go web frontends, https://tinyurl.com/sec-header-sets is the design doc. """ A proposed library that provides safe defaults (with opt-out) for security-relevant HTTP response headers. Background

Re: [go-nuts] Initializing Go Struct Literals

On Tue, Aug 22, 2017 at 11:09 AM, Tong Sun wrote: > First of all, thanks a lot for your solution andrey! > > Let me explain what I'm trying to do --- I'm trying to covert my struct > into map with github.com/fatih/structs > https://groups.google.com/d/msg/golang-nuts/eyYnelZF1zo/Z0IPBcArCwAJ > >

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

Yup, that's the one, thanks! (and retrospective thanks for the suggestion in the first place :-]) On 22 August 2017 at 15:03, Jan Mercl <0xj...@gmail.com> wrote: > On Tue, Aug 22, 2017 at 3:33 PM roger peppe wrote: > >> I *think* that the current implementation was inspired

Re: [go-nuts] Initializing Go Struct Literals

First of all, thanks a lot for your solution andrey! Let me explain what I'm trying to do --- I'm trying to covert my struct into map with github.com/fatih/structs https://groups.google.com/d/msg/golang-nuts/eyYnelZF1zo/Z0IPBcArCwAJ but the following gave me "panic: not struct" type Server

Re: [go-nuts] Initializing Go Struct Literals

On Tue, Aug 22, 2017 at 07:38:03AM -0700, Tong Sun wrote: > How to initialize a go struct like the following? > > type Server struct { > Namestring > ID int32 > Enabled bool > } This type definition looks pretty much OK. > s := struct { > Servers []Server{ > { >

Re: [go-nuts] Initializing Go Struct Literals

On Tue, Aug 22, 2017 at 4:38 PM Tong Sun wrote: https://play.golang.org/p/mKdRevvsH0 -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email

Re: [go-nuts] Initializing Go Struct Literals

It's not immediately obvious what you're trying to do, but here's one possible solution: https://play.golang.org/p/wrrDlvDISq On Tue, Aug 22, 2017 at 8:38 AM, Tong Sun wrote: > Hi, > > How to initialize a go struct like the following? > > type Server struct { > Name

[go-nuts] Initializing Go Struct Literals

Hi, How to initialize a go struct like the following? type Server struct { Namestring ID int32 Enabled bool } s := struct { Servers []Server{ { Name:"Arslan", ID: 123456, Enabled: true, }, { Name:"Arslan",

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

On Tue, Aug 22, 2017 at 3:33 PM roger peppe wrote: > I *think* that the current implementation was inspired by Minux's comment here: > https://groups.google.com/d/msg/golang-dev/G-uGL-jpOFw/vfazKS47_ckJ > > but I can't seem to find a comment from Russ that I seem to remember

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

This is a consequence of the decision to keep function pointers as single-word values. Discussion was here https://groups.google.com/forum/#!msg/golang-dev/G-uGL-jpOFw/pEFi6tsdkdUJ https://groups.google.com/d/msg/golang-dev/x328N8hiN5k/i5LJIXGmi_gJ I *think* that the current implementation was

[go-nuts] Re: Domain-driven design and go

Yeah that repo is really informative. I think it's a great source of info on the topic. On Tuesday, August 22, 2017 at 1:24:35 AM UTC-4, helloPiers wrote: > > This topic reminded me of this other thing I remember seeing: > https://github.com/marcusolsson/goddd - there are some further links to

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

On Tue, Aug 22, 2017 at 1:35 PM MartinG wrote: > In the below code example, setting a function variable to a simple function makes no memory allocation and is very fast (<1ns). The case of setting the same function variable to a method value is much slower (~30ns) and it turns

[go-nuts] Why does assigning a function variable to a method value allocate memory?

Hi, In the below code example, setting a function variable to a simple function makes no memory allocation and is very fast (<1ns). The case of setting the same function variable to a method value is much slower (~30ns) and it turns out to be because memory is allocated there. (16 B/op) I

Re: [go-nuts] Re: Gathering Ideas for Go 2.

You are right that there is a benefit analysis to be made. I just think the problems are more known than you do. On Tue, 22 Aug 2017, 12:08 Egon wrote: > On Tuesday, 22 August 2017 12:49:14 UTC+3, Henrik Johansson wrote: > >> The siphoning and "talking to other language

[go-nuts] Re: Best way to truncate a ridiculously long string in GO

A benchmark; https://play.golang.org/p/oUyeldDG5Q $ cat strslice_test.go package main import ( "strings" "testing" ) var ( s = strings.Repeat("a very, very long string", 4096) prefix string ) func BenchmarkNil(b *testing.B) { for i := 0; i < b.N; i++ { prefix

Re: [go-nuts] Re: Gathering Ideas for Go 2.

On Tuesday, 22 August 2017 12:49:14 UTC+3, Henrik Johansson wrote: > The siphoning and "talking to other language designers" is of course > related and I am sure that it happens. The community of compiler experts > seems not huge. I am aware of Ian's attempts to draft some proposals and >

Re: [go-nuts] Re: Gathering Ideas for Go 2.

The siphoning and "talking to other language designers" is of course related and I am sure that it happens. The community of compiler experts seems not huge. I am aware of Ian's attempts to draft some proposals and descriptions and that's what I am talking about. Experience reports will boil down

Re: [go-nuts] Re: Gathering Ideas for Go 2.

On Tuesday, 22 August 2017 10:56:52 UTC+3, Henrik Johansson wrote: > > I am sorry but you are missing the point. I think there already is a lot > of _experience_ that doesn't need reiterating. > > My obsolete C++ knowledge is not enough to do a proper comparison but > there are numerous experts

Re: [go-nuts] Re: Gathering Ideas for Go 2.

On Tue, Aug 22, 2017 at 9:56 AM, Henrik Johansson wrote: > I am sorry but you are missing the point. I think there already is a lot > of _experience_ that doesn't need reiterating. > This is a fundamentally flawed argument. By that logic, every language should be identical

Re: [go-nuts] Calling Julia from Go

Unfortunately, Julia cannot be compiled to a library. At least not that I am aware of. What could be done is linking/loading the Julia runtime libraries. That is what the author of the linked article tried. Here he hit some road blocks due to how Julia and Go manipulate the stack - if I

Re: [go-nuts] Re: Gathering Ideas for Go 2.

I am sorry but you are missing the point. I think there already is a lot of _experience_ that doesn't need reiterating. My obsolete C++ knowledge is not enough to do a proper comparison but there are numerous experts available inside the core team as well as outside. Why do you insist on

Re: [go-nuts] Testing that an implementation satisfies an interface in the standard library

On Mon, Aug 21, 2017 at 10:05:12PM +0200, 'Axel Wagner' via golang-nuts wrote: > > Satisfying a standard interface like io.Reader or io.Writer correctly is > > not just a matter matching the function signatures, but rather adhering to > > behaviour that is documented in comments > >

Re: [go-nuts] Re: Gathering Ideas for Go 2.

On Tuesday, 22 August 2017 09:12:45 UTC+3, Henrik Johansson wrote: > > I am sorry Dave but you can ignore the needs of the many few as much as > you want but the tiny things won't go away. > > There probably won't be any _written_ experience reports for most of the > little things. The things

[go-nuts] Re: Any idea why b.String() does not reflect the changes done in vim?

Thanks Dave, works fine :) On Monday, August 21, 2017 at 5:25:11 PM UTC+9, Dave Cheney wrote: > > Reopen the file after vim exists, it will be replacing the file by > renaming the vin .swp file, not overwriting its contents. -- You received this message because you are subscribed to the

Re: [go-nuts] Re: Gathering Ideas for Go 2.

I am sorry Dave but you can ignore the needs of the many few as much as you want but the tiny things won't go away. There probably won't be any _written_ experience reports for most of the little things. The things that people live through and sometimes just have the time to email the list about