Our great sponsors
-
rzgrep
grep utility that searches through zip,jar,ear,tgz,bz2 in any form of nesting; it can also decompile class files
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I think so, too, but only because that’s idiomatic go. In general, it’s not a good idea to have functions that logically return a value or an error return a value and an error. If you use go, that’s what you do, though.
I see that that was changed already (https://github.com/MoserMichael/rzgrep/commit/764b9ad61a5dbe...)
I think I would not return “ctx.data[0]” for the value returned in case of error, though, but either
- a fresh new instance of T
- a special instance of T created once
The first is cleanest, but may not be performant if creating T’s is costly.
The second may be risky if the returned items are mutable and the caller changes them.
My personal experience with generics was to port a parallel circular queue library (used to take interface{} and require a type cast at every use) add an experiment to build all the Lodash slice and collection functions in Go.
Happy to say that both worked really well. Took me less than an hour to understand the system enough for these purposes, and the implementation hides neatly in the library - the code that uses the library has absolutely no mention of anything generic. Having generics also helped switch to cleaner implementation inside as well, because I could now use maps as well without type casts.
Looks like a solid useful system - I could do everything I wanted, all the complexity stays in the library, and changes were pretty minimal and easy to understand. Would recommend.
https://github.com/sudhirj/cirque
https://github.com/sudhirj/slicy
My personal experience with generics was to port a parallel circular queue library (used to take interface{} and require a type cast at every use) add an experiment to build all the Lodash slice and collection functions in Go.
Happy to say that both worked really well. Took me less than an hour to understand the system enough for these purposes, and the implementation hides neatly in the library - the code that uses the library has absolutely no mention of anything generic. Having generics also helped switch to cleaner implementation inside as well, because I could now use maps as well without type casts.
Looks like a solid useful system - I could do everything I wanted, all the complexity stays in the library, and changes were pretty minimal and easy to understand. Would recommend.
https://github.com/sudhirj/cirque
https://github.com/sudhirj/slicy
I don't think this is right. Every source I can find says that Go does not currently move heap variables, but it reserves the right to, and code that assumes no movement is wrong.
I also found code that demonstrates stack variables being moved despite a pointer to them, but it's version dependent so I can't test it.
When a variable is moved, then obviously pointers to it need to be updated, but that's not an intractable problem.
Looking further, Go doesn't even provide an API for pinning objects right now[1]. You have to do weird workarounds to allocate static objects, or write code that assumes nothing on the heap moves and will explode if that ever changes.
[1] https://github.com/golang/go/issues/46787