Re: [go-nuts] Generics - please provide real life problems

Hi, I apologize but I must disagree. Those *are* real life examples. At least they're extracted from these. Especially the 'chans' package (the set of generic functions that apply to any 'chan T') or the 'mapreduce' one. You can't discard those away from the back of your hand. -s Sent from Pr

Re: [go-nuts] Generics - please provide real life problems

Those are simple examples of real world problems. I've been writing Go since the very beginning, having worked at Google when it was released and since I enjoy the language so much, I try to write all the backend server code in Go that I can. In these years, I've had to write many code generators t

Re: [go-nuts] Generics - please provide real life problems

While the example of ReverseSlice doesn't appear in my work experience, the concept of writing functions for slices independent of type is pretty common for me. Not having to copy to/from []someInterface or having to write (or go generate) multiple versions of the code differing only on the type w

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

On 23-12-2020, Kaveh Shahbazian wrote: > --=_Part_8328_927921797.1608758069173 > Content-Type: multipart/alternative; > boundary="=_Part_8329_1642814539.1608758069173" > > --=_Part_8329_1642814539.1608758069173 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encodi

Re:[go-nuts] Generics - please provide real life problems

Oh, I almost forgot, it also clearly does not "have minimal impact on everybody else", which is another proposal selection criteria. Go code becomes much more complex to read and understand from all the examples I have seen. You can even find several YouTube videos with people trying to analyze

Re:[go-nuts] Generics - please provide real life problems

I write this from my understanding of the "Proposal selection criteria", which clearly states, that in order for a proposal to be accepted, it has to "address an important issue for many people". This is why I'm asking for real life problem examples, not theoretical ones. I do not believe that

Re:[go-nuts] Generics - please provide real life problems

I'm sorry, but this is not real life problems. This is exactly the problem with this proposal. It's based on nothing but small theoretical examples. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receivin

Re: [go-nuts] Generics - please provide real life problems

On Wed, Dec 23, 2020 at 10:15 PM Martin Hanson wrote: > > I have been arguing passionately against adding generics to Go because > I truly believe that it is going against the simplicity of Go and the > philosophy behind the design of Go. > > I believe that the resilience of Go against unnecessary

[go-nuts] Generics - please provide real life problems

I have been arguing passionately against adding generics to Go because I truly believe that it is going against the simplicity of Go and the philosophy behind the design of Go. I believe that the resilience of Go against unnecessary change is of vital importance. The experience provided by Ken Tho

Re: [go-nuts] multicasting with encoding/gob

In games most code is shared between server and client so normally they're built on the same language, and even in the same framework. Sometimes you need to share load with the client to increase the amount of players. So I'm not too worried about inter-language interoperability. I'm not sure havi

Re: [go-nuts] Looking for a Go-Lang Developer

On Wed, Dec 23, 2020 at 9:13 PM Matt Harden wrote: > > Since Go version 1.0 was not released until March 2012, you might find it > hard to find people with 10 years of experience with it. There are dozens of us! DOZENS! Ian > On Wed, Dec 23, 2020 at 1:07 PM Kavya S wrote: >> >> Hi Everyone,

Re: [go-nuts] multicasting with encoding/gob

Exposing the bytes would hurt the abstraction. Game servers usually only process data in certain intervals (say 20 times per second), that means i would either need to expose the net.Conn for reading, or creating a buffer for each connection and acumulate the data on memory, so that each time the s

Re: [go-nuts] Looking for a Go-Lang Developer

Since Go version 1.0 was not released until March 2012, you might find it hard to find people with 10 years of experience with it. On Wed, Dec 23, 2020 at 1:07 PM Kavya S wrote: > Hi Everyone, > > Happy Holidays! > > Urgent requirement for a GO Language Developer with 7-10 years of > experience

[go-nuts] [ANN] Pion WebRTC v3.0.0 Released

Pion WebRTC is a Go implementation of WebRTC. If you haven't used it before check out awesome-pion[0] or example-webrtc-applications[1] for what people are doing. We maintain a feature list and other helpful resources in our README.md[2] I am so excited to finally post this! This release was a l

Re: [go-nuts] multicasting with encoding/gob

I looked at your top level README.md to understand what you are doing. Do these players join at the same time or different times? If different times, that can explain corruption with MultiWriter. One suggestion is to use "bufio" to create a writer for the gob encoder out of a []byte buffer. Then

Re: [go-nuts] multicasting with encoding/gob

That’s good to know. I figured after 20+ years of learnings with Java serialization that a somewhat modern version would have the ability to reset the stream. This is required for large dynamic object models. Very surprising. > On Dec 23, 2020, at 6:56 PM, 'Axel Wagner' via golang-nuts > wrot

Re: [go-nuts] multicasting with encoding/gob

On Thu, Dec 24, 2020 at 1:08 AM Artur Vianna wrote: > Before using gob was using encoding.BinaryMarshaler, but that would mean > the user of the api would need to implement a MarshalBinary for every type, > which is kind of cumbersome. > > An option might be to let the user choose gob, BinaryMar

Re: [go-nuts] multicasting with encoding/gob

On Thu, Dec 24, 2020 at 1:46 AM Robert Engels wrote: > I was referring to the comments about the encoder keeping state. You can > reset the encoder. You may need your own framing to do so - I’m not looking > at the gob streaming encoder docs - but if it is a decent streaming encoder > it should h

Re: [go-nuts] multicasting with encoding/gob

I was referring to the comments about the encoder keeping state. You can reset the encoder. You may need your own framing to do so - I’m not looking at the gob streaming encoder docs - but if it is a decent streaming encoder it should have a reset mechanism. That being said it is probably easi

Re: [go-nuts] multicasting with encoding/gob

I'm confused to which part of the thread you're referring to On Wed, 23 Dec 2020, 21:30 Robert Engels, wrote: > That is not true. Java serialization works similarly. You can hook it do > that you send the metadata once during connect, and then encode the data.so > no a new connection only needs

Re: [go-nuts] multicasting with encoding/gob

That is not true. Java serialization works similarly. You can hook it do that you send the metadata once during connect, and then encode the data.so no a new connection only needs the metadata and can decode further stream messages. You may need framing resets to simplify things and reduce the o

Re: [go-nuts] multicasting with encoding/gob

Before using gob was using encoding.BinaryMarshaler, but that would mean the user of the api would need to implement a MarshalBinary for every type, which is kind of cumbersome. An option might be to let the user choose gob, BinaryMarshaler or Json etc to best fit the use case, but that takes the

Re: [go-nuts] multicasting with encoding/gob

No, it wouldn't. Because the encoder keeps state about which type-information it already sent and wouldn't sent it again - causing the client to be unable to decode. So you'd also need a new encoder on the server. And at that point, you're back to the status quo, with one encoder per client and the

Re: [go-nuts] multicasting with encoding/gob

There are ways to control the framing but in my experience a pseudo multicast scenario is best implemented with a proprietary protocol. You can do this easily on top of other transports Luke grpc/protobufs. > On Dec 23, 2020, at 5:20 PM, Matthew Zimmerman wrote: > >  > If you would "reset"

Re: [go-nuts] multicasting with encoding/gob

If you would "reset" each client with a new decoder each time you make a new encoder, everything should work fine. Just would take some coordination. On Wed, Dec 23, 2020, 6:08 PM Artur Vianna wrote: > I will look into other protocols, although for now the performance is not > an issue in serve

Re: [go-nuts] multicasting with encoding/gob

I will look into other protocols, although for now the performance is not an issue in servers with less than 100 players. The problem with io.MultiWriter is that a player inside the group may disconnect or a new player may come in. This means a new io.MultiWriter must be created each time you disp

Re: [go-nuts] multicasting with encoding/gob

Dnia 2020-12-23, o godz. 13:45:10 meera napisał(a): I'd use flatbuffers. https://google.github.io/flatbuffers/flatbuffers_guide_use_go.html It is possible to extract gob encoded bytes and copy it over multiple receivers but it would be an overkill, likely. -- Wojciech S. Czarnecki << ^oo^

Re: [go-nuts] multicasting with encoding/gob

The issue with that approach is that gob keeps state about which type-information it still has to send. So if you encode to, say, a bytes.Buffer, it would encode all type-info on every message sent, which is a significant overhead. TBH, I don't understand why `io.MultiWriter` wouldn't work. It woul

Re: [go-nuts] multicasting with encoding/gob

Yes, that is why you need to create your own protocol. Use the gob to encode to a buffer then send the buffer on each of the connections using your protocol. > On Dec 23, 2020, at 4:19 PM, Matthew Zimmerman wrote: > >  > My understanding is that gob streams are unique. > > From https://gola

Re: [go-nuts] multicasting with encoding/gob

My understanding is that gob streams are unique. >From https://golang.org/pkg/encoding/gob/ "A stream of gobs is self-describing. Each data item in the stream is preceded by a specification of its type, expressed in terms of a small set of predefined types." In my own rudimentary understanding/te

Re: [go-nuts] multicasting with encoding/gob

If i create a bytes.Buffer and a gob.Encoder, each time i write to a group of connections i get "duplicate type received" and if i try and reuse the encoder, i get "corrupted data" and "unknown type". It seems i can't use both net.Conn.Write and gob.Encoder.Encode in the same connection, i will try

Re: [go-nuts] multicasting with encoding/gob

You need to encode once to a byte array then send the byte array on each connection. > On Dec 23, 2020, at 3:45 PM, meera wrote: > >  > I am trying to create a package for game servers using gob. The current > approach is an application level multicasting over TCP, having a gob encoder > an

[go-nuts] Re: multicasting with encoding/gob

Sorry, accidentally broke the links. The code for the dispatcher is here: https://github.com/kazhmir/gna/blob/master/dispatcher.go#L81 And the issue is here: https://github.com/kazhmir/gna/issues/1 Em quarta-feira, 23 de dezembro de 2020 às 19:45:10 UTC-2, meera escreveu: > I am trying to creat

[go-nuts] multicasting with encoding/gob

I am trying to create a package for game servers using gob. The current approach is an application level multicasting over TCP, having a gob encoder and decoder for each player connection, and set up a goroutine to receive and another to dispatch for each one. The code for the dispatcher is her

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

Axel provided good insights about the history and the big picture of generics. Since the beginning, not having generics was not a goal - or a promise. >From Computer Science - Brian Kernighan on successful language design : "Perl's time has passed because

[go-nuts] Looking for a Go-Lang Developer

Hi Everyone, Happy Holidays! Urgent requirement for a GO Language Developer with 7-10 years of experience for Philadelphia, PA. Please share profiles if interested along with contact details. Please send it over to kav...@biz3tech.com and CC urm...@biz3tech.com Regards, Kavya S Biz3TECH Corp

Re: [go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

Why will interfaces be more idiomatic once generics lands? It remains to be seen I guess but I could very well see the other way become the idiom. On Wed, 23 Dec 2020, 21:20 wilk, wrote: > On 23-12-2020, Ian Lance Taylor wrote: > > On Wed, Dec 23, 2020 at 9:54 AM wilk wrote: > >> > >> https://g

[go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

On 23-12-2020, Ian Lance Taylor wrote: > On Wed, Dec 23, 2020 at 9:54 AM wilk wrote: >> >> https://go2goplay.golang.org/p/fTW3hJYNgfU >> >> type Stringer interface { >>String() string >> } >> >> Print[T Stringer](s []T) >> >> Print(s []Stringer) >> >> Both forms works. >> How to prevent double

Re: [go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

to illustrate what Ian wrote, with your example: https://go2goplay.golang.org/p/YTqF-WS0m6O func main() { var ps = []*Person{ &Person{"Arthur Dent", 42}, &Person{"Zaphod Beeblebrox", 9001}, } Print(ps) // ok. Printi(ps) // compilati

Re: [go-nuts] `go list` across multiple modules?

Hi Paul! On Wed, Dec 23, 2020 at 4:23 AM Paul Jolly wrote: > > > I just can't figure out how to do this. Maybe it can't be done in `go > > list` ? Or maybe we're just missing some detail of go modules.. > > go list operates in the context of a single module (in the mode you > are interested in)

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

I meant success, as in ‘developer acceptance/enthusiasm’, not necessarily commercial success. > On Dec 23, 2020, at 9:48 AM, Space A. wrote: > > Prime driver of Java's success were enterprises with huge amount of > investments (money) into ecosystem along with all JSRs developed by companies

Re: [go-nuts] Performance issue with os.File.Write

On Tue, Dec 22, 2020 at 11:21 AM komuW wrote: > The bufio package also uses a max buffer of 64KB: > https://go.googlesource.com/go/+/go1.15.6/src/bufio/scan.go#80 > That limit is for bufio.Scanner. It doesn't have anything to do with bufio.Reader and bufio.Writer, which don't have any particular

Re: [go-nuts] [generics] use of new predeclared name `any`

Although "any" is a new predefined identifier, I still find that conceptually simpler than assigning a second meaning to "_". On Wed, Dec 23, 2020 at 9:27 AM Ian Lance Taylor wrote: > On Wed, Dec 23, 2020 at 9:03 AM LeoY wrote: > > > > Following the blog post about generics in Go, I want to joi

Re: [go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

On Wed, Dec 23, 2020 at 9:54 AM wilk wrote: > > https://go2goplay.golang.org/p/fTW3hJYNgfU > > type Stringer interface { >String() string > } > > Print[T Stringer](s []T) > > Print(s []Stringer) > > Both forms works. > How to prevent double way to do the same things that can be confusing ? Bo

[go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

Hi, https://go2goplay.golang.org/p/fTW3hJYNgfU type Stringer interface { String() string } Print[T Stringer](s []T) Print(s []Stringer) Both forms works. How to prevent double way to do the same things that can be confusing ? -- wilk -- You received this message because you are subscri

Re: [go-nuts] [generics] use of new predeclared name `any`

On Wed, Dec 23, 2020 at 9:03 AM LeoY wrote: > > Following the blog post about generics in Go, I want to join Ian about his > claim to "Minimize new concepts". > Would it be possible to allow a syntax that just omits a type constraint in > the generic function definition instead of using any ? T

[go-nuts] [generics] use of new predeclared name `any`

Hi, Following the blog post about generics in Go, I want to join Ian about his claim to "Minimize new concepts". Would it be possible to allow a syntax that just omits a type constraint in the generic function definition instead of using any ? Then the followi

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

On 22-12-2020, Ian Lance Taylor wrote: > On Tue, Dec 22, 2020 at 2:09 PM Martin Hanson > wrote: >> >> @Ian, if you're succumbing to outside pressure, please don't. >> >> If you on the other hand is pro-generics to Go, then of course that is >> your right. >> >> I for one doesn't hope that the futur

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

> Personally, though, I must say that the generics discussion has been going on for 10 years (and even more, if we don't limit ourselves to Go) and I don't - personally - believe that there is much hidden cost or surprising benefit left to be discovered. There is nothing hidden and nothing ne

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

Prime driver of Java's success were enterprises with huge amount of investments (money) into ecosystem along with all JSRs developed by companies and groups with J2EE becoming de-facto a standard for building enterprise applications. And all this was happening way before any generics. среда, 23

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

On 23-12-2020, Jeremy French wrote: > I'd like to second the notion that the argument "if you don't like them,=20 > don't use them," is an invalid argument. Anyone who's been in the game for= > any length of time knows that more than we'd like, we're repairing someone= > else's code, as opposed

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

On 22-12-2020, Ian Lance Taylor wrote: > On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom > wrote: >> >> Why not issue a poll on generics, was this ever done? (I could've missed it, >> I am only following Go ~2 years). While the community has a vote in >> accepting/rejecting the current generics

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

To add some weight to the pro generic side - from someone who doesn’t necessarily think Go needs them - generics and more specifically the “Java Collections” package was a prime driver in Java’s success. Moving highly tuned and verified implementations into the core library removed a huge burden

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

On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson wrote: > @Ian, for more than 10 years we have managed nicely without generics. > Of course, this doesn't answer how we'd have managed *with* them. We did manage for decades without general purpose CPUs. We did manage for several decades without func

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

On Wed, Dec 23, 2020, 6:17 AM Martin Hanson wrote: > > After generics gets added, it's going to be something else next time, and > again and again. The list goes on and on about changes people want to > make to Go. Not real life problems, just so-called "nice to have". > > No, the added and incre

Re: [go-nuts] `go list` across multiple modules?

> I just can't figure out how to do this. Maybe it can't be done in `go > list` ? Or maybe we're just missing some detail of go modules.. go list operates in the context of a single module (in the mode you are interested in), so you cannot do this with a single command across multiple modules.

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

On 12/23/20 11:19 AM, Axel Wagner wrote: > I have to call it out here though as I see statistic abuse on the news > every > day. Not to mention that asking the question encourages people to think of > something. > > Ignoring that encouragement in the question (and not remembering

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

@Alex Besogonov: > Can you provide concrete examples of code that would become more > complicated and/or slower with the addition of generics? I'm > genuinely researching it. I'm not the one wanting to change the language, it's the other way around. You have to provide concrete examples of why Go

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

I didn't take part in few of the last surveys. However I filled that very last one and haven't seen any generics-related questions. It was also stated somewhere that some of them randomized? So I answered a lot of weird questions for anything, but language features. Anyways if Go is not poll-dr

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

On Tue, Dec 22, 2020 at 9:48 PM Ian Lance Taylor wrote: > On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom > wrote: > > > > Why not issue a poll on generics, was this ever done? (I could've missed > it, I am only following Go ~2 years). While the community has a vote in > accepting/rejecting the

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

On Wed, Dec 23, 2020 at 11:42 AM Kevin Chadwick wrote: > I have to call it out here though as I see statistic abuse on the news > every > day. Not to mention that asking the question encourages people to think of > something. > > Ignoring that encouragement in the question (and not remembering su

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

On 12/23/20 8:06 AM, Alex Besogonov wrote: > In general, Go managed to tread a very fine line between "overcomplicated > nonsense" and "stupidly verbose" pretty well. So I suggest trusting the > language > maintainers. They are doing a great job! I wholeheartedly agree with this and thank you for

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

On Sunday, December 20, 2020 at 11:38:54 AM UTC-8 Martin Hanson wrote: > I think people who want generics added to Go should go and program in Java > or C++. > Perhaps you should switch to Python if you don't want generics? > Adding generics to Go will ruin the beautiful simplicity of the la