kilabit.info
Simple | Small | Stable | Secure

Go: things that I learned writing dsv

This is my notes on learning Go language while developing dsv [1]. My background is C/C++ with a little Java.

Range is fast

The question is this: does accessing slice using element is slower than using index? Discussion on Golangbridge forum [2].

What do I mean by accessing by element is this,

slice := []int{0,1,2,3,4,5,6,7,8,9}

for k,v := range slice {
...
}

v is an value of slice. While accessing by index, is like an usual array access slice[i].

Logically (if you are new and not Go main developer) when accessing slice using range, a copy of slice element is passed to temporary variable v, subsequently assuming that a copy process will take some operations in the background. While accessing by index is just take the address at index i.

Turn out, I was false.

Here is the benchmark file, and here is the output,

BenchmarkSumByIndex10000-8         50000             29073 ns/op           81922 B/op          1 allocs/op
BenchmarkSumByElm10000-8           50000             28527 ns/op           81921 B/op          1 allocs/op
BenchmarkSumByIndex1000000-8        1000           2077027 ns/op         8003657 B/op          8 allocs/op
BenchmarkSumByElm1000000-8          1000           2005368 ns/op         8003659 B/op          8 allocs/op

Accessing slice element with range is little bit faster than accessing by index.

Range is mutable

This is a rookie mistake.

When using range on slice of struct, each element passed on range is mutable. Here is the Go playground.

Do not embed struct if you want other to extend it

Or how to write generic in Go.

Coming from strong object oriented background, the way on how generic works in Go give me a lot of rewriting on dsv package.

Use case: You have struct reader and struct data to save content that the reader read from file, but you want another user to use their implementation, through data interface, to be used in your reader.

Wrong way to do this is by embeding data in reader

type Data struct {
	v int
}

type Reader struct {
	Data
}

because you think that user can access methods in Data through reader easily.

Right way to do this is using interface separating the job between reader and the data,

type DataInterface interface {
	// methods operate with data
}

type Data struct {
	// fields of data
}

type Reader struct {
	data interface{}
}

func NewReader(mydata interface{}) *Reader {
	if mydata == nil {
		mydata := &Data{
			// Set default data value.
		}
	}

	return &Reader{
		data: mydata
  	}
}

func (reader *Reader) Data() interface{} {
	return reader.data
}

So, when you need the data in the reader use the DataInterface,

func (reader *Reader) Read() {
	di := reader.GetData().(DataInterface)
}

Interface should only contain methods that operate with fields

Given an generic object Car with two fields: model and max-speed, the methods that should included in CarInterface should only methods that operate on the fields (e.g. initialization, getter, setter, etc).

type Car struct {
	model string
	maxSpeed int
}

type CarInterface interface {
	Init()
	Model() string
	SetModel(string)
	MaxSpeed() int
	SetMaxSpeed(int)
}

Everything else (features for car) should be written using parameter with CarInterface,

func MoveSlowly(ci CarInterface) {
	// make the car move slowly.
}

Why? I will leave it to the reader to answer it.

Slice is struct

Most of the time, it does not matter wether you want to pass slice to function by references or values, both will change the content of slice. But …​ if you have quite big number of element in slice, passing by pointer will make it faster.