Go is strongly typed, and with that, we get many options for simple variable types like integers and floats. The problem arises when we have a uint16, and the function we are trying to pass it into takes an int. We find code riddled with int(myUint16) that can become slow and annoying to read. In other words, when Go developers stray from the “default” type for any given type family, the code can get messy quickly.
The Go standard library has a really cool type - Ticker. Tickers are used when you want to do something at a regular interval, similar to JavaScript’s setInterval. Here’s an example: package main import ( "fmt" "time" ) func main() { ticker := time.NewTicker(time.Second) go func() { for range ticker.C { fmt.Println("Tick") } }() time.Sleep(time.Second * 4) ticker.Stop() fmt.Println("Ticker stopped") } As per the docs, a ticker is a struct that holds a receive-only channel of time.
In microservice architectures, it’s fairly common to have a project that includes different worker types. A Makefile can be used to manage the creation of multiple programs, but the Go toolchain has a tool that can be used as well, go generate. Here are some examples of how it can be used: API/Worker - We have an API that allows clients to start/stop long-running jobs, and a worker which accesses the same database to run the jobs.
An anonymous struct is just like a normal struct, but it is defined without a name and therefore cannot be referenced elsewhere in the code. Structs in Go are similar to structs in other languages like C. They have typed collections of fields and are used to group data to make it more manageable for us as programmers. To create an anonymous struct, just instantiate the instance immediately using a second pair of brackets after declaring the type:
Go is a strongly typed language, which means at any point a developer should know exactly what type of value they are dealing with. For example, if we have a function that prints a string, we can’t just give it an integer and expect it to work. We have to cast it to a string explicitly: func main() { num := 5 numString := strconv.Itoa(num) printString(numString) } func printString(s string) { fmt.
Errors in Go are a hot topic. Many newcomers to the language immediately level their first criticism, “errors in go are clunky! Let me just use try/catch!” This criticism is well-meaning but misguided. The paradigm of errors as a type, rather than something to be thrown and cause panics, allows for more control of how to handle “bad” state. It also forces developers to think about errors at every step.
Let’s discuss a few rules of thumb for logging in Go, as well as some features you may not have heard of that can make debugging easier. Best practices for logging in Go are not so obvious and sometimes we need to look closer to see what is the best choice, considering the unique situation of error handling in Go. Use Errors Where Appropriate, Not Strings Wrap Errors Use Formatters Like fmt.
Singletons are fairly controversial as far as I can tell, especially in JavaScript programming. Let’s take a look at what they are, when to (maybe) use them, and when not to. What is a Singleton? A singleton is a class that allows only a single instance of itself to be created and gives access to that created instance. It contains static variables that can accommodate unique and private instances of itself.
For the most part, I’ve found that Go developers are pretty good at using global constants for configuration rather than global variables. However, a problem arises when we want a constant version of some of the more complex types. The Go compiler does not allow us to create array, map, or slice constants. After realizing this, many developers decide to use a dangerous global variable. In this article, we will explore some alternative options to effectively make constant maps, slices, and arrays, albeit with some trade-offs.
My worst enemy is processes that a developer spun up years ago on a server everyone has forgotten about. I don’t know how to find these systems reliably, I don’t know where they came from, what depends on them, and if they are safe to delete. For example, the dreaded 15 6 2 1 * /home/lane/backup.sh. You may recognize this as a Unix cronjob, a job that is scheduled to run on a server periodically.