simplebuffer

For simple applications it makes no sense to have complicated things added to them. This library aims to solve two problems in one: A binary encoding with a decoder that avoids copying and not using reflect but not making new data types difficult to add or new messages to string together. Something fast but simple and easy to extend and recompose.

Using a slice of a specific serializer type, with an interface that does the usual things required of a serializer, mainly, to produce a serialized representation of its contents, can be strung together in an arbitrary order and do not run until you generate the message container, and when received do not incur processing cost until the value is actually accessed, which can help ensure failure conditions are more rapidly responded to - only as many fields are needed to determine such a condition are required to be decoded in order to respond appropriately, whereas a standard serialization codec will decode everything anyway before you even see it.

This library is inspired by Flatbuffers, but its terrible support of Go and the use of complicated tools and syntaxes and generators, when I already understand interfaces and slices and before there is a version 1 it is easy to just ad-hoc write new types. The design is such that also when you use it, each interface implementation is a unit of compilation, and not any of the implementations present that you haven't imported.

In most cases, there is already a fast binary encoding scheme for almost any given data type implemented by servers already existing, usually fast, this allows also the arbitrary change of the content of messages for specific purposes without a performance hit from reflection. It is up to the user of the library to take care of message versioning and the simplest way would be to centralise the definitions of the magics. The encoders can be made zero-copy at the option of the implementor, the performance cost of copying is still less than reflection anyway, but the option is open for the future.

This is not really so much of a library as a pattern of construction with modular importable boilerplate. The goal is maximum performance especially latency in tasks that may not require complete decoding to determine a response.

For example, in the Bitses implementation, it has an array of packed binary encoded 32 bit integers. It unpacks them into a map when you run the Decode method, but doesn't generate the int32 value, and subslicing usually will not copy the bytes, only create a new slice reference. There is also a header containing a service advertisment for the controller , it can be decoded with only knowing this part of the message at all, and its component parts also subslice to the returned values so they are basically zero copy, probably the conversion to int32 could be an unsafe type conversion, or generate the string representation without intermediate int32 representation.

Go is a language that encourages creative repurposing of its syntax to many other things than what was intended, and the use of closures, first class functions and parser/generators stringing these calls enables metaprogramming , yet without imposing complicated new syntax or feeling excessively clunky (once you get over the func :) )