Re: [go-nuts] Re: URL variables with net/http

2023-10-19 Thread Tim Casey
Gin does this directly. There is nothing complicated it does. Something like: group := engine.Group("/service/v1") group.GET("user/:id", handler) And then in the handler: id := c.Param("id") And the rest is what ever is yours. "engine" is a gin engine and 'c' is a gin context. On Thu, Oct

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

2023-10-11 Thread Tim Casey
I would put down Makefile includes for the supported targets and build each target at a time, as cross compiled shared libraries. This is easier for linux, harder for windows. But, you can build/export from docker containers as part of the overall build process to allow simulated build

Re: [go-nuts] Re: Parsing difficult JSON

2023-09-14 Thread Tim Casey
I solved this in some bizzaro way. Maybe what is needed is a json parser which is allowed to be multiple types. Or, another way to think about parsing which is easier on the type strictness, but still strongly typed. Like a duck typed struct of some sort. map[string]duck, where duck is allowed

Re: [go-nuts] Re: Error handling

2023-07-31 Thread Tim Casey
tires? That is like one time retires > won't work in an if-else block. > > Thanks again, > > On Monday, July 31, 2023 at 3:59:50 PM UTC-6 Tim Casey wrote: > >> >> >> I do not think this reduces boilerplate code. This compacts it, which is >> different. &g

Re: [go-nuts] Re: Error handling

2023-07-31 Thread Tim Casey
I do not think this reduces boilerplate code. This compacts it, which is different. I think any one-liner-return-on-err makes the language harder to debug. It is very common breakpoints are set for exceptional cases, which tend to be surprising. If the test and the return are on the same line