What are the best things about Golang?
Go is an open-source programming language that makes it easy to build simple, reliable, and efficient software. This is how Golang describes itself.
Language highlights :
- Started in 2007
- Announced in November 2009
- Released v1.0 in March 2012
- Stable release: 1.19.3 / 11 November 2022
Strengths
- Memory-Managed (Garbage collector)
- Go compiles directly to machine code
- Fast compilation
- Concurrency
- Powerful standard library/tool
Weakness
- Function Overloading
- Inheritance
- Error Handling
You can look to hear the general knowledge about Golang like syntax, usage, etc. I’d instead take a look at other great features.
What are the best things about Golang?
- Concurrency
- Goroutines
The most exciting thing about Golang for me is the Concurrency. I want to quote from a presentation shared by Rob Pyke in 2012. There are a few questions should I ask myself.
Why Concurrency?
- Look around you. What do you see?
- Do you see a single-stepping world doing one thing at a time?
- Or do you see a complex world of interacting, independently behaving pieces?
That’s why. Sequential processing on its own does not model the world’s behavior.
So, What’s Concurrency?
Concurrency is the composition of independently executing computations. Concurrency is a way to structure software, particularly as a way to write clean code that interacts well with the real world. It is not parallelism. If you have only one processor, your program can still be concurrent but it cannot be parallel.
Who saves gophers from the difficulties(threads, semaphores, locks, etc.) of parallelism?
Goroutines
You may have heard the Goroutine for the first time, but if you’ve ever printed “Hello World” with Go, congratulations! You have unwittingly used a goroutine. The func main() is the Goroutine. It wouldn’t be wrong to call it a lightweight thread. It has its stack that grows or shrinks when required (Up to 1GB on 64-bit and up to 250MB on 32-bit architectures). The minimum stack size of the goroutine is just 2MB. As it is known, threads are controlled by OS but goroutine is controlled by its runtime, this makes it cheap for example it provides low-cost context-switching. It’s launched by a go statement.
For example:
package main
import (
"fmt"
)
func main() {
go rohirrim("To the king!") // love this part btw.
}Goroutine is an independently executing function. So how do you communicate between two Goroutines?
Channels
“Do not communicate by sharing memory; instead, share memory by communicating”
When goroutines communicate by sharing memory, we use traditional concurrency synchronization techniques, such as mutex locks, to protect the shared memory to prevent data races. We can use channels to implement sharing memory by communicating.
Golang provides a unique concurrency synchronization technique, channel. Channels make goroutines share memory by communicating. We can view a channel as an internal FIFO (first in, first out) queue within a program. Some goroutines send values to the queue (the channel) and some other goroutines receive values from the queue.
// Declaring and initializing.
var c chan int
c = make(chan int)
// or
c := make(chan int)
// Sending on a channel.
c <- 1
// Receiving from a channel.
// The "arrow" indicates the direction of data flow.
value = <-cChannel can only transfer values of the element type of the channel. Channel types can be bi-directional or single-directional (T is any type):
- chan T denotes a bidirectional channel type. Compilers allow both receiving values from and sending values to bidirectional channels.
- chan<- T denotes a send-only channel type. Compilers don’t allow receiving values from send-only channels.
- <-chan T denotes a receive-only channel type. Compilers don’t allow sending values to receive-only channels.
Values of bidirectional channel type chan T can be implicitly converted to both types, but a receive-only type and send-only type cannot be converted to each other.
We’ll dive deeper in the next post. Thank you for reading. Your feedback is very important to me.
