Eric Myhre warpfork

the "Keep Your Serialization Simple" format

Kyss -- "Keep Your Serialization Simple" is a serialization format designed for simplicity, unambiguity, and a pleasant experience for human reading and writing.

Kyss was designed with these criteria in mind:

Maps, arrays, strings, ints: all the basics should be unsurprising.

The RFC RFC

There are many kinds of useful artifacts outside of code. This is a discussion of several kinds of docs, how we want to develop them, and how we like to merge and manage them.

Kinds of documents

Experience Reports

Warpfork's Guide to Structuring Large Go Programs

Table of Contents:

Package Layout
Coding styles
Helpful Libraries

Naming is a fundamentally opinionated operation. The exact mechanism and intensity of opinion may vary by application, but opinionated it certainly is. Opinions require curation. Curation implies either distributed reputation networks (which frankly, I don't think are Possible) or some degree of centralization. QED, it follows that decentralization (as opposed to distributed) is in fact the best we can do.

We can push that a little farther with a tiny bit of separation: it's the assignment of names that's opinionated, and thus requires curation, and thus confined to being decentralized at best. We can still of course make lookup of names completely distributed. And that's pretty good!

Let's talk about some user-stories that come to my mind right now (spoiler, for almost all of them, decentralized&&!distributed is either acceptable or outright desired):

package managers: if you talk to these people for any amount of time, naming curation is actually the number one problem. Your reputation

Codegen output and value construction in Golang

Preface: there are many (many (MANY)) different ways to do codegen. The effects are far-reaching, so they need to be considered carefully; and the cost to support variations is also sky-high, so please be judicious in suggesting "flags" and options.

This is some exploration of the ways we can do builders and constructors for values in the golang code.

IPLD one-pager

// this is a work in progress summarization doc.

// see github.com/ipld/specs for more complete reference!

In the IPLD project, we're interested in defining a universally compatible data model. With this, we separate serialization from structure.

	package main

	// the command you are looking for is probably: git update-server-info

	import (
	"fmt"
	"os"
	"net/http"
	)

	package serialization

	import (
	"testing"
	"time"

	"github.com/polydawn/refmt/cbor"
	"github.com/polydawn/refmt/obj/atlas"
	)

	package main

	/*
	This is all explicitly designed to be compatible with BurntSushi's sumtype checker:
	https://github.com/BurntSushi/go-sumtype

	Concretely, that means we 1) generate an interface and 2) use the unexported method
	trick to make it 'sealed'.

	All enum values get their own (empty) struct type.

	so where we're at right now is:

	IPFS is clearly the right primitives for a bunch of stuff.
	(E.g., content-addressing is just... clearly the way to go, for all sorts of stuff. Everybody knows that, at this point.
	Contentious a few years ago; but approaching "duh" as we come into 2020.)

	When we started making IPFS, "Step One" was get it to ship files... worldwide, peer-to-peer.
	We did that. It does that. It's pretty cool.

	We also did that without a particularly clear focus on performance, etc. Step One was "make it work!"