l0k1 l0k18

Parametric Polymorphism in Go idiom

For some reason, there does not exist a super simple example of how this is done in Golang, but it's completely doable, and gets you all the benefits of abstract parent types which you want to operate on multiple types of data, such as for example a binary tree. All the functions to navigate and add and remove nodes can be generalised and only a small subset of functions must be written to handle the specific data type.

First, the interface stuff:

package parametric

// Data - the type here doesn't really matter, but you can't use interface{} and then create a function for it

Unjumbling Golang OOP primitives

I am in the process of writing a binary search tree implementation and in order to minimise maintenance problems, I needed to use parametric polymorphism - so I could specify part of the algorithm concretely, where it is in common regardless of the data type in a subclass, and which parts were not in common.

The issue that I came across and I only just finally understood how to do this type of code in Go yesterday, so this is fresh and an issue that I want to raise regarding the Golang 2.0 specification.

Currently, this is how you do OOP in go:

type Objectname struct {

I think that most of the issues related to error handling would be fixed by turning error setting, can be changed by rewriting the error interface, and I have started towards doing this in my current project. However, my solution does sacrifice the ability to use symbolic operators, though possibly I can resolve this with suitable methods that return builtin types.

The essence of the solution is using structs and interfaces that embed a 'status' type that lets you set, get and nil the error string, and defining interfaces that allow you to chain method calls by returning the same type, usually the same struct.

As I read back, I also realise that it could become implicit that a method without a specified return implicitly always returns the receiver. It would be simple to gofix code, kinda backwards, to insert the implied return type and return statement. The same can be said about most of the suggestions I have made in this document, at least that I feel strongly about. Most of them are subtle tweaks to

Change directory to the root of an executable (main package), and then:

go install ./cmd/... 2>&1 >/dev/null | grep cannot|cut -d'"' -f2|uniq|sort|xargs -n1 gvt fetch

et voila! :D

Macros, not version bumps

An analysis and proposal for dealing with the gotchas in Go 1 other than a breaking change in grammar and syntax

by Loki Verloren, 16-04-2019, Novi Sad, Serbia

Abstract

Between Microkernel and Bare Metal

There is something more or less like an onion-skin model that can be used to describe the differences between different types of operating systems and in particular their kernels.

To describe it, you have to start from the core. This is just the general categories that have a dominent representation in practical use:

Bare metal

This is the level at which some (most) embedded systems exist. All of the resources are controlled by the main thread of the root process. This is the level with maximum performance and maximum burden upon the programmer to prevent resource deadlocks and mitigate contention.

Using functions in Go declarations

The best way to approach the limitations of Go's type system in regards to the function signature and closures, is to simply use variables. This also gives you something you can set to nil to become a typed nil, which is quite nasty syntax also.

var DefaultHandler = func(s string) error {
  return nil
}

What is Distributed Journal?

The semantic difference between journal and ledger is a very simple one - it starts with many snippets, and over time the tail becomes the final version that contains everything essential from the many little parts that compose it.

The correspondence of 'many small parts' to this protocol, there is a race to pin the network maximum confirmations to each recently passed transactions.

Interval Tree Clocks

Interval Tree Clocks are a system whereby special set-based splitting and joining operations that can determine the time-ordering of many sparsely connected events. There is an implementation for Java, C and Erlang, that has been forked here and will be ported to Go when the next phase of the roadmap begins:

Keybase proof

I hereby claim:

I am l0k18 on github.
I am l0k18 (https://keybase.io/l0k18) on keybase.
I have a public key ASBMfRcCdFf0zt1WFy1gpqzUtTyqcdH0roPT1yQbeJd7Cwo

To claim this, I am signing this object:

	package main

	import (
	"log"
	"net"
	"time"
	)

	type nodeCfg struct {
	Listener string