Re: [go-nuts] Question regarding gob
There is certainly no reason why pointer semantic meaning cannot be
supported in encode/decode tools for Go. It does not seem hard to do, but
there was a choice not to do it. I shared my understanding of the reason,
but that's not a suggestion of difficulty or impossibility.
The most natural implementation uses a map in both the encoder and decoder.
The least memory way uses the existing pointer values as the instance ID. A
refinement uses 2x map memory but is more compressible in the wire format.
encoder:
if next item is a pointer{
is pointer NOT in the map of previously sent pointers?
recursively encode/transmit *pointer and use uintptr(pointer) as its
ID.
send "next thing is a pointer to a T; value is whatever you
(reconstructor) generated for ID uintptr(pointer)"
}
decoder:
opposite of this, where the map has IDs sent and pointers to locally
allocated objects.
That is all it takes. More suave is to have the map not just be a
map[uintptr]struct{} but of map[uintptr]uint64, where the ID is a serial
number counting up. This would be invisible to the decoder, but real
addresses sent as IDs will be big numbers in a 64-bit address space and
take more bits to encode than one byte 0..255, two byte 256..65535, ...
On Tue, Mar 26, 2019 at 3:44 PM Robert Engels wrote:
> Yes, when using pointers and cycles you need to either use ids in the
> encoding or break the cycle by dropping the cyclic fields (for example, a
> simple ‘parent’ field causes an infinite cycle so drop it and make it
> implicit)
>
> On Mar 26, 2019, at 2:27 PM, Thomas Bushnell, BSG
> wrote:
>
> I mean, everything except the things that are not pointers.
>
> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels
> wrote:
>
>> This is not really true. In Java everything is a pointer (reference) and
>> has no problem with the semantics of passing a reference, it is built into
>> the serialization. They may be in fact passed as a pointer (local rpc) or
>> passed as a copy of the object graph, or something in between (custom).
>>
>> There is no reason Go can not achieve use the same paradigm.
>>
>> On Mar 26, 2019, at 11:48 AM, Michael Jones
>> wrote:
>>
>> To be clear here as educators, it is important to point out that
>> exporting / persisting / sending a pointer is an awkward concept.
>>
>> The normal meanings of sending data beyond an executing program have no
>> direct use for the pointer’s literal value; “the thing at location 12345 in
>> the memory of a program that ran last year” is not much help.
>>
>> On the other hand, one might imagine pointers being like file names and
>> then recreate both content and references during reading. The export format
>> could persist all the typed, pointed to values in tables, and then for each
>> pointer variable exported send instead advice like “put the address of the
>> 456th element of the table for type C things in this pointer slot.”
>>
>> A persistent format supporting this way of recreating the semantics of
>> pointers is very much like an archive format (Zip) with support for
>> symbolic links. It is not particularly hard to implement, but it is a
>> “heavyweight” approach. My sense is that the common desire in export tools
>> is high speed and byte efficiency so it is natural that Gob and other
>> mechanisms adopt the “pointers don’t make sense for export” argument.
>>
>> Michael
>>
>> On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote:
>>
>>>
>>>
>>> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote:
>>>
Thanks for the reply, Sameer.
Being able to directly send go types is a really big plus for me, I
wonder if I really want to use gob, are there any recommended rpc choices?
>>>
>>> Note that gob has at least one significant limitation when encoding Go
>>> types - it doesn't know about pointers - in general it encodes a pointer by
>>> omitting a field. So if you want to send a slice of a pointer type where
>>> some elements can be nil, you're out of luck:
>>> https://play.golang.org/p/ThVUT_M0hjR
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com *
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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.
>> For more options, visit
Re: [go-nuts] Question regarding gob
Yes, when using pointers and cycles you need to either use ids in the encoding or break the cycle by dropping the cyclic fields (for example, a simple ‘parent’ field causes an infinite cycle so drop it and make it implicit) > On Mar 26, 2019, at 2:27 PM, Thomas Bushnell, BSG > wrote: > > I mean, everything except the things that are not pointers. > >> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels wrote: >> This is not really true. In Java everything is a pointer (reference) and has >> no problem with the semantics of passing a reference, it is built into the >> serialization. They may be in fact passed as a pointer (local rpc) or passed >> as a copy of the object graph, or something in between (custom). >> >> There is no reason Go can not achieve use the same paradigm. >> >>> On Mar 26, 2019, at 11:48 AM, Michael Jones wrote: >>> >>> To be clear here as educators, it is important to point out that exporting >>> / persisting / sending a pointer is an awkward concept. >>> >>> The normal meanings of sending data beyond an executing program have no >>> direct use for the pointer’s literal value; “the thing at location 12345 in >>> the memory of a program that ran last year” is not much help. >>> >>> On the other hand, one might imagine pointers being like file names and >>> then recreate both content and references during reading. The export format >>> could persist all the typed, pointed to values in tables, and then for each >>> pointer variable exported send instead advice like “put the address of the >>> 456th element of the table for type C things in this pointer slot.” >>> >>> A persistent format supporting this way of recreating the semantics of >>> pointers is very much like an archive format (Zip) with support for >>> symbolic links. It is not particularly hard to implement, but it is a >>> “heavyweight” approach. My sense is that the common desire in export tools >>> is high speed and byte efficiency so it is natural that Gob and other >>> mechanisms adopt the “pointers don’t make sense for export” argument. >>> >>> Michael >>> On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: > Thanks for the reply, Sameer. > > Being able to directly send go types is a really big plus for me, I > wonder if I really want to use gob, are there any recommended rpc choices? Note that gob has at least one significant limitation when encoding Go types - it doesn't know about pointers - in general it encodes a pointer by omitting a field. So if you want to send a slice of a pointer type where some elements can be nil, you're out of luck: https://play.golang.org/p/ThVUT_M0hjR -- 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. For more options, visit https://groups.google.com/d/optout. >>> -- >>> Michael T. Jones >>> michael.jo...@gmail.com >>> -- >>> 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. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
I mean, everything except the things that are not pointers. On Tue, Mar 26, 2019 at 2:45 PM Robert Engels wrote: > This is not really true. In Java everything is a pointer (reference) and > has no problem with the semantics of passing a reference, it is built into > the serialization. They may be in fact passed as a pointer (local rpc) or > passed as a copy of the object graph, or something in between (custom). > > There is no reason Go can not achieve use the same paradigm. > > On Mar 26, 2019, at 11:48 AM, Michael Jones > wrote: > > To be clear here as educators, it is important to point out that exporting > / persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and > then recreate both content and references during reading. The export format > could persist all the typed, pointed to values in tables, and then for each > pointer variable exported send instead advice like “put the address of the > 456th element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for > symbolic links. It is not particularly hard to implement, but it is a > “heavyweight” approach. My sense is that the common desire in export tools > is high speed and byte efficiency so it is natural that Gob and other > mechanisms adopt the “pointers don’t make sense for export” argument. > > Michael > > On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > >> >> >> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >> >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I >>> wonder if I really want to use gob, are there any recommended rpc choices? >>> >> >> Note that gob has at least one significant limitation when encoding Go >> types - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > *Michael T. jonesmichael.jo...@gmail.com * > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
On Tue, Mar 26, 2019 at 12:45 PM Robert Engels wrote: > > This is not really true. In Java everything is a pointer (reference) and has > no problem with the semantics of passing a reference, it is built into the > serialization. They may be in fact passed as a pointer (local rpc) or passed > as a copy of the object graph, or something in between (custom). When you deal with pointers during serialization, you have to deal with the potential of cyclic references. I remember getting frustrated during my Java days with things failing when encoded in JSON where they worked just fine with Java serialization because of cyclic references. This is not a language problem, it is more of an encoding problem. > > There is no reason Go can not achieve use the same paradigm. > > On Mar 26, 2019, at 11:48 AM, Michael Jones wrote: > > To be clear here as educators, it is important to point out that exporting / > persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and then > recreate both content and references during reading. The export format could > persist all the typed, pointed to values in tables, and then for each pointer > variable exported send instead advice like “put the address of the 456th > element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for symbolic > links. It is not particularly hard to implement, but it is a “heavyweight” > approach. My sense is that the common desire in export tools is high speed > and byte efficiency so it is natural that Gob and other mechanisms adopt the > “pointers don’t make sense for export” argument. > > Michael > > On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: >> >> >> >> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >>> >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I wonder >>> if I really want to use gob, are there any recommended rpc choices? >> >> >> Note that gob has at least one significant limitation when encoding Go types >> - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. > > -- > Michael T. Jones > michael.jo...@gmail.com > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
This is not really true. In Java everything is a pointer (reference) and has no problem with the semantics of passing a reference, it is built into the serialization. They may be in fact passed as a pointer (local rpc) or passed as a copy of the object graph, or something in between (custom). There is no reason Go can not achieve use the same paradigm. > On Mar 26, 2019, at 11:48 AM, Michael Jones wrote: > > To be clear here as educators, it is important to point out that exporting / > persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and then > recreate both content and references during reading. The export format could > persist all the typed, pointed to values in tables, and then for each pointer > variable exported send instead advice like “put the address of the 456th > element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for symbolic > links. It is not particularly hard to implement, but it is a “heavyweight” > approach. My sense is that the common desire in export tools is high speed > and byte efficiency so it is natural that Gob and other mechanisms adopt the > “pointers don’t make sense for export” argument. > > Michael > >> On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: >> >> >>> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I wonder >>> if I really want to use gob, are there any recommended rpc choices? >> >> Note that gob has at least one significant limitation when encoding Go types >> - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. > -- > Michael T. Jones > michael.jo...@gmail.com > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
When we think of pointers as what they literally are, an address to a space in memory, it sounds reasonable for Gob to not support them. Things get more unclear when we consider that, in practice, Go programmers often use pointers as a replacement for option types. Without pointers, I don't know how an optional value could be transported using Gob, unless you're willing to add an additional flag to your data structure to indicate if some data is considered present. On Tue, Mar 26, 2019 at 9:48 AM Michael Jones wrote: > To be clear here as educators, it is important to point out that exporting > / persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and > then recreate both content and references during reading. The export format > could persist all the typed, pointed to values in tables, and then for each > pointer variable exported send instead advice like “put the address of the > 456th element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for > symbolic links. It is not particularly hard to implement, but it is a > “heavyweight” approach. My sense is that the common desire in export tools > is high speed and byte efficiency so it is natural that Gob and other > mechanisms adopt the “pointers don’t make sense for export” argument. > > Michael > > On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > >> >> >> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >> >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I >>> wonder if I really want to use gob, are there any recommended rpc choices? >>> >> >> Note that gob has at least one significant limitation when encoding Go >> types - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > *Michael T. jonesmichael.jo...@gmail.com * > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
To be clear here as educators, it is important to point out that exporting / persisting / sending a pointer is an awkward concept. The normal meanings of sending data beyond an executing program have no direct use for the pointer’s literal value; “the thing at location 12345 in the memory of a program that ran last year” is not much help. On the other hand, one might imagine pointers being like file names and then recreate both content and references during reading. The export format could persist all the typed, pointed to values in tables, and then for each pointer variable exported send instead advice like “put the address of the 456th element of the table for type C things in this pointer slot.” A persistent format supporting this way of recreating the semantics of pointers is very much like an archive format (Zip) with support for symbolic links. It is not particularly hard to implement, but it is a “heavyweight” approach. My sense is that the common desire in export tools is high speed and byte efficiency so it is natural that Gob and other mechanisms adopt the “pointers don’t make sense for export” argument. Michael On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > > > On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: > >> Thanks for the reply, Sameer. >> >> Being able to directly send go types is a really big plus for me, I >> wonder if I really want to use gob, are there any recommended rpc choices? >> > > Note that gob has at least one significant limitation when encoding Go > types - it doesn't know about pointers - in general it encodes a pointer by > omitting a field. So if you want to send a slice of a pointer type where > some elements can be nil, you're out of luck: > https://play.golang.org/p/ThVUT_M0hjR > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com * -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: > Thanks for the reply, Sameer. > > Being able to directly send go types is a really big plus for me, I wonder > if I really want to use gob, are there any recommended rpc choices? > Note that gob has at least one significant limitation when encoding Go types - it doesn't know about pointers - in general it encodes a pointer by omitting a field. So if you want to send a slice of a pointer type where some elements can be nil, you're out of luck: https://play.golang.org/p/ThVUT_M0hjR -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
I think the big difference is that gob is most often for Go to Go serialization (at least easily), where as gRPC is cross-platform RPC mechanism using a cross platform serialization (protobufs).-Original Message- From: Sameer Ajmani Sent: Mar 25, 2019 9:53 AM To: Glen Huang Cc: golang-nuts Subject: Re: [go-nuts] Question regarding gob Gob is supported, but I'm not familiar with its current popular use cases. Most often I see people mapping Go types directly to JSON, but using protos with gRPC and other places where the compact encoding helps.On Mon, Mar 25, 2019 at 9:45 AM Glen Huang <hey@gmail.com> wrote:Thanks for the reply, Sameer.Being able to directly send go types is a really big plus for me, I wonder if I really want to use gob, are there any recommended rpc choices?Btw, since grpc + protobuf is the recommended choice right now, does that mean gob is semi deprecated (or at least on hiatus) right now?On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote:With gRPC, I recommend you use protobuf.On Mon, Mar 25, 2019 at 8:18 AM Glen Huang <hey...@gmail.com> wrote:I planed to use net/rpc with gob, but then found the GitHub issue saying net/rpc is deprecated, and people should be using grpc instead.That leads to the question should I use grpc with gob or stick with protobuf? Google suggests not many people talk about using grpc with gob, any there aren't many examples demonstrating how to integrate gob into grpc. I wonder why that's case? Should I use gob or stick with protobuf?Thanks in advance. -- 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
Gob is supported, but I'm not familiar with its current popular use cases. Most often I see people mapping Go types directly to JSON, but using protos with gRPC and other places where the compact encoding helps. On Mon, Mar 25, 2019 at 9:45 AM Glen Huang wrote: > Thanks for the reply, Sameer. > > Being able to directly send go types is a really big plus for me, I wonder > if I really want to use gob, are there any recommended rpc choices? > > Btw, since grpc + protobuf is the recommended choice right now, does that > mean gob is semi deprecated (or at least on hiatus) right now? > > On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote: >> >> With gRPC, I recommend you use protobuf. >> >> On Mon, Mar 25, 2019 at 8:18 AM Glen Huang wrote: >> >>> I planed to use net/rpc with gob, but then found the GitHub issue saying >>> net/rpc is deprecated, and people should be using grpc instead. >>> >>> That leads to the question should I use grpc with gob or stick with >>> protobuf? Google suggests not many people talk about using grpc with gob, >>> any there aren't many examples demonstrating how to integrate gob into >>> grpc. >>> >>> I wonder why that's case? Should I use gob or stick with protobuf? >>> >>> Thanks in advance. >>> >>> -- >>> 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...@googlegroups.com. >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
Thanks for the reply, Sameer. Being able to directly send go types is a really big plus for me, I wonder if I really want to use gob, are there any recommended rpc choices? Btw, since grpc + protobuf is the recommended choice right now, does that mean gob is semi deprecated (or at least on hiatus) right now? On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote: > > With gRPC, I recommend you use protobuf. > > On Mon, Mar 25, 2019 at 8:18 AM Glen Huang > > wrote: > >> I planed to use net/rpc with gob, but then found the GitHub issue saying >> net/rpc is deprecated, and people should be using grpc instead. >> >> That leads to the question should I use grpc with gob or stick with >> protobuf? Google suggests not many people talk about using grpc with gob, >> any there aren't many examples demonstrating how to integrate gob into >> grpc. >> >> I wonder why that's case? Should I use gob or stick with protobuf? >> >> Thanks in advance. >> >> -- >> 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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
With gRPC, I recommend you use protobuf. On Mon, Mar 25, 2019 at 8:18 AM Glen Huang wrote: > I planed to use net/rpc with gob, but then found the GitHub issue saying > net/rpc is deprecated, and people should be using grpc instead. > > That leads to the question should I use grpc with gob or stick with > protobuf? Google suggests not many people talk about using grpc with gob, > any there aren't many examples demonstrating how to integrate gob into > grpc. > > I wonder why that's case? Should I use gob or stick with protobuf? > > Thanks in advance. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Question regarding gob
I planed to use net/rpc with gob, but then found the GitHub issue saying net/rpc is deprecated, and people should be using grpc instead. That leads to the question should I use grpc with gob or stick with protobuf? Google suggests not many people talk about using grpc with gob, any there aren't many examples demonstrating how to integrate gob into grpc. I wonder why that's case? Should I use gob or stick with protobuf? Thanks in advance. -- 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. For more options, visit https://groups.google.com/d/optout.
