Re: [go-nuts] [ANN] Koazee a library inspired by functional programming and lazy evaluation that takes the hassle out of working with arrays

I just created a new thread in which I've published a benchmark comparison of Koazee with Go-Funk and Go-Linq https://groups.google.com/forum/#!topic/golang-nuts/BfGPIzNsxsM The article can be found here: https://medium.com/@ivan.corrales.solera/koazee-vs-go-funk-vs-go-linq-caf8ef18584e I hop

[go-nuts] Koazee vs Go-Linq vs Go-Funk

Hey all, I am working on Koazee, a library to deal with slices in a functional way. Since I published the very first release I was asked me for publishing a benchmark comparison with other existing and matured frameworks. that provide similar functionality. I hope you find useful this article

[go-nuts] Re: Newbie question about struct definition

Awesome!!! Thank you very much Brian Regards = Freddy Martínez García Software Engineer B.S. Computer Science LinkedIn: https://ar.linkedin.com/in/freddy-martinez-garcia-47157259 *“If you give someone a program, you will frustrate them for a day;if

Re: [go-nuts] Newbie question about struct definition

Hi Freddy! Those are Struct Tags (see here for more ) and are a way to add some metadata to struct fields that can be accessed via reflection. Lots of libraries use these to denote names or other notes about each fields. Those libraries expect to have a "known" st

[go-nuts] Newbie question about struct definition

Hey guys, I’ve been learning Go for the lat couple of weeks but now that I’m looking to more advanced topics, I’ve seen things like type Person struct { FirstName string `db:"first_name"` LastName string `db:"last_name"` Email string } What `db:”first_name”` means ? Regards =

Re: [go-nuts] Package Stutter

On Mon, Dec 3, 2018 at 4:25 PM Robert Engels wrote: > > Btw, I am working on some issues/proposals/tools that I think will help the > situation - not just complaining. I'd like to hear more about what you're planning to do. > > > On Dec 3, 2018, at 5:19 PM, Robert Engels wrote: > > > > Probabl

[go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

Ah yes, that's a nice way -- thanks. Still has the issue that it's fairly easy to forget ... oh well. -Ben On Monday, December 3, 2018 at 7:17:21 PM UTC-5, Jesse Rittner wrote: > > In this situation, we normally use named return variables. That way we can > just check if we are returning with a

[go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

In this situation, we normally use named return variables. That way we can just check if we are returning with an error in the defer. func DoTwoThings() (retErr error) { tx, err := db.Begin() if err != nil { return err } defer func() { if retErr != nil {

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

The best way to access the return value of a function is to name the return variable: func DoTwoThings(db *Database) (err error) { tx, err := db.Begin() if err != nil { return err } defer tx.Close(&err) ... } Then any accidental shadowing doesn't matter because the "defer" is referring to the

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

Go vet will report this as a problem. > On Dec 3, 2018, at 5:54 PM, Ben Hoyt wrote: > > Robert, here is code (actual working code this time) similar to what we have: > https://play.golang.org/p/jUPqgnk6Ttk > > Leonel, yep, I understand that, which is why we have this problem. The thing > is,

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

Robert, here is code (actual working code this time) similar to what we have: https://play.golang.org/p/jUPqgnk6Ttk Leonel, yep, I understand that, which is why we have this problem. The thing is, this pattern makes it very easy to forget to always re-use the same error variable, especially in cod

[go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

Hi Ben, I'm pretty sure that the *err* variable is getting shadowed on your Update construct. Instead of doing: if _, err := UpdateBar(tx); err != nil { return err } You should do something like: _, err = UpdateBar(tx) if err != nil { return err } Just like you do with the insert

Re: [go-nuts] Package Stutter

Btw, I am working on some issues/proposals/tools that I think will help the situation - not just complaining. > On Dec 3, 2018, at 5:19 PM, Robert Engels wrote: > > Probably another thread unto itself, and some of the issues have already been > corrected like the addition of modules. > > On

Re: [go-nuts] Package Stutter

Probably another thread unto itself, and some of the issues have already been corrected like the addition of modules. One of the biggest is dynamic code changes at runtime, while debugging, a lot of web apis, etc. Often there’s a lot of steps to get to X in an enterprise app. It’s a much slow

Re: [go-nuts] Best way to handle database transactions? (commit, or rollback on error)

Then there should only be a single err variable, and the address should not change. Not sure why it isn’t working are you sure you are not in a code block that is causing a shadowing of err? > On Dec 3, 2018, at 4:54 PM, Ben Hoyt wrote: > > Ah, quite right. That's what comes of trying to m

Re: [go-nuts] Best way to handle database transactions? (commit, or rollback on error)

Ah, quite right. That's what comes of trying to modify the code snippet from our actual code on the fly. It was more like: t, err := InsertFoo(tx) -Ben On Mon, Dec 3, 2018, 5:50 PM Robert Engels How can you write this > > err := InsertFoo(tx) > > Don’t you get no new variables defined error he

Re: [go-nuts] Best way to handle database transactions? (commit, or rollback on error)

How can you write this err := InsertFoo(tx) Don’t you get no new variables defined error here? > On Dec 3, 2018, at 3:53 PM, Ben Hoyt wrote: > > Hi folks, > > We found some subtle bugs in our db transaction code for handling > commits/rollbacks. Here's the pattern we were using (not real, bu

[go-nuts] Generic function aliases

Type aliases appear in the contracts draft design. Has anyone suggested alias declarations for generic functions? This would simplify syntax for callers... package g func G(type T)(i T) error { ... } --- package main import "g" func Gi g.G(int) // declare alias func f() { Gi(1) } -- You

[go-nuts] Best way to handle database transactions? (commit, or rollback on error)

Hi folks, We found some subtle bugs in our db transaction code for handling commits/rollbacks. Here's the pattern we were using (not real, but shows the issue): func DoTwoThings() error { tx, err := db.Begin() if err != nil { return err } // commit or rollback the transa

Re: [go-nuts] Package Stutter

On Sun, Dec 2, 2018 at 11:09 PM Robert Engels wrote: > > I agree that is an important consideration, but it seems less important if > the packages are small and focused. > > I think an important point to consider is that there are systems apps, and > enterprise apps. These rules seem well suited

Re: [go-nuts] errgroup example without channels

* Mu11 [181203 11:47]: > I saw the example > of > errgroup in godoc, and it makes me confused that it simply assigns the > result to global results instead of using channels in each search routines. > Heres the code: > > G

Re: [go-nuts] Rethink possibility to make circular imports

Hi everyone. I think for the moment I will agree that it would bring more pain to allow circular imports in Go than it would solve problems. One of the most convincing arguments I have read here so far is that it would probably cause many design flaws all around and make many packages very hard to

Re: [go-nuts] Getting .slide of Golang Talks

On Mon, Dec 3, 2018, at 10:28, Andrew Frances wrote: > Is it possible to get the .slide files for the > Golang Talks https://talks.golang.org/ so I can have more examples (I don't > really need all the accompanying files)? https://github.com/golang/talks -- You received this message because you

Re: [go-nuts] JSON dynamic keys

You might be interested to take a look at how we do it in the elasticsearch client we wrote for one of our services: https://godoc.org/gopkg.in/juju/charmstore.v5/elasticsearch On Mon, 3 Dec 2018 at 15:27, Jeffrey Smith wrote: > I'm trying to set mapping in elastic search in go and want to gene

[go-nuts] Re: .net core vs go

Good show. Being a lone warrior. Some hate Microsoft so badly for no apparent reason while they seem to love Apple ! :) There is no reason for such hatred - given their love for Apple or even Google. .Net Core is solid and Go feels totally "incomplete" to me. You cannot model an abstraction th

[go-nuts] Getting .slide of Golang Talks

Hi Folks: I know this is a strange request. I am learning Golang Present. So far, I am enjoying Present. There are a few things I do not know how to do (i.e., change the colour of text, or have a page without a title with a quote centered in the middle). Is it possible to get the .slide files for

Re: [go-nuts] JSON dynamic keys

In addition to Burak's suggestion, keep in mind that if you implement MarshalJSON and/or UnmarshalJSON for certain structs, then those will be used instead of the built-in functions. If you end up cleaning up your struct definitions and just cant find the right way to annotate your fields to get th

[go-nuts] errgroup example without channels

I saw the example of errgroup in godoc, and it makes me confused that it simply assigns the result to global results instead of using channels in each search routines. Heres the code: Google := func(ctx context.Context, q

Re: [go-nuts] JSON dynamic keys

On Mon, Dec 3, 2018 at 9:29 AM Burak Serdar wrote: > > On Mon, Dec 3, 2018 at 9:06 AM Jeffrey Smith > wrote: > > > > That is 99% of what I'm after cheers. > > > > I need to be able to set the _doc bit to be any random string if possible > > as its the type name. > > > > `json:"_doc"` > > > Nest

Re: [go-nuts] Package Stutter

I don’t think that’s an issue. You only have references to both Employee in the integration code, and that should probably always use fully qualified names - if I’m understanding your concerns, but I’m not sure I am. > On Dec 3, 2018, at 10:23 AM, Bakul Shah wrote: > > > >> On Dec 3, 2018,

Re: [go-nuts] JSON dynamic keys

On Mon, Dec 3, 2018 at 9:06 AM Jeffrey Smith wrote: > > That is 99% of what I'm after cheers. > > I need to be able to set the _doc bit to be any random string if possible as > its the type name. > > `json:"_doc"` Nested maps are messy to deal with. In my opinion, your best bet is a custom mar

Re: [go-nuts] Package Stutter

Whilst not exaclty the peek of modern tooling, grep is one method of checking where and how your package is used. That's a lot clearer without dot imports. I've never used a dot import, and don't think I have seen one in the wild. Allowing dot imports feels like a bit of a wart (but one that is e

Re: [go-nuts] Package Stutter

> On Dec 3, 2018, at 8:08 AM, Robert Engels wrote: > > I understand that, and when working in code that uses both types, which is > probably limited, you fully qualify. This is pretty standard stuff in the > enterprise world, as well architected solutions are segmented, so you only > encoun

Re: [go-nuts] Package Stutter

Anyway, thanks all for the input. I am continuing to review other large code based for real world examples for what works and what doesn’t and having the input of the community makes understanding the conventions easier. > On Dec 3, 2018, at 10:08 AM, Robert Engels wrote: > > I understand tha

Re: [go-nuts] Package Stutter

I understand that, and when working in code that uses both types, which is probably limited, you fully qualify. This is pretty standard stuff in the enterprise world, as well architected solutions are segmented, so you only encounter this problem at the integration points, and that code is quali

Re: [go-nuts] JSON dynamic keys

That is 99% of what I'm after cheers. I need to be able to set the _doc bit to be any random string if possible as its the type name. `json:"_doc"` On Monday, December 3, 2018 at 3:53:34 PM UTC, Burak Serdar wrote: > > On Mon, Dec 3, 2018 at 8:27 AM Jeffrey Smith > > wrote: > > > > I'm try

Re: [go-nuts] Package Stutter

On Dec 3, 2018, at 6:52 AM, Robert Engels wrote: > > I think people are misunderstanding my equal footing need. I don’t mean for > all applications, I mean for a application. > > Here’s another example. You have a enterprise payroll application. You have a > model package. You have model.Empl

Re: [go-nuts] JSON dynamic keys

On Mon, Dec 3, 2018 at 8:27 AM Jeffrey Smith wrote: > > I'm trying to set mapping in elastic search in go and want to generate > something like this. > > { "mappings": { "_doc": { "properties": { "title": { "type": "text", "store": > true }, "date": { "type": "date", "store": true }, "content":

Re: [go-nuts] Package Stutter

On Mon, 3 Dec 2018 at 14:52, Robert Engels wrote: > I think people are misunderstanding my equal footing need. I don’t mean > for all applications, I mean for a application. > > Here’s another example. You have a enterprise payroll application. You > have a model package. You have model.Employee

[go-nuts] JSON dynamic keys

I'm trying to set mapping in elastic search in go and want to generate something like this. { "mappings": { "_doc": { "properties": { "title": { "type": "text", "store": true }, "date": { "type": "date", "store": true }, "content": { "type": "text" } } } } } The _doc, title,date and content a

Re: [go-nuts] Package Stutter

I thought the main was special cased, since the app band is based on the directory not the package. > On Dec 3, 2018, at 3:04 AM, roger peppe wrote: > > On Mon, 3 Dec 2018 at 07:40, robert engels wrote: > > Roger, > > > > I experimented with the import name (rather than dot import), and cam

Re: [go-nuts] Package Stutter

I think people are misunderstanding my equal footing need. I don’t mean for all applications, I mean for a application. Here’s another example. You have a enterprise payroll application. You have a model package. You have model.Employee. Having to use model.Employee throughout the application

Re: [go-nuts] [ANN] Koazee a library inspired by functional programming and lazy evaluation that takes the hassle out of working with arrays

I fully understand and completely agree with you... It's hard but I will try to do it, Thanks again for advice On Mon, Dec 3, 2018 at 3:21 PM Marko Ristin-Kaufmann wrote: > Hi Iván, > Thanks for taking the time to make the benchmarks! > > However, it only makes sense to compare your framework

Re: [go-nuts] [ANN] Koazee a library inspired by functional programming and lazy evaluation that takes the hassle out of working with arrays

Hi Iván, Thanks for taking the time to make the benchmarks! However, it only makes sense to compare your framework against the other frameworks running in the same setting (same machine, same OS *etc.*), hence your current benchmarks tell us very little. IMO, your best bet to popularize your frame

Re: [go-nuts] Package Stutter

On Dec 2, 2018, at 11:39 PM, robert engels wrote: > > what I’m really trying to convey is that “Fixed” is a top-level type, on > equal footing with ‘string’. a) it is *not* on equal footing with the built in types of Go. b) it can't be, as "Fixed" by itself not well defined. The Fixed type i

Re: [go-nuts] Package Stutter

On Mon, Dec 3, 2018 at 10:05 AM roger peppe wrote: > That said, you could do: > > type fixed = fixed.Fixed FTR: That's invalid code, it redeclares 'fixed'. (Go forbids the same identifier to live in package scope and file scope.) -- You received this message because you are subscribed to the G

Re: [go-nuts] Package Stutter

On Mon, 3 Dec 2018 at 07:40, robert engels wrote: > Roger, > > I experimented with the import name (rather than dot import), and came up with this: > > type Order struct { >sync.RWMutex >Instrument >Id OrderID >ExchangeId string >Price n.Fixed >Side >Quanti