Let’s have some fun with some numbers.

In the serialization in go article , we discussed a number of types of encoding formats and their libraries in go.

And let me answer …

The encoding/json library bundled with the standard library is a GREAT piece of software.

go-codec supports compile-time generation of encoders and decoders for named types, which does not incur the overhead of reflection in the typical case, giving 40% to 100% performance improvement over the idiomatic runtime introspection mode.

Idiomatic encoding and decoding types within go typically relies on the reflection capabilities of the go runtime. This affords flexible performance without the need for a pre-compilation step; the go types contain all the information needed and the runtime exposes the full types via reflection. However, introspecting the runtime to get this information has a noticeable overhead, which can be eliminated by a pre-compilation/code-generation step.

go-codec is a high performance and feature rich library that provides idiomatic encoding and decoding support for msgpack, binc, cbor, json and simple formats. It supports both runtime introspection (reflection) and code generation. Below, we will walk you through using it for your serialization needs.

Supported formats:

They say premature optimization is the root of all evil. I say some layers of the stack MUST be optimal. The layer that does marshalling of data MUST be optimal.

go-codec library supports code generation OR runtime reflection for its encoding and decoding. We will mostly discuss the runtime reflection in this article. It is easiest to compare this to other libraries.

Glad you asked. cbor stands for: Concise Binary Object Representation .

cbor is a relatively new binary format which builds upon the simplicity of messagepack and json. It is currently being targeted agressively in the internet-of-things space. It is a kick-ass format.

The go-codec library is a High Performance , Feature-Rich and Idiomatic Go encoding/decoding library for binc , msgpack , cbor , json , with runtime reflection or compile-time code generation support. View Source at http://github.com/ugorji/go .

Sometime in 2013, we announced go-codec as a library for msgpack. The go-codec library has come a long way since then.

For data transfer between systems to occur, the sending side must encode the data structures into a stream of bytes, and the receiving side must efficiently decode the stream of bytes into a representative data structure.

There is efficient and extensive support for this when using go as your language runtime. The standard library provides support for the following general-purpose encodings:

We describe enhancements to the Binc data interchange format since its public release.

Also, the Binc spec is now stored on github ( https://github.com/ugorji/binc ). This allows us track revisions and affords better collaboration.

Go codec is a High Performance and Feature-Rich Idiomatic Go Library providing encode/decode support for different serialization formats, including msgpack and binc . Get it while it’s hot at https://github.com/ugorji/go/tree/master/codec#readme

Binc is a lightweight, compact, limitless, schema-free, precise, binary, high-performance, feature-rich, language-independent, multi-domain, extensible, data interchange format for structured data.

See the format documented at http://www.ugorji.net/project/binc

Announcing go-msgpack, a rich msgpack codec for Go. Supports encoding/decoding to msgpack binary format, and use for net/rpc communication.

https://github.com/ugorji/go-msgpack http://gopkgdoc.appspot.com/pkg/github.com/ugorji/go-msgpack

With App Engine, the Go Runtime is a mashup of Python Runtime, Go SDK and glue code (Go and Python). This poses some challenges during development, which this proposal addresses with solutions.

Development Tool for go app engine development, that presents an easier to use wrapper for App Engine development with GO Runtime, bypassing some pitfalls caused by integration with the Python SDK.

The source is available online, and the motivation for building this is described below. What irks one person may not irk the other, so your utility of this tool may differ from mine. For me, the utility is really high:

With changes to allow concurrent requests in Go App Engine, Testing support follows naturally and natively.

Following support for concurrent requests described previously, Testing support is as easy as ensuring the following is called one time before your test is run. I have tested it and it works flawlessly.

This details how to enable concurrent requests in the Go App Engine SDK.

This attempts to make a case for datastore enhancements in the GO Language Runtime of App Engine.

Quoting from http://code.google.com/appengine/:

This attempts to objectively address areas where the new App Engine pricing may not not fair, and what Google may do to alleviate these concerns.

Disclaimer I am an unabashed fan of Google App Engine, and have been for over three years. I don’t think there’s anything else on the market that comes close. I think it is a fine platform for any applications, from simpler small ones to large complex ones.

Google has done a major disservice to its cult of developers by changing the pricing terms of App Engine ridiculously while giving developers short notice to react. In doing so, Google may have done severe damage to their brand and the trust that developers put in them.

Google released app engine in 2008 on a set of premises: