l0k18

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.

l0k18

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

l0k18

package main

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

type nodeCfg struct {
	Listener   string

l0k18

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

l0k18

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

l0k18

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 {

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

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

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

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:

```go
package parametric

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