[go-nuts] Re: Generics - please provide real life problems

What's the Big-O on determining whether N functions are a/ identical, b/ similar but expressing potentially unique behavior, c/ subtly varied. identical, assuming x and y have the same type: func (t *T) fX() bool { return t.x == t.z } func (t *T) fY() bool { return t.y ==

Re: [go-nuts] Go and AI Recommendations

I don't know what resources you have tried already so I'm probably going to state the obvious. You're probably looking for some language agnostic resources on the subject, since having it be Go specific will narrow your search. ML like any part of computer science can be described with algorithms

Re: [go-nuts] Import a submodule from its parent package?

On Sun, Dec 27, 2020 at 6:42 PM Aidan Hahn wrote: > > I am writing a modification to the os package in which I would like to take > advantage of code from the os/signal package. Ive written the patch (modified > os/exec_posix.go) and as I expected none of the symbols from os/signal are > define

Re: [go-nuts] Go and AI Recommendations

Go does not have much traction in ML and for good reasons: * not a single one organization or company is backing Go ML projects * with exception couple papers, no research in neither computer vision, NLP, or RL is done in Go, no papers are implemented in Go. It is mostly Pytorch these days. * Go

[go-nuts] Import a submodule from its parent package?

Hello, I am writing a modification to the os package in which I would like to take advantage of code from the os/signal package. Ive written the patch (modified os/exec_posix.go) and as I expected none of the symbols from os/signal are defined in the os package. My question is how I can import

Re: [go-nuts] Generics - please provide real life problems

On Sun, Dec 27, 2020 at 3:51 PM Jesper Louis Andersen wrote: > I need a heap over any type which can be ordered, and its needs to drag > around any type of satellite data. I'm confused. Isn't that what https://golang.org/pkg/container/heap/#Interface provides already? -- You received this mes

Re: [go-nuts] Go and AI Recommendations

I think you might be better off learning AI/ML using Python - to understand the concepts - most tutorials use Python/Colab as well since it is so easy. Once you understand the concepts you can use Go libraries  to implement the

Re: [go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

@Arnaud: I tend to agree that it's a downside of having two ways to do things. However, I don't know how we would get the actually additive expressive power of generics without that downside. If you have any ideas, that would be great. @Robert: I think sweeping statements about the performance of

[go-nuts] Go and AI Recommendations

I am an experienced developer and fairly knowledgeable in Go, but new to AI and machine learning. I'd like to expand my skillset in that direction. I would be happy for and recommendations and advice on good material for learning AI and machine learning with Go. Most of the material out there seem

Re: [go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

Makes sense. I just attempted to quantify the overhead and it looks like it's at least 2x on my machine, which is not as trivial a performance bump as I had imagined, so thanks for the push back. There are clearly some uses for which this pattern is going to be desirable for the performance benefi

Re: [go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

That is not true. The generic version can have significant performance implications for low-level/tight-loop functions as it will avoid the indirection required for interface method dispatching (at the expensive of code explosion for common calls with lots of types). > On Dec 27, 2020, at 11:31

Re: [go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

I understand the difference, but that doesn't prevent me from having to choose between the two implementations. To simplify greatly, and as you pointed out in your reply, there is a tension between "simplicity" (non-generic) and "performance" (generic), and that is where I fear the friction wi

Re: [go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

Since in this case the use of generics doesn't let you do anything new, I would argue that the KISS principle applies and the non-generic version should be preferred. I think a linter can be added to go vet to warn about instances like this one (where the type parameter can be replaced by the type

[go-nuts] Re: datastore.RunInTransaction

Thanks. I see now that if err == nil in the following code snippet, then the for loop will end. Not sure why I find the effect of this err check confusing, but I do. Probably its dual-use is the culprit. Return on happy path (i.e., err == nil) and return on most errors. if cmt, err := tx.Co

Re: [go-nuts] Generics - please provide real life problems

If Go with generics wax released tomorrow I have about 8 kubernetes controllers that I'd be porting to use a type safe version of the work queue to. This isn't theoretical, I will do this week 1 of generics being available. It is all production code. On Thu, 24 Dec 2020, 06:15 Martin Hanson,

Re: [go-nuts] Generics - please provide real life problems

On Thu, Dec 24, 2020 at 7:15 AM Martin Hanson wrote: > I therefore propose that the pro-generics camp provide real examples of > problems they have faced that was such a big issue that it justifies > adding generics to Go. > > Maintaining type safety is a lot easier with generics. Right now, my c

Re: [go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

In my opinion, the issue is that there are two ways to express (almost) the same thing and that in itself creates friction in the language. There may be a valid reason to choose one version over the other, but every time it will be necessary to review the pros and cons of each alternative. If we

[go-nuts] Re: datastore.RunInTransaction

Jeff, Retry if err == ErrConcurrentTransaction. Peter On Saturday, December 26, 2020 at 10:54:36 PM UTC-5 Jeff wrote: > I was curious how datastore.RunInTransaction was implemented in comparison > to the Transaction method set so I took quick look at the source code. > However, I hope I am s