[go-nuts] Re: Implement generic type interface

GoLand' support for generics is in alpha stage today, false negatives are pretty common and this is your case. понедельник, 24 января 2022 г. в 20:02:09 UTC+3, ka...@swit.io: > Before the question, I'm sorry I'm not good at English > > when go 1.18 beta released, i try to test generic type >

Re: [go-nuts] Re: Generating go code using go templates

u have big files you can't check syntax >> easily, don't know how it looks and if you have errors in the template it >> is really hard to fix them. >> So the protoc-gen-go case is preferable. >> >> вс, 19 сент. 2021 г. в 04:33, Denis Cheremisov : >> >>>

[go-nuts] Re: Generating go code using go templates

Templates is the worst approach to code generation IMO. Take a look how they do this in protoc-gen-go: https://github.com/protocolbuffers/protobuf-go/blob/b92717ecb630d4a4824b372bf98c729d87311a4d/cmd/protoc-gen-go/internal_gengo/main.go#L83 I am using very similar approach, albeit I prefer

[go-nuts] Re: [Macos/Apple M1] some fork/exec … operation not permitted error

Found what causes this. An extended Apple attribute apple.com.quarantine. Set it off, then need to set off some other utilities and now it is done. вторник, 8 декабря 2020 г. в 18:07:17 UTC+3, Denis Cheremisov: > Hi! I installed Go via sources > > $ go version > go version devel

[go-nuts] [Macos/Apple M1] some fork/exec … operation not permitted error

Hi! I installed Go via sources $ go version go version devel +9c91cab0da Tue Dec 8 01:46:45 2020 + darwin/arm64 got better performance than I had with my aging Core i5 4670k, etc, this was expectable, no surprises here. But, there's an issue. When I call `go get`, `go install`, etc via

[go-nuts] Re: Any recommendation for structured logging library in Golang?

Zerolog does the trick, need a bit of setup though for what you want среда, 18 ноября 2020 г. в 07:21:48 UTC+3, ChrisLu: > I am considering moving from glog to structured logging. I tried logrus, > go-kit, uber/zap, but could not find one good fit. In short, this is the > desired format: > >

Re: [go-nuts] Licence details of github.com/golang/sync

r the same note too, so we will have fun times :) четверг, 29 октября 2020 г. в 20:09:59 UTC+3, ohir: > Dnia 2020-10-29, o godz. 06:52:17 > Denis Cheremisov napisał(a): > > > Hi! > > At my job we found these additional patents > > limitatations https://githu

[go-nuts] Licence details of github.com/golang/sync

Hi! At my job we found these additional patents limitatations https://github.com/golang/sync/blob/master/PATENTS They makes us impossible to use errgroup (which is, to say, turned to have pretty poor choice of WithContext signature, so our one is different), so we have our custom implementation

Re: [go-nuts] Re: protobuf avoid namespace conflict

It is because you import protoc-gen-go generated entities with exactly the same package name and their own name. This is not allowed with protobuf, you can only have a single .. You can either use different names for error packages or use a 3rd repository with generated code. среда, 30

Re: [go-nuts] how to use replace directives in go.mod in dev but not prod

CI probably is the anwser, made a utility based on golang.org/x/mod which parses go.mod and checks if replaces are there and exit with error state if they are. вторник, 22 сентября 2020 г. в 11:21:55 UTC+3, Paul Jolly: > 26640 is an open issue describing the same problem you're describing. >

[go-nuts] Re: [ generics] Moving forward with the generics design draft

Oops, I meant "all interfaces can be used as a constraint yet there are interfaces that can be used as a value's type" -- 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

[go-nuts] Re: [ generics] Moving forward with the generics design draft

> But I don't think that using type list constraint as sum types is good idea. > Type constraints should be known in compile-time, but the sum type variant should be known in run-time. It looks like you misunderstand it a bit. Indeed type Constraint interface { type Type₁, Type₂, …, Typeₙ

Re: [go-nuts] rin: return if nil syntactic sugar

> I am using flutter and so Dart for the frontend right now, and I have come to a Error context has a little value in the end user apps, I noticed this too at the example of just CLI utilities. It is totally different when it comes to modern network systems, because there're far more places of

Re: [go-nuts] [ generics] Moving forward with the generics design draft

> possibility of using angle brackets Please stop - call these operator signs “brackets” - pretending they are good in a role of brackets — they are not - spreading this nonsense from C syntax family of languages to saner once — yes, you heard it right. C is known for its chaotic

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

I probably didn't read what you have wrote in the first message carefuly enough. Does it mean something like that will work type SomeTypes interface { type int, float32, float64 } func Min[T SomeTypes](x, y T) T { switch T { case int: if x < y {

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

You may use something like this *value2 := *(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer()) + 8))* *if value2 == 0 {* *return true* *}* on AMD64, should work also for any 64 bit architecture (at least I believe so). Remember though this is hacky and

Re: [go-nuts] [ generics] Moving forward with the generics design draft

BTW, I am really glad your proposal is accepted, now the whole thing feels polished and IMO it is time to start building an implementation. пятница, 21 августа 2020 г. в 20:02:17 UTC+3, Carla Pfaff: > On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote: > >> All constraints

Re: [go-nuts] Re: Why we don't have simple throws error statement

eturn err > } > > fmt.Println("result:", x + y + z) > > return nil > } > > How is sound? > > Semih. > On Sunday, 2 August 2020 at 11:44:43 UTC+3 Denis Cheremisov wrote: > >> There are two major issues with Go error hand

Re: [go-nuts] Generics and parentheses

> Have the authors considered the implications of requiring the `type` keyword to use a generic type, not just at declaration time? Would this open up more syntax possibilities, such as `var x T`? This might be easier to read at the expense of five more characters of typing. It also could

Re: [go-nuts] A few thoughts on type parameters

> I think "[type T]" is slightly clearer than "[T any]". Code with `[T any]` is much easier to read at least for me. среда, 5 августа 2020 г. в 11:07:59 UTC+3, Jan Mercl: > On Tue, Aug 4, 2020 at 6:07 AM 'Carla Pfaff' via golang-nuts > wrote: > > > On Tuesday, 4 August 2020 at 00:34:12 UTC+2

Re: [go-nuts] Re: Why we don't have simple throws error statement

There are two major issues with Go error handling: 1. It is not strict enough, i.e. the compiler cannot ensure error check 2. It is not consistent enough. In the first you can easily ignore an error and the compiler will let you go further. In the second, you can both *if err :=

[go-nuts] Re: Thoughts on the try proposal (and Generics)

> Most functions are called more than once in a program, so adding > context to the implementation itself would benefit every caller: they don't > need to add the context themselves. This is highly questionable assumption. Context outside is obviously superior: - Your assumption just does

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

I actually mean something different. The bad with *any* in builtins is there will be questions "why you use interface{}" if there's builtin *any?*", etc. I mean these will be different AST nodes, there will be *type GenericAny struct {* *Name *ast.Lit* *}* and *type Generic struct {* *

[go-nuts] Re: How can I fork a module that uses /internal ?

As soon as I understand you can just keep their module name in `go.mod` and that's it. воскресенье, 26 июля 2020 г. в 03:46:15 UTC+3, brad.be...@gmail.com: > Hi folks. I was unable to find a good answer online already. The closest > I found was >

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

Btw, it `any` suffix can be a part of grammar, I mean something like *GenericParam = Lit [',' Lit]* 'any' | Lit [',' Lit]* Ident* where *any* can be replaced with an actual *any* if there's one in a scope. воскресенье, 26 июля 2020 г. в 00:47:17 UTC+3, Denis Cheremisov: > Great catch! I wo

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

Great catch! I would say I really like it! суббота, 25 июля 2020 г. в 23:37:39 UTC+3, Carla Pfaff: > I know it's common to have no constraints, but "[Elem any]" is even one > character shorter than "[type Elem]". I rewrote the function signatures > from slices.go2 in this way, and it doesn't

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

I look at what Carla did write and it feels ... good. I don't know, it may be not for everyone, but for me [T any] looks cleaner than [type T]. Probably I see `[` and understand this is generic params, then `T` and I immediately understand this is how the generic type denoted. A final touch, I

Re: [go-nuts] Generics and parentheses

Lesser and greater signs never were a good choice. They were chosen because of C syntax restrictions. Go creators would do *slice[T]* (or may be just *[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind. Because, if you have managed not to notice it, Go barely inherited anything from

Re: [go-nuts] Re: Generics and parentheses

func XGenericFunction(x X) … пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak: > On Thu, 2020-07-16 at 13:44 -0700, jpap wrote: > > Notwithstanding a concise unambiguous alternative, I would rather > > type parameters "stick out" so they are easily identified when > > visually scanning

Re: [go-nuts] Generics and parentheses

The big argument I always found less and greater signs to be not visually distinctive enough, at least with fonts I am using. [ and ] are larger and I was really happy with them in Scala although I dislike the language in general. Seriously though, the real big argument is [] are already used

[go-nuts] Re: Generics and parentheses

Great! Those multiple parenthesis were a beat on unredable side indeed, and I always was in the pro-square party as I always found less and greater signs to be unreadable. As much as I disliked Scala in general I liked their generic syntax. This is a really good news Go will have the same.

Re: [go-nuts] My small app executes within 400μs but the exit happens in about 0.16s

0,001s sys 0m0,009s воскресенье, 5 июля 2020 г., 3:45:34 UTC+3 пользователь Kurtis Rader написал: > > On Sat, Jul 4, 2020 at 5:24 PM Denis Cheremisov > wrote: > >> I have a small app like >> >> func main() { >> start := time.Now() >> … >>

[go-nuts] My small app executes within 400μs but the exit happens in about 0.16s

Hi! I have a small app like func main() { start := time.Now() … fmt.Println(time.Since(start)) } where output is ≈400μs but the actual time is about 0.16s, I mean $ time app-name real 0m0,156s user 0m0,238s sys 0m0,054s Profiling collects nothing (it is expected with ≈400μs

Re: [go-nuts] Generic syntax suggestions

PS Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this > is a true valid reason: I didn't mean they are inconsistent. They just don't look consistent at the first glance. суббота, 20 июня 2020 г., 19:06:14 UTC+3 пользователь Denis Cheremisov написал: > &g

Re: [go-nuts] Generic syntax suggestions

I like it. Poor VSCode users will suffer from the current approach and all these ((() – this thing can't even highlight types of function parameters. Your variant is a lot (I mean a LOT) more readable Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this is a true

Re: [go-nuts] [generics] bring contracts back

you should write them all. - interface flood. There's a possibility to use them as an variable/paremeter/return value type although they are only needed for a generic contract. пятница, 19 июня 2020 г., 0:07:45 UTC+3 пользователь Denis Cheremisov написал: > > &

Re: [go-nuts] [generics] bring contracts back

ня 2020 г., 1:11:22 UTC+3 пользователь Ian Lance Taylor написал: > > On Wed, Jun 17, 2020 at 9:58 AM Denis Cheremisov > > wrote: > > > > IMO a groups of constraints are horrible with interfaces > > > > type CommonResponse(type E) interface { > >

Re: [go-nuts] [generics] why struct fields-based constraints were banned?

It would be much less troublesome if you would keep using contracts instead of this interface insanity. четверг, 18 июня 2020 г., 3:18:05 UTC+3 пользователь Ian Lance Taylor написал: > > On Wed, Jun 17, 2020 at 10:05 AM Denis Cheremisov > > wrote: > > > > I ca

[go-nuts] Re: [generics] Replace () with <> or other character

Not all languages use <> for parametric parametrism. I tried lots of variants and my favorite is [] from Scala (I don't like Scala, BTW). четверг, 18 июня 2020 г., 11:15:16 UTC+3 пользователь Nathanael Curin написал: > > An argument for this is also that (all ?) languages that use generics use

[go-nuts] Re: [generics] (again). Type inference is somewhat weak

, service.MethodRequest, service.MethodResponse)(ctx, client.Method, { … }) instead of simple to read resp, err := proto.ReadOne(ctx, client.Method, { … }) среда, 17 июня 2020 г., 19:43:35 UTC+3 пользователь Denis Cheremisov написал: > > https://go2goplay.golang.org/p/ObL79

[go-nuts] Re: [generics] gRPC bistream quantization

Thank you -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit

[go-nuts] [generics] gRPC bistream quantization

Another question about generics, a HOWTODO one: I am bored to death writing methods what would send one request and get one response from a gRPC bistream. Decided to try a draft 2 against a generic approach to the task. My final attempt which I still can't compile:

[go-nuts] Re: [generics] bring contracts back

oops, an infitie loop in the As implementation, now the right one: https://go2goplay.golang.org/p/5NnZBnmIC96 среда, 17 июня 2020 г., 21:55:52 UTC+3 пользователь Denis Cheremisov написал: > > There's an advantage though, for rather narrow cases though: reuse of > interfaces:

[go-nuts] Re: [generics] bring contracts back

There's an advantage though, for rather narrow cases though: reuse of interfaces: https://go2goplay.golang.org/p/HJr3QIzgQuX среда, 17 июня 2020 г., 19:58:08 UTC+3 пользователь Denis Cheremisov написал: > > IMO a groups of constraints are horrible with interfaces > > type CommonRes

[go-nuts] [generics] why struct fields-based constraints were banned?

I can't get why struct based constraints were banned. struct is a kind of types in Go and a wish to only allow them having some field is valid. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] [generics] bring contracts back

IMO a groups of constraints are horrible with interfaces type CommonResponse(type E) interface { GetError() E } type CommonError interface { GetCode() int32 } func IsOK(type R CommonResponse(E), E CommonError)(r R) bool { switch r.GetError().GetCode() { case 0, 200, 201:

[go-nuts] Re: [generics]Use "<>" to declare template would be better than "()"

Better for who? You? I would to love to see `[]` instead of `()`, but `<>` are horrible to read IMO. среда, 17 июня 2020 г., 19:36:09 UTC+3 пользователь hao luo написал: > > The creator: > > Hi, I am extremely interested in and eager for golang's generics, and I > have read the updated draft.

[go-nuts] Re: [generics] Replace () with <> or other character

> > makes it easier to visual parse > Are you sure? It may be a personal thing, but "visual parsing" of these <<< really annoys me, I would prefer `[]`, but I like `()` more than `<>`. In addition, a good IDE (not that well known overhyped editor on steroids) will highlight these fragments, so

[go-nuts] [generics] (again). Type inference is somewhat weak

https://go2goplay.golang.org/p/ObL79WVHDjw Need to write types explicitly although all the info needed is easily accessible: fmt.Println(IsOK(*commonResponse, *commonError)(r)) What I am sure is I will keep using a code generator instead of this monstrosity. -- You received this message

Re: [go-nuts] Need advice on AST formatting

hanks to all of you for your time. > > Le ven. 18 oct. 2019 à 00:11, Denis Cheremisov > a écrit : > >> Hi! >> >> I have a utility that parses Go files into AST , makes some changes on >> the tree (import paths) and format it back into the Go source code, in

[go-nuts] Need advice on AST formatting

Hi! I have a utility that parses Go files into AST , makes some changes on the tree (import paths) and format it back into the Go source code, in the original file. The problem is I am using format.Node function from this package. The formatting this

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

nk that it will become more readable than explicit error handling >> quite fast. Note that it is still explicit, if you don't use the try >> notation the error can be handled as it is now or ignored as it sometimes >> is now. >> >> I have a feeling that there

[go-nuts] Proposal: try function constructor

Pooof Are you serious? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit

[go-nuts] The "leave "if err != nil" alone?" anti-proposal

And prepare for wider audience in shitty “try” proposal after 1 July. -- 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+unsubscr...@googlegroups.com.

[go-nuts] The "leave "if err != nil" alone?" anti-proposal

The “try” proposal is unpopular: 246 dislikes vs 186 likes. And aforementioned one is highly popular with more than a thousand likes and the like/dislike ration is reaching 8 (actual numbers are 1147 likes vs 148 dislikes). And you must understand the specific: you are solving relatively hard

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

> - also enable normal go program to use awk scripts probably this is better tool for the case суббота, 24 ноября 2018 г., 5:43:22 UTC+3 пользователь Tong Sun написал: > > > > On Saturday, November 17, 2018 at 12:44:57 PM UTC-5, Ben Hoyt wrote: >> >> >>

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

oops, gave link to a dup, here's a right one: https://github.com/golang/go/issues/27380 четверг, 30 августа 2018 г., 22:06:36 UTC+3 пользователь Denis Cheremisov написал: > > Filled a new issue: https://github.com/golang/go/issues/27381 > Please let me know if a title is too weird, I

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

aven't dug in > further. > > —Sam > > On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote: > > strange, still the same > > > > $ go get -x -u golang.org/x/tools/cmd/goimports > > go: cannot find main module; see 'go help modules' > > >

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

: > > > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote: > > Hi! > With Go 1.10 and earlier one can install binaries via regular `go get`, `go > get golang.org/x/tools/cmd/goimports` for instance. > It doesn't work with Go modules enabled: > > $ go get golang.org/x/to

[go-nuts] How to deal with binaries compilation with go modules enabled?

Hi! With Go 1.10 and earlier one can install binaries via regular `go get`, `go get golang.org/x/tools/cmd/goimports` for instance. It doesn't work with Go modules enabled: $ go get golang.org/x/tools/cmd/goimports go: cannot find main module; see 'go help modules' this is an obvious usability

[go-nuts] Re: [go/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

;Implementation2 implements Interface", types.Implements(impl2, iface)) } Введите код... The problem though ASTs are not cached. I copied implementation of importer from go/internal/srcimporter and extended it with caching (I need ASTs besides *type.Package for style checks) суббота, 5 мая 201

[go-nuts] Re: [go/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

I meant true-false is not expected behaviour, true-true is what I would love to see. -- 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

[go-nuts] [go/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

Hi! I am writing a special linting-like piece of code and struggle dealing with the Implements that doesn't work for my configuration. I made a simplified testing example to show the issue: - I have package speaker with interface Speaker and

[go-nuts] [dep] is it planned to integrate `go get` and future `go dep`?

Hi! I struggled a couple of days ago with an issue caused by the fact the *go get* is not aware of dependencies defined by the current *dep*, which I am using for the development purposes. *dep* sticked to fixed https://github.com/antlr/antlr4 version (latest, v4.7 released in march 2017),