Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

On Wed, Dec 30, 2020 at 4:07 AM Amnon wrote: > > How do you know, if you don't check? FTR, it's not just about sending > garbage, it's also about requests accidentally being truncated or just > generally garbled. > > json.NewDecoder(r.Body).Decode(&payload) will return an error if the request >

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

On Tue, Dec 29, 2020 at 9:50 PM Axel Wagner wrote: > > There is an important semantic difference between the two, which means you > almost never want to use a `Decoder`: `Unmarshal` is for parsing a single > json document, whereas a `Decoder` is for parsing a stream of concatenated > documents,

[go-nuts] Re: Generics, please go away!

Of course generics will make everything harder. We learn harder, we read harder, we think harder, we write harder. I use C++ for more than 10 years. I know the harder. Whether or not experience is improving, life is harder and the language is rotten. On Wednesday, December 30, 2020 at 4:27:45 A

Re: [go-nuts] A new solution of type list in generic.

You are right. The implicit type conversion will bring confusion. I give up. But I still think the type list is not a good idea. I'd rather not support operators than use type list. On Tuesday, December 29, 2020 at 1:51:13 PM UTC+8 Ian Lance Taylor wrote: > On Mon, Dec 28, 2020 at 5:14 PM redsto

[go-nuts] Re: Generics, please go away!

Please, stop being so condescending to newcomers and non-professional developers. Generics as uses by end-users will improve their experience, not make it harder. (And what is this obsession with "classes"? Go has them - structs with methods are classes). On Tuesday, December 29, 2020 at 1:32:

[go-nuts] Re: The GitHub Vet Project

I'd like to solicit some input from the community regarding a decision that could reduce the effort required in crowdsourcing. After thinking carefully about the loopclosure vet check , it seems to me that a

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

On Tue, Dec 29, 2020 at 6:07 PM Amnon wrote: > *How do you know, if you don't check? FTR, it's not just about sending > garbage, it's also about requests accidentally being truncated or just > generally garbled.* > > json.NewDecoder(r.Body).Decode(&payload) will return an error if the > request i

Re: [go-nuts] Runtime cost of type assertions

On Tue, Dec 29, 2020 at 6:01 PM Arnaud Delobelle wrote: > > > On Tuesday, 29 December 2020 at 16:25:41 UTC axel.wa...@googlemail.com > wrote: > >> On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle >> wrote: >> >>> Question 1: I *think* that the compiler has all the information >>> necessary to im

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

*How do you know, if you don't check? FTR, it's not just about sending garbage, it's also about requests accidentally being truncated or just generally garbled.* json.NewDecoder(r.Body).Decode(&payload) will return an error if the request is garbled or truncated. The other nice thing about thi

Re: [go-nuts] Runtime cost of type assertions

On Tuesday, 29 December 2020 at 16:25:41 UTC axel.wa...@googlemail.com wrote: > On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle wrote: > >> Question 1: I *think* that the compiler has all the information necessary >> to implement type assertion to the Cont interface as I have, i.e. it knows

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

On Tue, Dec 29, 2020 at 5:17 PM Amnon wrote: > I always use `json.NewDecoder(r.Body).Decode(&payload)` > You shouldn't. The code is more succinct than reading the entire body into a buffer, and > then unmarshalling it. And there is only one error to check. > There is only one error to check, b

Re: [go-nuts] Runtime cost of type assertions

On Tuesday, 29 December 2020 at 16:25:41 UTC axel.wa...@googlemail.com wrote: > On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle wrote: > >> Question 1: I *think* that the compiler has all the information necessary >> to implement type assertion to the Cont interface as I have, i.e. it knows

Re: [go-nuts] Runtime cost of type assertions

On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle wrote: > Question 1: I *think* that the compiler has all the information necessary > to implement type assertion to the Cont interface as I have, i.e. it knows > only 3 types implement that interface, so could it not do the optimisation > on my beh

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

I always use `json.NewDecoder(r.Body).Decode(&payload)` The code is more succinct than reading the entire body into a buffer, and then unmarshalling it. And there is only one error to check. If I was super concerned about people sending trailing gibberish to my server, I could call `dec.Buffere

Re: [go-nuts] Re: Generics, please go away!

On Tue, Dec 29, 2020 at 5:01 PM L Godioleskky wrote: > Hopefully the GO leadership will isolate Generics to a module so that those > who dont wish to use them can quietly ignore them, while those that believe > Generics have value can just import the relevant module(s) It's a language change,

[go-nuts] Re: Generics, please go away!

Hopefully the GO leadership will isolate Generics to a module so that those who dont wish to use them can quietly ignore them, while those that believe Generics have value can just import the relevant module(s) On Tuesday, December 29, 2020 at 4:32:30 AM UTC-5 rickti...@googlemail.com wrote: >

[go-nuts] Runtime cost of type assertions

Hi there! Looking at performance bottlenecks for my implementation of Lua in Go ([1]), I found that type assertions can have a significant cost, which feels unnecessary to me. I couldn't explain it without quite a lot of context, which makes my post quite long - sorry about that! I have a Val

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

There is an important semantic difference between the two, which means you almost never want to use a `Decoder`: `Unmarshal` is for parsing a single json document, whereas a `Decoder` is for parsing a stream of concatenated documents, like so: https://play.golang.org/p/4uiNyJlNIKh. In particular, t

Re: [go-nuts] json.NewDecoder()/Decode() versus Unmarshal() for single large JSON objects

On Tue, Dec 29, 2020 at 11:35 AM burak serdar wrote: > > On Mon, Dec 28, 2020 at 5:22 PM Amit Saha wrote: > > > > Hi all, let's say I am a single large JSON object that I want to > > process in my HTTP server backend. > > > > I am trying to get my head around if there is any performance > > advan

[go-nuts] Re: Generics, please go away!

My point of view is that Generics should not become part of the Go standard library. I appreciate there are use cases where it is very helpful to have, but I do not believe that adds value to Go. The real value for Go is it's simplicity, avoidance of generics and avoidance of classes. This makes