Golang

TL;DR In this blog post, we will see how new golang iterators1 enables us to write efficient code. Although, we talk about iterators in golang, same argument holds for other languages as well2. Traditional Approach Consider a hypothetical example of writing powerset function to generate all possible subsets: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // We are using slice instead of set func PowerSet[T any](values []T) [][]T { if len(values) == 0 { return nil } results := make([][]T, 0) for i := 0; i < int(math.Pow(2, float64(len(values)))); i++ { result := make([]T, 0) for j := 0; j < len(values); j++ { if i&(1<<j) != 0 { result = append(result, values[j]) } } results = append(results, result) } return results } What is going on here: ...

Couple of years ago, one of my friends wanted me to look at golang. Back then, golang was a shiny language and there was a lot of hype around it. I briefly look at the language and I had two primary concerns back then: Lack of generics: No longer exists now as generics were added in go 1.181. Better ergonomic error handling: This problem even exists at the time of writing. Most of the times I see a common pattern mentioned below: // common pattern result, err := fetch_value() if err != nil { return nil, err } ​ I wish there was a way2 in which I can return an error if I don’t want to deal with it. Something along the lines of: ...