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

On Wednesday, August 23, 2017 at 6:45:57 AM UTC+1, Henrik Johansson wrote: > 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 t

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

On Wednesday, August 23, 2017 at 3:24:26 AM UTC+1, Linker Lin wrote: > 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. > That will not happen. Please read the

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 disagr

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

OK, then I think you've answered your own question; your uses should handle the nils, rather than papering over them by assigning a pointer to "". If you expect to have "" when the value is empty, just use string. On Tue, 2017-08-22 at 17:39 -0700, Eric Brown wrote: > Yeah, sometimes it's better

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... https://dhdersch.github.io/golang/2016/01/23

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] Re: check for *string that is nil

Nevermind, found a dirty solution besides have to restructure my entire code-base to implement sql.NullString I was having trouble when populating contacts (which is []contact) with the individual query returns. I went from... contacts = append(contacts, contact) To using... nullString := ""

[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 Contac

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 *shoul

[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 impo

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 grou

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 A

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 by Minux's comment >>

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 stru

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 to golang-nuts+unsubs

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 { > Namestring > ID int32 >

[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 > where that's specif

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 in

[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

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

I would like to echo on Tong Sun's suggestion here. I know his isn't an "experience report" per se, but a suggestion worth building on, for those who're wishful of optionals in Go. The case mentioned might be immediately solvable by just using a pointer to the variable, which gives you the abil

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

FWIW, append is most often a small performance penalty when the number of elements is known ahead. And for some reason, using built-in func copy, or an explicit loop, is slightly faster on my workstation than BenchmarkConvert. Also, "small benchmarks are hard" so I suspect the small allocations i

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 out to be because

[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 fou

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 designers" is of course >

[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 > descr

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 t

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.

I disagree, I think we are doing Go a disservice with this line of reasoning. I may be alone in this sentiment and that is fine. tis 22 aug. 2017 kl 10:27 skrev Axel Wagner : > On Tue, Aug 22, 2017 at 9:56 AM, Henrik Johansson > wrote: > >> I am sorry but you are missing the point. I think there

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 to every other languag

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 underst

Re: [go-nuts] Calling Julia from Go

I would like to implement a pricing server. The pricings will be delivered by quants and should be changeable (scripted) without affecting the server architecture/ On Friday, August 18, 2017 at 1:17:43 AM UTC+2, kortschak wrote: > > What is it that you want to do in Julia? > > On Wed, 2017-08-

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 reiterati

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] Seemingly peculiar behavior with nil checks on pointers to structs encapsulating interfaces.

On Tue, Aug 22, 2017 at 03:00:18PM +0930, Dan Kortschak wrote: [...] > > Basically, if you encapsulate an interface in a struct, then call a  > > function who's signature states it will return a pointer to that > > struct, nil values returned from that function do not count as nil. [...] > This i

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 tha