Let's Go! Why Golang is the way to go :)
Published: 2022-12-19 10:08:34

Not so long ago, while I was working on creating an outline for my upcoming Golang workshop one of my teammates came and asked me "Noaa, what is so special about Golang?". His question got me thinking “Why do I like this language so much?”, and I realized that I’m not really sure and maybe I don’t really understand Golang. So I decided to go on a new journey - my journey after the meaning of Golang. 

In this article, we are going to talk about How Golang was invented in the first place, what is so special about it, when you should use it and why for those use cases I believe that Golang language is the way to go 🙂

> Big thank you and credits to Karolina Rusinowicz, and Jacek Olszak who wrote [“Why Golang may be a good choice for your project”](https://codilime.com/blog/why-golang-may-be-a-good-choice-for-your-project/). I learned a lot and used your article as a resource.
> 

## What is Go?

- Go was developed by Google in 2007.
- It was first released as an open source in 2009.
- Go was designed just for that: to run on multiple cores and it was built to support concurrency. Concurrency in Go is considered very cheap and easy.

### **How Go was born?**

---

A long time ago, in the early 2000, Google was growing exponentially. 📈 They grew so fast that they started to have a lot of scaling problems. They simply had too much of everything! Lots of software and systems, millions of lines of code being developed by hundreds of programmers, and finally lots of hardware on which all this software was launched.

In addition to that, Google’s entire source code was stored in one monolithic repository and their build took **a huge amount of time.** It was so long that to perform such a build, **Google created its own build system to compile the code on many machines in parallel.** 

But... despite all this and many other optimization efforts, the time needed to build certain systems reached several dozen minutes in 2007.  

This became a problem for a lot of other companies besides Google... 🌍  
At that time, multi-core processors became common and the infrastructure became much more scalable, dynamic, and had more capacity. Using cloud infrastructure with hundreds of servers with multiple processors to deploy applications became universal. However, back then code compilation (mainly in C++) lasted too long and coding with threads and memory sharing (in C++ and Java) to write concurrent code was considered too complicated. Programmers made a lot of mistakes, and the code was often not optimized. In most cases, a thread was left waiting—and gobbling up resources like RAM and CPUs.

To solve this problem, **alternative models of concurrent programming were created**. 💡 
An asynchronous model used especially in Node.js is one of them. However, it wasn’t so Promising 🙃 **it was still complex for programmers to use and even much more difficult to debug.** Additionally, there were many approaches to C++ and Java programming (which were the top languages for multi-threading) but none emerged as best-in-class. 

**This resulted in the code being difficult to manage and in needlessly long compilation times.**

Fed up with these pitfalls, Googlers Robert Griesemer, Rob Pike, and Ken Thompson,  decided to create a new language. This language was supposed to increase the productivity of Google engineers and allow them to use the company’s huge hardware resources more effectively. Since the most widely used programming languages at Google were C++ (mainly for servers) and Java/Python (the rest of the code), this new language needed to be similar to them so that programmers could learn it easily.

And this is exactly what they did. They wrote the code, published it as an open-source named **Golang** and they lived happily ever after. 🌈

### Why Go?

---

1. **CONCURRENCY MADE EASY**
    
    Go introduced an alternative model of concurrent programming, ****one based mainly on [CSP language](https://en.wikipedia.org/wiki/Communicating_sequential_processes). This new model introduced `goroutines` which communicate with each other using `channels`  (you can think about them as mailboxes). `goroutines` had several advantages over threads and memory sharing, one of them was that they were easier to understand which made the code much more simple and safe.
    
2. **FAST PROGRAMS**
    
    Programs written in Go are executed fast and use little RAM. One reason why is because when Go code is compiled, it creates an executable file. This is not `bytecode` or any other intermediary code, it’s *a machine code.* 😎 Another reason is because of Go’s `goroutine`. A `goroutine` is a lightweight thread managed by Go runtime and it consumes fewer resources than threads in Operating Systems.
    
3. **FAST BUILD**
Go’s compilation is very fast because Go was designed to enable its compiler to analyze dependencies quickly and avoid loading files repeatedly. Under the hood, Go, compiles the source code incrementally, creating an object file for every package. so when somebody uses a specific package, it loads the previously prepared file. 

# Local Setup

In order to compile Go source code, Go requires two `.env` variables exists, `$GOPATH` and `$GOROOT` →  `$GOPATH` pointing to the directory where the Go source code exists, and `$GOROOT` points to Go’s installation directory. 

<aside>
💡 Go v1.11 does introduce the concept of [modules](https://github.com/golang/go/wiki/Modules) that allows you to have your project code outside of your `GOPATH`.

</aside>

After installing Go, you have to configure your workspace. 

### Workspaces

**A Go workspace** is a directory stored on your local machine for your Go code. Go doesn’t require a special name or location for the workspace however, by default, Go expects all code to be in a single workspace. The reason why is for the compiler to operate at optimal efficiency. The path to your workspace should be stored in `$GOPATH`.

Inside the workspace there must be 3 subdirectories named by convention:

**`$GOPATH/src`**  - for the code.

**`$GOPATH/pkg`**  - stores archived files of packages installed in programs. This essentially helps to save compilation time based on whether the packages being used have been modified.

**`bin`**  - stores all the compiled binaries.

## File structure

**`go.mod`**

The `package.json` file for Go. 
Modules are the Golang support for dependency management. A module by definition is a collection of related packages with a **`go.mod`** file at its root. All the modules which are needed to be used in the project are maintained in `go.mod` file.

The **`go.mod`** file defines:

- Module import path.
- The version of go with which the module was created
- Dependency requirements of the module for a successful build. It defines both projects’ dependencies requirements and also locks them to their correct version.

**`go.sum`** 

The `package-lock` file for Go.

This file contains all the project’s dependencies(a.k.a dependencies checksums) and it is managed by the go tools. 

### Packages

A package is the entry point to access a Go code. All go code is organized into packages and it simply consists of several`.go` files. You might be surprised to know that packages are the most powerful part of the Go language! (see “Why Go?. Fast Build” section).

**Common packages structure** 

1. **`/cmd`** 
    
    In general, this folder contains the main entry point files for the project, with the directory name matching the name for the binary. In our project, this folder contains the main commands entry points. Each directory name matches the name of the command.
    
2. `**/pkg**`
    
    This is the place to put public libraries. Usually, this may include API clients or utilities which may be handy for other projects but don’t justify their own project. The important thing to remember is that other projects might import these libraries, so we need to think twice when we make changes.
    
3.  **`/internal`**
    
    The `internal` directory is the place to put your private packages. If you put your code in an `internal` directory no external project will be able to import that code. Any code that lives outside of `internal` parent directory won’t be able to import this code. 
    
    [Go 1.4](https://golang.org/doc/go1.4#internalpackages) introduces an ability to hide code using `internal` directories. 
    

### Common best practices

- Go projects often keep the core types grouped at the top of a file.
- Organize code by responsibility, not by type.
- Package names are often single form, lowercase (not snake_case or camelCase).