I've had quite a bit of experience in this area.
Briefly: for language interop, the easiest thing to do is to use the
for JSON and msgpack that Go libraries already provides.
For writing to disk, write one of these in parallel alongside your binary
data. For transmitting over the wire, use
the builtin JSON or 3rd party libraries (e.g. ugorji/go/codec or
tinylib/msgp) to translate from your Go structs on the fly.
More in depth thoughts:
From investigation of flatbuffers last month:
The current state is that the Go bindings for FlatBuffers are buggy and
it wasn't possible to produce equivalent binary output to the C++ reference
with the Go bindings.
The design of FlatBuffers is also, to my mind, poorly thought out: it is
there are severe limitations on the amount of data you can express;
you are limited to 64KB + 1 longer array. The
documentation is very incomplete; there is no precise spec, rather just a
paragraphs of vague casual description that do not match hex dumps
of the reference implementation output. As a result the format is currently
under-documented that I cannot recommend it.
Summary of flatbuffers investigation: I would like to see the Go bindings
but the originators need to put in better documentation of the format
before that is even possible.
disclaimer: I maintain the first version of the Go bindings for Capnproto.
For capnroto, on the plus side:
+ The serialization design/IDL for Capnproto is generally excellent. Very
expressive and well designed type system and solid evolve-able story.
- But since you talk about having arrays of structs, be aware the in
you will have no ability to version such structs; such structs are always
stored in-line in the array. Hence the advantages
of using an evolve-able data format are lost. This begs the question
of why go to the trouble in the first place.
- Support for languages beyond C++, python, and Go is unlikely to be
completed in the next year.
For most new projects I've moved to the simple Msgpack
and using either https://github.com/tinylib/msgp
with the need for easy json interop being forefront in my mind.
Between those two libraries you have alot of speed tuning options (either
fully dynamic (ugorgi), or fully pre-compiled deserialization (tinylib).
The caveats with Msgpack are poor handling of signed vs unsigned
numbers; the lack standard ways to express time.Time and other
language specific types, and the fact that although they tried to
fix the flaws of version1 with version2, nobody really implemented
version2 fully. Also the evolution of data story is not as bullet-proof;
actual interop with other languages may be particularly
painful because of that. That said, for an all-Go project,
using tinylib/msgp in particular makes serialization so fast and
easy (add a "go generate" one-line directive to your file) that it is my
default solution. You get quite a bit of ability to evolve your
data, as long as you never re-use an old field name and give
it a different type. It is somewhat more risky, but as long
as you only care about version N to version N+1 evolve-abilty,
you should be fine.
Stepping back, big picture: Protobufs with GoGoProtobuf
certainly has the most mature tooling and support of any of these.
If you don't want to pay bleeding edge "early adopter" taxes,
and you require a binary format, this is your choice.
On Tuesday, January 26, 2016 at 5:29:41 AM UTC-8, Daniele Baroncelli wrote:
The type system in GoMobile is still very limited, as it's currently not
possibly to work with slices of struct:https://godoc.org/golang.org/x/mobile/cmd/gobind#hdr-Type_restrictions
In the meantime, developers are starting to release mobile apps with
GoMobile and they all have to deal with the same problem: the lack of
slices of struct. Each developer has been coming with its own solution.
Someone tried with wrappers (https://github.com/scisci/go-mobile-collection),
but the most convincing
solution so far seems to be Flatbuffers. A few developers have already used
Flatbuffers have official implementations in Go and Java. And there is
already an open source package for Swift:https://github.com/mzaks/FlatBuffersSwift
I have talked to Robert Winslow, one of the guys behind Flatbuffers, if it
made sense to implement Flatbuffers for GoMobile and he seems to agree and
he is willing to help.
I am opening this thread, so that discussions can start.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.