Static Typing or Type Inference in Go

2025-04-26T00:00:00+00:00

Overview
Static Typing:</a> </h2> In Go, once a variable is declared with a specific type (e.g., int</code>, string</code>, bool</code>), it cannot be reassigned a value of a different type. Type Inference:</a> </h2> Go's type inference mechanism, using the :=</code> operator, enables you to declare variables without explicitly specifying their type. The compiler infers the type from the value on the right-hand side of the assignment. Example: x := 10</code> infers that x</code> is an int</code>. Benefits of Static Typing:</a> </h2> Early Error Detection: Type errors are caught during compilation, preventing runtime crashes.</li> Improved Code Readability: Explicit type declarations (or inferred types) can make code easier to understand.</li> Compiler Optimization: Knowing the type of variables allows the compiler to perform optimizations.</li> </ul> Benefits of Type Inference:</a> </h2> Conciseness: Reduces verbosity in code by allowing type declarations to be omitted.</li> Improved Readability: In some cases, inferred types can make code easier to read, especially when the type is obvious from the context.</li> </ul> Trade-offs:</a> </h2> Static Typing: Can be more verbose than dynamic typing, requiring explicit type declarations in some cases.</li> Type Inference: Might lead to less explicit code, potentially making it harder to understand the type of a variable at first glance.</li> </ul> Other Differences Between Static Typing: var variableName variableType</code> and Type Inference: :=</code></a> </h1> There are some small differences between the var var :=: Static Typing: var varibaleName variableType</code></th> Type Inference :=</code></th></tr></thead> Can be used inside and outside of functions</td> Can only be used inside functions</td></tr> Variable declaration and value assignment can be done separately</td> Variable declaration and value assignment cannot be done separately (must be done in the same line)</td></tr> </tbody></table> RIP Bram Moolenaar 2023-08-03T00:00:00+00:00 I just came to know that Bram Moolenaar, the creator and BDFL</a> of Vim</a>, passed away today. An email was sent to the vim group mailing list about Bram’s passing. I never met him but I’ve been using Vim since highschool so he’s indirectly been a huge part of my professional and enthuisiast life. I’m sure Vim isn’t going anywhere (hopefully it’s not archived or something), and NeoVim is obviously there if Vim development should cease, and people would move to it since the maintainer has passed away and the project is going in a great direction. Still, this news hits hard for me for some reason. Since I have using Vim since Grade 11 in highschool. Best wishes to Bram’s family and the people who worked with him on Vim. Thanks for the awesome editor, Bram! RIP. Youtube Short Code here: Zoom in Short Code here: Remebering Bram - Creator of Vim Video by the Primeagen</a> Concurrency Abstractions in Go: Queues, Tasks, and Actors 2023-07-11T00:00:00+00:00 Introduction</a> </h1> Concurrency is built-in to the Go programming language and is one of the most powerful features of the language. There are many great resources that explain how concurrency works out of the box in Go. This post will cover a basic overview of how concurrency works in Go and then explore some concurrency abstractions that are common in other languages and how they can be implemented in Go. This post will also cover some basic usage of generics and managing state with closures. Note that one of the characteristics of Go is that it does not rely on as many abstractions as other languages and more direct approaches are common. The patterns presented here are more for learning and exploring with comparisons to other languages rather than for actual use. Error handling is not directly addressed in any of these examples as well. Code for this post can be found at GitHub</a> or GitLab</a>. Go Concurrency Fundamentals</a> </h2> Go has two primary features for handling concurrency: goroutines</code> and channels</code>. Goroutines</a> </h3> A goroutine</code> is a lightweight, virtual process that is managed by a built-in scheduler. Goroutines</code> are lighter weight than threads in other languages and are created by calling the go</code> keyword followed by a function call. For example: func main() { go func() { fmt.Println("Hello, World!") }() } </code></pre> This code snippet will create a new goroutine</code> that will print "Hello, World!" to the console in the background. It is important to note that goroutines</code> on their own do not provide any way to wait for execution to complete or to communicate with other goroutines</code>. This is where channels</code> come in. Channels</a> </h3> A channel in Go is a special data structure that behaves like a queue that can be accessed by multiple goroutines</code>. Items can be either sent into the channel or received from the channel. Channels provide the ability for goroutines</code> to communicate with each other. This allows data to be passed in and out of goroutines</code> and for goroutines</code> to wait for data to be available. They also allow for synchronization of goroutines</code> to ensure that they are executed in a particular order. If the example above was run in an empty program it would not print anything since the main goroutine</code> would exit before the goroutine</code> that prints "Hello, World!" could finish. Channels can be used to wait for the goroutine</code> to finish before exiting the program. // helloworld.go func helloworld() { c := make(chan struct{}) go func() { fmt.Println("Hello, World!") c <- struct{}{} }() <-c } </code></pre> The struct{}</code> type is used here due to its minimal size. Another popular option for a signal channel like this is a bool</code>. In this example the data in the channel does not matter. Instead we are using a special feature of channels that the receive operation will block until data is available. When the empty struct is sent into the channel in the goroutine</code> the receive operation in the main goroutine</code> will unblock and the program will exit having printed the greeting. Channels can also be closed which signals that no more data will be sent into the channel and any blocking receive operation should unblock. In our example here this is not necessary since we are only sending a single item into the channel and only waiting for one item to be received. An additional way to receive data from a channel is to use a for</code> loop and the range</code> keyword. Channels can also be buffered, see this Go by Example post</a> for more details. Work Queues</a> </h2> Channels in Go are basically queues so a work queue concurrency abstraction makes sense in Go. A work queue is a queue of tasks that are executed by a pool of workers. The number of workers should be configurable and typically makes sense to set to the number of CPU cores. An example work queue implementation is shown below. // workers.go type Workers[T any] struct { Work chan func() T Results chan T wg sync.WaitGroup } func New[T any](numWorkers int) Workers[T] { w := &Workers[T]{ Work: make(chan func() T), Results: make(chan T), wg: sync.WaitGroup{}, } for i := 0; i < numWorkers; i++ { w.wg.Add(1) go func() { for f := range w.Work { w.Results <- f() } w.wg.Done() }() } // Close the results channel when the work is done. go func() { w.wg.Wait() close(w.Results) }() return w } </code></pre> In this example we create a Workers</code> struct that has a Work</code> channel for tasks and a Results</code> channel for results. The struct has a generic type parameter to allow a variety of result types. We could allow for input arguments explicitly here but our earlier trick of using closures works here as well since we are using a function as the work item type. The struct also stores a wait group to manage synchronization of the workers so that we can close the results channel when all the work is done. The constructor for this struct accepts a number of workers to create and starts a go routine for each worker that is listening to the work channel to take on work as it comes in. As work is performed the result is sent to the results channel. The following shows how this can be used. w := workers.New[string](2) go func() { for i := 0; i < 10; i++ { i := i w.Work <- func() string { return fmt.Sprintf("%d", i) } } close(w.Work) }() for r := range w.Results { fmt.Println(r) } </code></pre> Note that the Workers</code> struct exposes a basic Work</code> channel that is not buffered. Since the channel will block on send we must send our work items in a separate go routine that will close the channel once all work has been added. If we knew ahead of time how much work we would have we could create a buffered channel of the appropriate size. Tasks</a> </h2> Other languages provide a Task</code> concurrency abstraction that allows for asynchronous execution code with explicit synchronization or "awaiting". Sometimes this behavior is called a promise</code> or future</code>. Basic Task Implementation</a> </h3> The following is an implementation of a Task</code> abstraction in Go based loosely on the .NET Task</code>. // task.go func New(f func()) Task { return &Task{ f: f, awaiter: make(chan struct{}), } } func (t Task) Start() { go func() { t.f() t.awaiter <- struct{}{} }() } func (t Task) Wait() { <-t.awaiter } </code></pre> To use this Task</code> abstraction we can create a new Task</code> and call Start</code> to start the Task</code> in a new goroutine</code>. We then call Wait</code> to wait for the Task</code> to complete. The awaiter channel is used to block the Wait</code> call until the provided function has completed. t := New(func() { fmt.Println("Hello, World!") }) t.Start() t.Wait() </code></pre> This implementation is very simple and does not provide any error handling or cancellation. It also only implements functions that take no arguments and return no values. Task with Input Arguments</a> </h3> If we want to use a function with arguments with our Task</code> we can use a closure to capture the arguments. This example uses a similar function except the greeting</code> to print is set in the outside scope and passed in as a closure. greeting := "Hello from the closure!" t := New(func() { fmt.Println(greeting) }) t.Start() t.Wait() </code></pre> Note that the usual caveats</a> about closures apply here and loop scope variables should be used with care and set as local variables when necessary. In this proposal</a> this might be changing. Task with Output Values</a> </h3> If we want to return a value from the Task</code> we can also use a closure to capture the return value. This example defines a variable in the outside scope and modifies it in the Task</code> function. var greeting string t := New(func() { greeting = "Hello from the closure!" }) t.Start() t.Wait() fmt.Println(greeting) </code></pre> Using closures like this works but it can be hard to determine what the actual inputs and outputs of the Task</code> are. We also need to pay more attention to the scoping of our variables than seems necessary. Refactoring with Generic Helpers</a> </h3> We can update our Task</code> implementation to use some generic helpers to make the code more readable and easier to use. Since we have already proven that the closure method works for input and outputs we can take advantage of that and not modify existing code. To allow the creation of a task with a single input argument we can create the following helper function. // Creates a new task with a single input argument. func NewWithInput[T any](f func(T), input T) Task { fun := func() { f(input) } return New(fun) } // usage t := NewWithInput(func(i string) { fmt.Println(i) }, "Hello with generics!") t.Start() t.Wait() </code></pre> This helper function takes a function that takes a single argument and a value to pass into that function. To allow a task to return a value we must slightly modify the Task</code> struct to store the return value. We create a new constructor function to simplify creation of the new struct and a getter function to get the result after blocking on the execution of the task. // Task struct that stores a single result value. type TaskWithResult[T any] struct { Task result T } // Creates a new task that stores a single result value. func NewWithResult[T any](f func() T) TaskWithResult[T] { t := &TaskWithResult[T]{ Task: New(nil), } t.f = func() { t.result = f() } return t } // Returns the result value after waiting for the task to finish. func (t TaskWithResult[T]) GetResult() T { t.Wait() return t.result } </code></pre> This new constructor closes over its own container struct in order to store the result value. Using these new features are straightforward and shown in the following example. GetResult</code> is called rather than Wait</code> so that we get the result value after the task has finished. t := NewWithResult(func() string { return "Hello with generic output!" }) t.Start() fmt.Println(t.GetResult()) </code></pre> These approaches can be combined based on the needed input and output tasks of the application. Unfortunately we would need to create a new version of these functions and wrapper structs for every variation. If we were building a library we would not want to create a new function for every possible number of arguments. Code generation and reflection could help solve this but we won't explore that now. Actor Model</a> </h2> The actor model is a concurrency abstraction that is based on the idea of actors that communicate with each other via messages. An actor can only do three things when receiving a message: mutate internal state, send a message to another actor, and create new actors. 1</a> Message sending is asynchronous and non-blocking by default so the order of messages is not guaranteed. The actor is the base unit of computation and they compose to form larger systems. One of the interesting properties of an actor model based system is that there is no shared state between actors. This allows for greater fault tolerance and easier reasoning about the system. This pattern has been implemented in many languages and is a proven approach to distributed systems. Erlang and other BEAM languages such as Elixir are built around this concept. BEAM languages use an abstraction on top of the actor model known as OTP (Open Telecom Platform)2</a> that forms a powerful framework for building distributed systems. For a Go implementation of OTP see https://github.com/ergo-services/ergo. This example implementation of the actor model is more basic. An extra benefit of the actor model is that it can be easily scaled out to a distributed system where the actors are running on different machines though we won't cover that case here. ^{1 See https://www.brianstorti.com/the-actor-model/ for a good introduction to the actor model as well as https://en.wikipedia.org/wiki/Actor_model for more history and detail. </div>}^{2 See https://github.com/erlang/otp and https://erlang.org/download/armstrong_thesis_2003.pdf for more information on OTP. </div>}Actors</a> </h3> In Go, goroutines</code> make a great foundation for actors as Erlang processes do for BEAM languages. On top of the virtualized lightweight unit of computation we only need to add a message queue to create an actor. Some synchronization is also necessary in to improve the usability of the actor. This example creates a simple Actor</code> struct that wraps up a configurable actor implementation with a message queue and a wait group for synchronization. The handling of messages is configured at construction via a function that is stored in the struct. // actor.go type Actor[T any] struct { messages chan T handler func(T) wg sync.WaitGroup } // Creates a new actor with the given handler function. func New[T any](handler func(T)) Actor[T] { a := &Actor[T]{ messages: make(chan T), handler: handler, } go func() { for m := range a.messages { a.handler(m) a.wg.Done() } }() return a } // Sends a message to the actor. func (a Actor[T]) Send(m T) { a.wg.Add(1) go func() { a.messages <- m }() } // Waits for all messages to be finished and closes the channel. func (a Actor[T]) Stop() { a.wg.Wait() close(a.messages) } </code></pre> The Actor</code> struct has a generic type parameter to allow for a variety of message types. It implements a Send</code> method that adds the message to the message queue and increments the wait group. This is done asynchronously so that the caller does not block though the wait group ensures that when we stop the actor it drains existing messages. Asynchronous message sending is expected in an actor model based system. The Stop</code> method waits for all messages to be processed and then closes the message queue. Note that the messages</code> channel is not buffered and we are able to accept multiple messages because we are using a goroutine to send and process each message. See the following snippet for usage of this struct. In this example we create a simple actor that prints out the message it receives. a := actor.New(func(s string) { fmt.Println(s) }) a.Send("Hello, World!") a.Send("Hello again, World!") a.Stop() </code></pre> The messages will not always be printed in the order they were sent because actors are asynchronous and non-deterministic by default. Specialized Actors</a> </h3> The Actor</code> struct we built above is a generic implementation that can be expanded upon to create more specialized actors. In this example we create a specialized actor that prints every message (of type string) it receives. // printer.go type Printer struct { Actor[string] } func NewPrinter() Printer { p := &Printer{} p.Actor = New(func(s string) { fmt.Println(s) }) return p } func (p Printer) Print(s string) { p.Send(s) } </code></pre> All we are doing to the generic Actor</code> is creating a custom constructor and wrapping the Send</code> method with a more specific name. The following snippet shows how this would be used to perform the same task as the generic Actor</code> example above. p := actor.NewPrinter() p.Print("Hello, World!") p.Print("Hello again, World!") p.Stop() </code></pre> The output is the same but we get a little bit more reusability and better readability with our specialized actors. Multiple Actors</a> </h3> Actors are rarely useful on their own. Instead, they are typically composed into larger systems that accomplish more complex tasks. In this example we create two types of actors: a ChatRoom</code> and a Client</code>. The ChatRoom</code> is responsible for printing any message it receives along with the sender's name. The Client</code> is responsible for sending messages to the ChatRoom</code>. // chat_room.go type ChatRoom struct { Actor[message] } // Creates a new chat room that prints messages that come in. func NewChatRoom() ChatRoom { c := &ChatRoom{} c.Actor = New(func(m message) { fmt.Printf("%s: \t %s\n", m.sender.name, m.text) }) return c } type Client struct { Actor[string] name string } // Creates a new client that sends messages to the given chat room. func NewClient(name string, room ChatRoom) Client { c := &Client{ name: name, } c.Actor = New(func(t string) { m := message{ sender: c, text: t, } room.Send(m) }) return c } type message struct { sender Client text string } </code></pre> All we need to do to implement this is create custom types and constructors for each actor type that sets their message handling behavior as well as create a small custom struct to serve as the message type. This snippet shows these actors in action. // create chat room chatRoom := actor.NewChatRoom() // create clients alice := actor.NewClient("Alice", chatRoom) bob := actor.NewClient("Bob", chatRoom) // send messages alice.Send("Hello, Bob!") bob.Send("Hello, Alice!") // stop actors and wait for them to finish alice.Stop() bob.Stop() chatRoom.Stop() </code></pre> The chatroom</code> actor is constructed, then two clients are created with the chatroom</code> pointer as an input so that their handlers know which actor to send messages to. The clients then send messages to each other and the chatroom</code> prints them out. Finally, all actors are stopped and the program exits. Note that the actors must be stopped in this example so that we make sure to wait for all messages to be processed since they are passing asynchronously. More advanced actors might accept multiple types of messages and have more complex message handling logic. They may also store more complex state. Supervisor actors that manage other actors and enhance fault tolerance are also common. Conclusions</a> </h2> The fundamental building blocks of Go allow for some expressive and powerful concurrency patterns. Despite the fact that in reality most usages of concurrency would be more bespoke, the basic tools of Go allow for a lot of flexibility. Some future exploration could include: More complex actor systems and a more thorough implementation of the actor model</li> Event based concurrency patterns</li> Performance benchmarking of the different approaches and comparison with other languages</li> Error handling and fault tolerance</li> Using buffering to improve performance and change behavior of the channels</li> </ul> Further Reading</a> </h2> The Go Programming Language</a> by Alan A. A. Donovan and Brian W. Kernighan is a great resource for understanding Go and has thorough descriptions of concurrency in Go. Go By Example</a> has useful examples of Go features including those for concurrency. Save your System with sysrq 2023-01-10T00:00:00+00:00 [1] What the heck is SysRQ?:</a> </h2> SysRQ is a key on your keyboard. If you don't see it, chances are your PrtSc key doubles as it. The insert key and PrtSc/SysRQ key are usually right next to each other, near where your numpad would be. [2] What does SysRQ do exactly, and how can it save my system?:</a> </h2> SysRQ is the magic key (that is even what it is called in the Linux kernel). You can use it to send messages directly to the kernel. Here are some situations where you might want to do that: Your system freezes, and your only option (not knowing about SysRQ ofc) is to hard turn off the machine. (I cannot think of any others at the moment, this is kind of what you would use SysRQ primarily for!)</li> </ol> The reason you would not want to hard power off the machine is because that surprises the OS. If the OS is in the middle of writing to disk for example, it could corrupt the filesystem (which is not good at all)! SysRQ comes in handy, because it talks directly to the Linux kernel. So, even if everything on your system is locked up, you can still communicate directly to the Linux kernel, with SysRQ. SysRQ allows you to reboot your computer correctly. [3] Great! So... how do I use it?:</a> </h2> In order to use it, we must make sure the system is configured to use it. You can make sure by reading the output of this command: cat /proc/sys/kernel/sysrq If the output is: 1: Enabled, and you can skip to section 5. Not 1: Not enabled, and you have some work to do. [4] Alright, how do I enable SysRQ?:</a> </h2> You can enable SysRQ with a simple command... sort of, see, you can enable it with this command as root: echo 1 > /proc/sys/kernel/sysrq But the issue is that this does not persist after a reboot! If you want to have your changes stay even after rebooting, you will have to run this at startup. Depending on the distro, there are different ways to do this: Generic Distros: You can enable SysRQ even after reboot with this simple command as root: echo "kernel.sysrq = 1" >> /etc/sysctl.d/99-sysctl.conf NixOS: You can do this on NixOS by adding one line to configuration.nix in the global scope: boot.kernel.sysctl."kernel.sysrq" = 1; [5] Okay... now, how to use SysRQ?:</a> </h2> I mentioned earlier that all most people are gonna use SysRQ for is rebooting their machine properly if it freezes. If you want to do this, you have to remember 6 letters: REISUB A good way to remember these is to remember: (R)eboot (E)ven (I)f (S)ystem (U)tterly (B)roken If you want to actually do this, what you need to do is hold down the ALT key, and the SysRQ key down at the same time. Once you are holding them down, you want to press the first or next queued letter. And, you need to release the ALT and SysRQ keys after every letter (command) pressed. So, you would end up holding down ALT + SysRQ 6 times during the REISUB sequence. I repeat, you can not enter multiple letters without releasing your fingers from ALT + SysRQ, then putting them back down! What REISUB is doing: R: Turns off keyboard raw mode, and sets it to XLATE. E: Send a SIGTERM to all processes, except for init. I: Send a SIGKILL to all processes, except for init. S: Will attempt to sync all mounted filesystems. U: Will attempt to re-mount all mounted filesystems as read-only. B: Reboot! [6] Did you find this out yourself?:</a> </h2> No, I watched a Chris Titus Tech video about it. Here is the link: </iframe> </div>

RIP Bram Moolenaar

Concurrency Abstractions in Go: Queues, Tasks, and Actors

Introduction
Code for this post can be found at GitHub</a> or GitLab</a>.</strong></p>

Further Reading </a> </h2>
The Go Programming Language</a> by Alan A. A. Donovan and Brian W. Kernighan is a great resource for understanding Go and has thorough descriptions of concurrency in Go.</p>
Go By Example</a> has useful examples of Go features including those for concurrency.</p>

Save your System with sysrq

[1] What the heck is SysRQ?:

[3] Great! So... how do I use it?:
[4] Alright, how do I enable SysRQ?:
[5] Okay... now, how to use SysRQ?:
[6] Did you find this out yourself?:

[3] Great! So... how do I use it?:
[4] Alright, how do I enable SysRQ?:
[5] Okay... now, how to use SysRQ?:
[6] Did you find this out yourself?:

[3] Great! So... how do I use it?:
[4] Alright, how do I enable SysRQ?:
[5] Okay... now, how to use SysRQ?:
[6] Did you find this out yourself?:

[4] Alright, how do I enable SysRQ?:
[5] Okay... now, how to use SysRQ?:
[6] Did you find this out yourself?:

[5] Okay... now, how to use SysRQ?:
[6] Did you find this out yourself?:

[6] Did you find this out yourself?:

My Blog

Static Typing or Type Inference in Go