DEV Community: Rahul sawra

Harnessing the Power of Generics in Go: A Comprehensive Guide - Part I

Rahul sawra — Sun, 30 Jul 2023 10:36:01 +0000

Introduction

Go,has gained significant popularity for its simplicity, efficiency, and concurrency features. However, one critical feature that has been missing for a long time was generics. Generic programming enables developers to write code that can work with different data types, making code more flexible, reusable, and less error-prone. With the introduction of generics in Go 1.18, the language has taken a giant leap forward, empowering developers to tackle complex problems with greater elegance and efficiency. In this blog post, we'll dive into the world of generics in Go and explore how this new feature revolutionizes the way we write code.

The Need for Generics

Before the introduction of generics in Go, developers had to rely on interfaces or write type-specific code to handle various data types. While interfaces allowed some level of abstraction, they often introduced performance overhead and forced developers to compromise on type safety. Additionally, code duplication was common when dealing with multiple data types, leading to maintainability challenges.

Generics address these limitations by enabling the creation of functions, data structures, and algorithms that work with any type while maintaining strict type safety. This means developers can write code once and apply it to multiple data types, resulting in cleaner, more maintainable, and efficient programs.

Type Parameters and Type Constraints

At the core of generics are type parameters, which are placeholders for specific types used within a generic function or data structure.
Functions and types are now permitted to have type parameters. A type parameter list looks like an ordinary parameter list, except that it uses square brackets instead of parentheses.

To show how this works, let’s start with the basic non-generic Min function for floating point values:

func Min(x, y float64) float64 {
    if x < y {
        return x
    }
    return y
}

The above function Min() only works for floating type values. In order to calculate Min() of integers you need to write a seperate function (or use interfaces).

We can make this function generic–make it work for different types–by adding a type parameter list. In this example we add a type parameter list with a single type parameter T, and replace the uses of float64 with T.

import "golang.org/x/exp/constraints"

func GMin[T constraints.Ordered](x, y T) T {
    if x < y {
        return x
    }
    return y
}

It is now possible to call this function with a type argument by writing a call like

x := GMin[int](2, 3)
y := GMin[float64](2.1, 3.1)

Type constraints play a crucial role in ensuring type safety while using generics. By specifying constraints, developers limit the types that can be used with a generic function, preventing misuse and providing better error messages during compilation.

In the generic GMin implementation, the type constraint is obtained from the constraints package.
constraints.Ordered is a type constraint.

Specifically, the Ordered constraint is responsible for defining the set of types whose values can be ordered, i.e., compared using operators such as <, <=, >, etc. This constraint guarantees that only types with comparable values can be used in GMin.

It's important to note that in Go, type constraints are required to be implemented as interfaces.

We look at the interfaces in a new way now.
Until recently, the Go spec said that an interface defines a method set, which is roughly the set of methods enumerated in the interface. Any type that implements all those methods implements that interface.

You can now define type set in a interface. For instance, interface{ int|string|bool } defines the type set containing the types int, string, and bool.

Another way of saying this is that this interface is satisfied by only int, string, or bool.
Now let’s look at the actual definition of constraints.Ordered:

type Ordered interface {
    Integer|Float|~string
}

This declaration says that the Ordered interface is the set of all integer, floating-point, and string types. The vertical bar expresses a union of types. Integer and Float are interface types that are similarly defined in the constraints package. Note that there are no methods defined by the Ordered interface.

Now let's look at a simple example where a func SumIntsOrFloats is a generic function that sums the values of map m. It supports value of both types int64 and float64.

package main

import (
    "fmt" 
)

// SumIntsOrFloats sums the values of map m. It supports both int64 and float64
// as types for map values.
// K avd V are type params
// comparable = type constraint (built in)
// Number = type constraint
type Number interface {
    int64 | float64
}

func SumIntsOrFloats[K comparable, V Number](m map[K]V) V {
    var s V
    for _, v := range m {
        s += v
    }
    return s
}

func main() {
    // Initialize a map for the integer values
    ints := map[string]int64{
        "first":  34,
        "second": 12,
    }

    // Initialize a map for the float values
    floats := map[string]float64{
        "first":  35.98,
        "second": 26.99,
    }
    fmt.Printf("Generic Sums: %v and %v\n",
    SumIntsOrFloats(ints),
    SumIntsOrFloats(floats))
}

go run main.go 
Generic Sums: 46 and 62.97

Well, that's all about generics in this blog. We will dive deep into generics in coming blogs and look at more use cases.

Reach out to me, if you want to discuss anything about GO! :D
Twitter - https://twitter.com/im_rsawra
LinkedIn - https://www.linkedin.com/in/rahul-sawra/

Ref:

Strategy Design Pattern in Go

Rahul sawra — Wed, 16 Feb 2022 13:17:40 +0000

According to Wikipedia,

The strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use

The strategy design pattern comes under the behavioural pattern.
Strategy design pattern turns a set of behaviors(strategies) into objects and makes them interchangable inside original context object.
We create objects which represent various strategies and a context object(original object),which holds a reference to a strategy object and delegates it executing the behaviour.
In order to change the context object perform its work, other objects may replace the currently linked strategy object with another one.

Example

Suppose we are building an in-memory cache.Since, the size of an im-memory cache is limited, whenever it reaches its maximum size alloted, some enteries have to be removed in order to free up the space. This task can happen via several algorithms:

First In , First Out (FIFO) - remove an entry from in memory cache , that was created first.
Least Recently Used (LRU) - remove an entry from in memory cache, that has been used least recently
Least Frequently Used (LFU) - remove an entry from in memory cache, that has been used least frequently

The main idea is to decouple the cache object/class from these algorithms (strategies) so that we can change the algorithm at runtime.

Also, the original cache class should not change when a new algorithm is being added in the future.

This is where Strategy Pattern comes into play. It basically suggests to create the family of algorithms and each algorithm having its own class. Each of these classes implement the same interface and this way the algorithm becomes interchangable within the family.

Lets say the common interface name is evictionAlgo
evictionAlgo.go: Strategy Interface

fifo.go: Strategy

lru.go: Strategy

lfu.go: Strategy

cache.go: Context

Here as you can see , the original context object(cache) holds a reference to a strategy interface(evictionAlgo).

main.go: Client Code

Output:

Evicting by lfu strtegy
Evicting by lru strtegy
Evicting by fifo strtegy

Taints and Tolerations in Kubernetes

Rahul sawra — Tue, 24 Aug 2021 06:42:24 +0000

In this blogpost, we'll learn about Taints and Tolerations in Kubernetes.

Taints
Taints are the property of nodes , that is used to repel the pods if they don't tolerate this taint.
Taints can be applied on the nodes just like labels.
This means that only those pods that are tolerant to the taints , will be scheduled on that node.

To apply a taint on a node:

kubectl taint nodes <node_name> key1=value1:taint_effect

places the taint on node.The taint has key=key1,value=value1 and a taint_effect

taint_effect can take 3 different values:

NoSchedule: If this effect is applied to the node , then the pods that are tolerant to all the taints applied on the node, are only scheduled on this node.
PreferNoSchedule: In this case, the system will try to avoid placing a pod that does not tolerate the taint on the node, but it is not required.
NoExecute: In this case, the new pods that do not match the taint are not scheduled on the node and existing pods on the node will also be evicted if they do not tolerate all the taints.

Tolerations
Tolerations are applied on the pods,that allow the pods to schedule on the nodes with matching taints.

We apply the toleration for a Pod in PodSpec.

tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"

By Default the value of operator is Equal
A toleration "matches" a taint if the keys are the same and the effects are the same, and:

the operator is Exists (in which case no value should be specified), or
the operator is Equal and the values are equal.

Let us take an example
Suppose we have two worker nodes node01 and node02
We apply the taints to nodes as follows:

kubectl taint nodes node01 key1=value1:NoSchedule
kubectl taint nodes node02 key2=value2:NoExecute

And then we apply toleration to a pod as:

apiVersion: v1
kind: Pod
metadata:
    name: nginx-pod
spec:
    containers:
       - image: nginx
         name: nginx-container
    tolerations:
        - key: "key1"
          operator: "Equals"
          value: "value1"
          effect: "NoSchedule"

In this case the pod will be scheduled on node01 since it has the toleration to its taint.

Ever wondered why the pods are not scheduled on master(controlplane) nodes?
Because it has a taint node-role.kubernetes.io/master=true:NoSchedule
which prevents pods from being scheduled unless otherwise untainted the master node.
Using Taints and Tolerations , we can create nodes that are reserved(dedicated) for specific pods.

Ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/