Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

4 is a viable fix > (and should of been supported originally). > > On Nov 10, 2021, at 12:59 PM, Andrey T. wrote: > > Fellas, > I would say the 5x throughput difference is a serious problem.Would you be > kind and open an issue on github about it? > Also, the PR that you

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Fellas, I would say the 5x throughput difference is a serious problem.Would you be kind and open an issue on github about it? Also, the PR that you have might benefit from explanation about what you are trying to solve (and probably link to an issue on github), so it would get more attention.

Re: [go-nuts] Idea extending xerror.As

... or, to put a crazy idea out there, we need to ask for extension of switch statement to support (v, err) tuples for a case argument... On Sunday, September 19, 2021 at 3:43:36 PM UTC-6 david@gmail.com wrote: > On Sun, Sep 19, 2021 at 5:19 PM roger peppe wrote: > >> In some ways, the exis

[go-nuts] Re: go 1.17.1 in docker (m1) Segmentation Fault

Hi Remi, You might want to open a bug on https://github.com/golang/go/issues/new and try to check if 1.17 (not 1.17.1) has the same problem - that will reduce the scope of thing to verify for dev team Andrey On Wednesday, September 15, 2021 at 1:05:52 PM UTC-6 remi.p...@gmail.com wrote: > He

[go-nuts] Re: [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

Jan, This is fantastic news! Congratulation on hitting such a milestone! (patiently waiting for the windows and macos) Andrey On Wednesday, August 26, 2020 at 3:52:13 PM UTC-6, Jan Mercl wrote: > > From the change log (https://godoc.org/modernc.org/sqlite#hdr-Changelog) > > 2020-08-26 v1.4.0: >

[go-nuts] Re: [Generics] Simplified syntax to sidestep the bracket arguments

I have tried to propose something like this in https://groups.google.com/forum/#!topic/golang-nuts/W3fSnH0w1G0 (and earlier I was dancing around that idea in https://groups.google.com/forum/#!topic/golang-nuts/Rp3yUUy2nS8 ), but somehow it did not get any serious attention. I still think that

Re: [go-nuts] [generics] cannot use generic type list.Element(type TElem) without instantiation

Ian, continuation question -- does `type intElement list.Element(int)` introduce a new type just like `type myInt int` does? If so, in a previous example, these 2 maps are not of the same type, am I right? Thank you very much, Andrey On Wednesday, July 1, 2020 at 10:50:07 AM UTC-6, Ian Lance

Re: [go-nuts] [generics] Syntax feedback

Tyler, May I humbly suggest https://groups.google.com/d/msg/golang-nuts/W3fSnH0w1G0/JbMkJrKICAAJ for an additional item for your list? Thank you very much, Andrey On Saturday, June 27, 2020 at 11:46:23 AM UTC-6, Tyler Compton wrote: > > Hi Rob, > > This topic has been discussed many times on

[go-nuts] Re: [generics] Use decorators ($, or @, or #) to specify that the type is a generic type.

> > On Thursday, 25 June 2020 06:17:24 UTC+2, Andrey T. wrote: > > >> 3. Ability to use decorated interface name as spec for type constrains >> >>func (type T Comparable) Max(a... T) (result T) {...} >> >>might become >> >>

[go-nuts] [generics] Use decorators ($, or @, or #) to specify that the type is a generic type.

The idea: Use decorators ($, or @, or #) to specify that the type is a generic type. (Syntax is vaguely follows to * "it is a pointer", so $T becomes a "it is a generic type") 1. Readability - Immediately visible which type is a generic type. 2. Readability - Less braces. Compare func (ty