my gists, just random but connected thoughts relating to things involving programming and distributed systems.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

whatcouldgo.md 2.4KB

Things that could be removed from Go

  1. if/switch, merge into one conditional/block pattern

  2. interface method sets - Handy, sorta, for arbitrarily struct laden application data structures that deal in bytes or some other uniform intermediate formatted data. But no, really.

How to remove interfaces? Build an xml-type structured container with attributes and children, instead of interfaces you can pin a type (and its’ store) into a tree structure, with base features of get/set/validate/copy.

Essentially, interfaces are just a type of set structure anyway. The container is by its nature a set, though some applications have temporal or spatial directions, these are implemented by sorters, which can order iterations as well.

We still need the interface{} type, and type switches, but this construction pattern is less rigid. Interfaces really should be spared and it is why also Go idiom recommends small, narrow purpose interfaces.

Using closures and func() variables and structs you can specify method sets and easily override them, chain them, or construct them from structured (tree shaped, but not full blown grammar).

This construction motif used in Go as it is currently has some downfalls. There could easily be a simple builtin set of basic func() types, no return, one in of a builtin type, one out of a builtin, and one in and one out of built-in types. Some more short-hand way to express the concept of a context within the copy-only optimistic conflict resolution models that next generation distributed systems require.

Go is interesting to me due to the fact it is targeted exactly at relatively small, low feature, high throughput low latency complex server network topologies.

The only substantive changes I am interested in are primarily ergonomic. Go as it is today has some features that require excessive amounts of typing. The composite construction method using closures greatly simplified building more complex application components, and so I am convinced that Go could be optimised towards this type of programming, cut out at least as much things as it adds.

I don’t think Go needs built-in generics, I think it needs a built-in container, and some kind of a scheme for how the namespaces contain all the metadata and runtime. With containers you can isolate and encapsulate the implementation and focus it on the hardware requirements and reduce strain of structural limitations.