What exactly do I mean by this. Let me explain through an example:

package main

import (
    "fmt"
    "time"
)

type Country struct {
    Name       string
    Continent  string
    Population int32
}

func updatePopulation(c *Country, newBorns int32) {
    c.Population += newBorns
    fmt.Printf("New population of %v is %v\n", c.Name, c.Population)
}

func main() {
    totalStates := 50 // total number of sources, (US states)
    us := Country{"USA", "North America", 32000000}
    for i := 0; i <= totalStates; i++ {
        go updatePopulation(&us, int32(i))
    }
    time.Sleep(time.Second * 5)  // this is just so that we don't need channels
}

Here is a very simple example. Say we have an application that is tracking the population of countries in real time. The population of a country is dynamic, babies get born all the time, and sadly some people pass away all the time.
The USA is a huge country, which consists of 50 states. So, for the sake of my example, this updatePopulation will simulate a single call to some Census Agency of every state. Since we're in a cheerful mood (and also because I need it to prove my point), we'll only register the newborns and not the departed.

Since we want this app to truly be a real-time tracker, we don't want to make synchronous API calls, we want to make them concurrently, hence the go in front of the updatePopulation function call.

That should do it, right? Let's see the result:

New population of USA is 32001199
New population of USA is 32001030
New population of USA is 32001206
New population of USA is 32001176
New population of USA is 32000957
New population of USA is 32001005

Hmm.. I gotta say, I'm kind of concerned here. If we are only tracking newborns , and not tracking the deceased... how come our population is actually lower in the last line than the first line?

Well, it's because we haven't implemented thread safety. Our various goroutines are accessing the same memory address without any respect for order. It's like those old people at the supermarket that pretend they don't see the line.

We need to implement some order here.

Enter Mutexes.

Mutex is short for Mutually Exclusive Lock. It's used so that when one thread (or goroutine in the case of Golang) is accessing a value inside a memory address, it can lock out the other threads so they have to wait in line. This guarantees that there will not be any of this random accessing and changing of values. Let's implement:

package main

import (
    "fmt"
    "sync"
    "time"
)

type Country struct {
    Name       string
    Continent  string
    Population int32
    mu     sync.Mutex
}

func updatePopulation(c *Country, newBorns int32) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.Population += newBorns
    fmt.Printf("New population of %v is %v\n", c.Name, c.Population)
}

func main() {
    totalStates := 50 // total number of sources, (US states)
    us := Country{"USA", "North America", 32000000, sync.Mutex{}}
    for i := 0; i < totalStates; i++ {
        go updatePopulation(&us, int32(i))}
    time.Sleep(time.Second * 5)
}

The sync.Mutex is a struct that we use for implementing mutexes in Go. The default value is an unlocked mutex, as you can see from the standard library code:

// A Mutex is a mutual exclusion lock.
// The zero value for a Mutex is an unlocked mutex.
//
// A Mutex must not be copied after first use.
type Mutex struct {
    state int32
    sema  uint32
}

Now, let's run our app again and see what the result will be:

New population of USA is 32000979
New population of USA is 32001023
New population of USA is 32001072
New population of USA is 32001108
New population of USA is 32001146
New population of USA is 32001185
New population of USA is 32001225

This looks good. The values are constantly incrementing, meaning that order is restored. Now, you might wonder why we use the defer c.mu.Unlock() code immediately under the line of code where we establish the lock. The reason for this is because we need to avoid a deadlock. Deadlocks are vulnerabilities of mutexes that must be avoided at all cost. Imagine something happens between the locking of a memory address and it's unlocking that causes the goroutine to stop. It would mean that this lock is going to be implemented indefinitely and that all of the other goroutines will not be able to access it at all. This is why we use the defer keyword, because it will guarantee that no matter what happens in that function, it will unlock after exiting.

I'd also like to mention that beside the standard sync.Mutex that we used above, there also exists another mutex - sync.RWMutex .

That's right folks, the complexity is far from finished. Whoever told you that Golang is easy ( that would be me, just a few articles ago) really had no idea about the low-level concepts you need to master before using it responsibly.

The point is that each time a goroutine implements a lock, the other goroutines have to wait in line, thus slowing down the overall performance. But, what if these goroutines just want to read the value from that memory address. That's safe, right? Why would the goroutine that implemented the lock hog the memory address all to itself, if the others promise not to change anything, just read the value and go on with their business.

So if you change the sync.Mutex field in the Country struct to be sync.RWMutex , you now have the possibility of getting even more functionality:

1. Lock(): only one go routine reads/writes at a time by acquiring the lock.

2. RLock(): multiple go routines can read(not write) at a time by acquiring the lock.

I actually copy/pasted these two definitions from Stack Overflow (like any well mannered programmer would do) . Here is the original post:

https://stackoverflow.com/questions/53427824/what-is-the-difference-between-rlock-and-lock-in-golang

Finally, I want to address the fact that most of you who were coming from Python and JavaScript like me, were probably shocked to even learn that something like a Mutex even exists. The reason we never heard of this concept from our dear dynamically typed, interpreted languages is because in the case of Python (CPython to be specific) the GIL (Global Interpreter Lock) acts a a gigantic Mutex over everything, so using explicit locks wouldn't really change anything. Although, you can implement a Lock and Unlock by using the threading library, but even the documentation says:

CPython implementation detail: In CPython, due to the Global Interpreter Lock, only one thread can execute Python code at once (even though certain performance-oriented libraries might overcome this limitation). If you want your application to make better use of the computational resources of multi-core machines, you are advised to use multiprocessing or concurrent.futures.ProcessPoolExecutor. However, threading is still an appropriate model if you want to run multiple I/O-bound tasks simultaneously.

Basically they are saying - just use the library for IO (but I would suggest using asyncio), and if you really need OS threads, Python probably isn't that great of an option.

For JavaScript devs, the reason is even simpler - you never used mutexes, because JavaScript has only one thread. And, guess what, it does it's job pretty well with it. Once again, if you are doing compute heavy operations that are time sensitive, go with C++ or Rust. Luckily, most modern backend servers don't need compute heavy operations, they are totally IO based, and spend most of their idle time waiting for a db server to return some input. Golang is beautiful because it has the ability to use both OS threads and goroutines.

That's all for this article. If I missed anything please leave a comment. Thanks for reading!

Ever hear of the term "pass by reference" ? It's used all the time in Python, JS and many more. Here's an example in Python to describe what I mean:

a = [1,2,3]
b = a
b.append(4)
print(a)

You'll see from this simple example that not only are the values of a and b the same, but a and b are the same. You can check this by printing the memory addresses of both:

print(id(a))
print(id(b))

The reason they are the same is because when we say b=a, we're not saying assign b the value of a, rather assign b to be a pointer to a.

Languages like Python and JavaScript were created to abstract away many low level concepts so that developers had less on their mind, and could focus more on business logic. These languages were created in the 1990s when memory was scarce. Why is that important for pointers? Well, imagine you have a data structure like this:

people = {1: {'name': 'John', 'age': '27', 'sex': 'Male'},
          2: {'name': 'Annie', 'age': '22', 'sex': 'Female'},
          3: {'name': 'Jane', 'age': '42', 'sex': 'Female'},
          4: {'name': 'Bob', 'age': '31', 'sex': 'Male'},
          5: {'name': 'Andy', 'age': '36', 'sex': 'Male'},
          6: {'name': 'Lisa', 'age': '32', 'sex': 'Female'},
          7: {'name': 'Jimmy', 'age': '26', 'sex': 'Male'},
          8: {'name': 'Gregory', 'age': '36', 'sex': 'Male'}}

Let's see how much memory this object will take up when placed in the heap:

print(sys.getsizeof(people))

360 bytes. Not too big, but we could easily imagine this dictionary containing 800 keys instead of 8. Imagine copying the value of this variable whenever we wanted to do something with it. You would potentially run out of memory if memory was scarce and expensive, like in the previous decades. Wouldn't it be cheaper to just copy a reference to this variable. It's like having 200 pounds of sugar (for whatever reason maybe you really like sugar, just stick with me) . Would you rather always carry that huge load of sugar around with you, or would you perhaps store it in some locker, write down the address of that locker, and then when you need some (or all) of that sugar you just go to that address.

That's the whole point of pointers (no pun intended).

Pointers are integers that store the value of the memory address. Being integers, they only take up 4 bytes on a 32 bit system, or 8 bytes on a 64 bit system. Which is way less than the 360 bytes (or potentially 36000 bytes) that our people variable value takes up.

However, passing around references can get complex and error prone sometimes, that is why it is good to have an option to pass by value as well.

Golang, unlike Python or JavaScript, is a pass by value language. If you want to pass by reference, you use explicit pointers.

Okay, so basically we should use pointers all the time, right?

No.

In fact, I'll quote Ben Darnell, who is the lead engineer of CockroachDB (built in Go) :

"Whenever in doubt, use a value instead of a pointer"

We're no longer in the 1990s , memory is cheap. If you don't need a pointer, you should stick to a value. However, in many cases, you will indeed need a pointer.

Here are some of the common situations where you will need to use a pointer instead of a value:

1. Changing the state of an object:

Let's say you have a struct like this

type Person struct {
    name     string
    age      int
    gender   string

}

Now, you want a method that will enable you to change the name of a person. Coming from Python, your gut instinct would tell you to write

func (p Person) changeName(name string){
    p.name = name
}

The problem is, Golang being Golang, you are passing by value, meaning you are not passing the real p but only a clone that copies it's values. Changing the state of the clone will not affect the original.

This is why you need a pointer here.

func (p *Person) changeName(name string){
    p.name = name
}

2. Enabling variables to have nil values

This is a gotcha that leads a lot of Go beginners to create bugs. A variable that is defined, but not assigned a value, does not evaluate to nil but rather to it's default value. For booleans this is false, for integers it is 0, for strings it is an empty string. But, what if you need it to be nil. Say you have a REST API endpoint that allows end users to create accounts in your application by using the POST /accounts endpoint. They pass their info in the body of this request and your backend Go server then converts this JSON body into a User struct, does some validations, and then stores this data in the database. Suppose you write your struct like this:

type User struct {
    username   string
    email      string
    profession string
    country    string
}

Now, let's say that some user sends their POST request to your server, but leaves the profession parameter out of the body because it is a non-required parameter, and the user wishes not to specify their profession. The way this struct is defined, the profession would not evaluate to nil`` , but to''``` . Is this some kind of new profession? Or is this intended to be empty? Did the user mistakenly pass an empty string? Here, it would be more appropriate to use a pointer to a string, instead of just a string. You could also imagine situation where an integer evaluates to 0, when the value shouldn't even exist, because it wasn't specified. Imagine a football match struct:

type Match struct {
    homeTeam        string
    awayTeam         string
    HomeTeamGoals int
    AwayTeamGoals    int
}

What if the match hasn't started yet. Wouldn't it be more appropriate if the HomeTeamGoals and AwayTeamGoals were nil instead of evaluating to 0.

Your application logic would be able to assert if a value is nil, then the match hasn't started. So better to define the struct like this:

type Match struct {
    homeTeam   string
    awayTeam      string
    HomeTeamGoals *int
    AwayTeamGoals    *int
}

Make it a rule that if you need a variable to be able to evaluate to nil, you need a pointer.

3. Copying struct that have very large values:

Although memory is not that big of an issue today, you might still want to use a reference if the value of the object is ridiculously large, and there is really no need to pass it around all the time. This will probably improve the performance and memory usage of your application (although probably not significantly) . There is a trade off, because now the garbage collector has more work to do, but in cases of very large and complex structs, I think using pointers makes more sense.

As you can see, using pointers is sometimes over-engineering, and although it makes the code seemingly look sophisticated it's actually doing damage. However, sometimes you have no other option.

Thanks for reading, and if I missed anything important, please leave a comment :)

Although it is officially a NoSQL database, you'll usually use it as a cache, or maybe a pub-sub system. Some developers are advocating using it as a primary database, but I think for now that's a bit too extreme.

In this article, we'll look at some code that basically implements a couple of simple API endpoints, that use Redis to access/store the data.

I'll also be using commands like go mod init and go get to initiate a go module and get the third party package I will use to connect to my Redis instance.

By the way, I'll be running Redis in Docker, so if you have Docker installed on your local machine you should run docker run -d -p 6379:6379 redis to get it up and running. If not, either install Redis locally, or install Docker locally and then run the command above.

So, let's initate a go module and fetch the go Redis driver. I'll do this by typing the following commands in my terminal, in the directory where I'm going to write my code:

go mod init github.com/pavledjuric/go_redis_webapp
go get github.com/go-redis/redis/v8

By the way, just because I name my module with the github.com prefix, doesn't mean it's actually going to be on GH, but if I were to push this code to a git repo, then I would push it to that one.

Now I have a module and the redis driver, so let me create a simple web server:

package main

import (
    "log"
    "net/http"
)

func main() {

    port := ":8080"
    http.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hellooo users!!"))
    })
    log.Fatal(http.ListenAndServe(port, nil))
}

Boring! A simple http server with a single endpoint that doesn't do anything smart. So, let's make that handler take some data from Redis, and be able to write some data to Redis if it's a POST request. I'll also store my handlers in a separate package called handlers just to make it seem more like a real app.

Just so we're on the same page, and there's no issue with imports, your main.go file should go in a directory called cmd . That is go jargon for command, and that's where the executable usually goes. Your handlers directory and all of it's files should go in a directory called pkg. You guessed it , that's short for packages. This is how your project directory tree should look like:

Now let's write the code for our handlers.go file:

package handlers

import (
    "context"
    "io/ioutil"
    "net/http"

    "github.com/go-redis/redis/v8"
)

func UsersHandler(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case "GET":
        var ctx = context.Background()

        red := redis.NewClient(&redis.Options{
            Addr:     "localhost:6379",
            Password: "",
            DB:       0,
        })
        res, err := red.Get(ctx, "user").Result()
        if err != nil {
            w.Write([]byte("Error!"))

        }
        w.Write([]byte(res))
    case "POST":
        body, err := ioutil.ReadAll(r.Body)
        if err != nil {
            w.Write([]byte("Error!"))
        }
        defer r.Body.Close()
        var ctx = context.Background()

        red := redis.NewClient(&redis.Options{
            Addr:     "localhost:6379",
            Password: "",
            DB:       0,
        })
        _, err = red.SetNX("user", body, 60*time.Second).Result()
        if err != nil {
            w.Write([]byte("Error!"))

        }
        w.Write([]byte(body))

    }

}

It may look a bit confusing but it's actually pretty self explanatory. We're using a switch statement that will execute code depending on the HTTP method of the request we're handling (GET or POST) .

If it's GET, we'll create a context and a connection to our Redis server. Next , we'll try to get the data that is stored in the user key in the our Redis db. If we can't find that key, that will return an error, and our server will let us know it's an error.

If the request method is POST, we'll read from the request body and store that data in the user key in Redis with a 60 second time to live. This means that after 60 seconds the data will be deleted from Redis, thus mimicking how a real caching system would work. Of course, in a real application, we would store the data permanently in an SQL or NoSQL database apart from storing it temporarily in the cache.

There's one thing I'd still like to do here. This code doesn't seem too DRY (don't repeat yourself) , since I'm instantiating the redis.NewClient twice with all the connection parameters unnecessarily. Let's extract that to a function, and create another package to store it in. I'll call the package redisconn, so now my project tree looks like this:

The code for the redis connection will go in the redisconn package. Basically, it's just a wrapper to the redis driver we downloaded, but perhaps we wan't to add some custom logic after, so it's a good idea to have it in a separate package:

package redisconn

import (
    "github.com/go-redis/redis"
)

func GetRedisConnection() *redis.Client {

    return redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "",
        DB:       0,
    })
}

Now back to the handlers package, let's import redisconn and update the code. I also wan't to add an http status code of 404 if the data is not found, and 500 if for some reason the server crashes while reading data from the POST request (I forgot to do that initially, and I'm too lazy to update it honestly) :

package handlers

import (
    "io/ioutil"
    "net/http"

    "github.com/pavledjuric/go_redis_webapp/pkg/redisconn"
)

func UsersHandler(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case "GET":
        red := redisconn.GetRedisConnection()
        res, err := red.Get("user").Result()
        if err != nil {
            http.Error(w, "Error!", 404)
            return

        }
        w.Write([]byte(res))
    case "POST":
        body, err := ioutil.ReadAll(r.Body)
        if err != nil {
            http.Error(w, "Internal server error", 500)
            return
        }
        defer r.Body.Close()

        red := redisconn.GetRedisConnection()
        _, err = red.SetNX("user", body, 60*time.Second).Result()
        if err != nil {
            http.Error(w, "Internal server error", 500)
            return

        }
        w.Write([]byte(body))

    }

}

Ok, that definitely looks a bit cleaner now.

So let's try it out:

I first try the GET request, knowing that my Redis db is empty:

Looking good. Now I'll add my user to Redis by sending a POST request. I'll use Postman , but you can use curl or whatever you preffer:

Ok, it seems to have worked, so let's call the GET /users endpoint again:

Beautiful!

However, I'm a bit paranoid by nature, so I wan't to make sure this data is actually coming from Redis, and not some alien hackers from another planet. Let me go inside the docker container that is running Redis and check. I enter the container by running the following command

  docker exec -it a1b redis-cli

This a1b is the first 3 characters of my container ID , yours will most definitely be different . You can check it by running docker ps .

Ok, so I'm in my Redis container, inside the redis cli tool. I run keys * to see that user is indeed there. I run get user to find that the data is definitely coming from Redis:

I'm truly relieved it was not the aliens.

Remeber how we added a 60 second time to live for the data inside Redis, so let's check how much time it has left by using the ttl command:

Now let's wait out those 52 seconds and check again:

Looking good. What about our API server, does he agree?

He does indeed! Seems like everything is working as intended.

In conclusion I would say that connecting Redis to your Go API server is pretty simple as you can see, and it will boost your response times significantly. Typically, you would use a SQL database as a primary db, and Redis would be in front of it. When a user would request data from your API server, the server would first check Redis for the data. If Redis has it, it will return it in a blazing fast manner. If it this data is not in Redis, the server would then retrieve the data from the SQL server (MySQL, Postgres or whatever you’re using), and on it's way back store that data in Redis, with a specified time to live (because your data is probably dynamic and changes often , so you do not want your cache to store it indefinitely) . This is known as the cache-aside pattern. There are other caching patterns like write-through, but I usually use cache-aside and I recommend it for most cases.

That's all for this one folks. Thanks for reading.

Besides the nice and simple syntax, one of it's main advantages is the standard library that is fully equipped with modules that are production ready, and extremely well designed ( there's also a number of great third party modules, but more about some of those in another article) .

One of the finest modules from the Go standard library is definitely net/http , which makes sense, because you really can't do web without the http protocol.

It has a production ready web server, and an extremely easy to use http client for sending requests. Let's see how easy it is to run a web server in Go:

package main

import (
    "fmt"
    "net/http"
)

const portNumber = ":8080"

func HomePageHandler(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("We're live !!!"))
}

func main() {

    http.HandleFunc("/", HomePageHandler)
    fmt.Printf("Starting application on port %v\n", portNumber)
    http.ListenAndServe(portNumber, nil)
}

Pretty self explanatory, right? I've even added a few more lines of code than necessary, just to make things more obvious. The HandleFunc method attaches a route to a handler, and each handler function must accept an http request ( a pointer to it actually) , and a response writer which is in charge of sending the response back via the net to the client.

Another way of writing the handler would have been :

func HomePageHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "We're live!!!")
}

It really depends on style. Fprintf takes any type that implements the io.Writer interface ( the http.Responsewriter is a marvelous example of this, but so is os.Stdout) as a first argument, and a string as a second argument. The string is what we're displaying, and the io.Writer is where we're displaying it.

If we're going to call w.Write , we know that as an implementation of the Write function of the io.Writer interface, we need to give it a slice of bytes, not a string. Luckily converting a string to a slice of bytes is a slice of cake.

Let's take a look at this *http.Request thingamajig:

package main

import (
    "fmt"
    "net/http"
)

const portNumber = ":8080"

func HomePageHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello %v, you are at %v. You have sent some query params too: %v.The method you used is %v", r.UserAgent(), r.URL.Path, r.URL.Query(), r.Method)

}

func main() {

    http.HandleFunc("/hello", HomePageHandler)
    fmt.Printf("Starting application on port %v\n", portNumber)
    http.ListenAndServe(portNumber, nil)
}

I've updated the code so that it is clear that the request struct has everything we need for handling an http request, just like we would with any cool web framework like Flask or Spring Boot. Except, this is not a framework, it's the standard library http module. Ok, I will admit that using a framework like Gin Gonic or Gorilla will speed you up, and keep you from writing a lot of boilerplate code, but for a stadard library http module, this is pretty practical.

Now, what about sending http requests to a remote server. Has anyone written a cool http client for Go, something in the line of the massively successful requests library in Python?

Actually, the original Go creators decided not to give anyone a chance to do that, because the net/http module contains such a simple http client , that there really wasn't any need for a third party library.

Here's a call to github's API:

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
)

func main() {

    req, err := http.Get("https://api.github.com/users")
    if err != nil {
        log.Fatal(err)
    }
    defer req.Body.Close()
    data, err := ioutil.ReadAll(req.Body)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(string(data))

}

Probably the most complicated code here is all of this error checking, but when considering try/catch blocks in other languages, it's not even that bad. I'm calling defer req.Body.Close() here because it's good practice to close a request body, same as you would close a file once you've finished reading from it.

Since the request body is an implementation of the io.ReadCloser interface (what's with all these io module interfaces, right? ) , we can't just print that , we need to call ioutil.Readall which will take the request body and return a byte slice. As we know, turning a byte slice into a string (and vice versa) is not difficult.

Finally, since a large part of backend development today is concerned with REST APIs, I guess it wouldn't be bad to implement a basic GET endpoint that returns some JSON so that the output we get at least remotely resembles something you would see in real life:

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
)

const portNumber = ":8080"

type User struct {
    Name   string `json:"username"`
    Age    int    `json:"age"`
    Gender string `json:"gender"`
}

func UsersHandler(w http.ResponseWriter, r *http.Request) {

    users := []User{
        {
            Name:   "Chris",
            Age:    22,
            Gender: "Male",
        },
        {
            Name:   "Annie",
            Age:    23,
            Gender: "Female",
        },
        {
            Name:   "Jane",
            Age:    25,
            Gender: "Female",
        },
    }

    usersJson, err := json.Marshal(users)
    if err != nil {
        log.Fatal(err)
    }
    w.Write(usersJson)
}

func main() {

    http.HandleFunc("/users", UsersHandler)
    fmt.Printf("Starting application on port %v\n", portNumber)
    http.ListenAndServe(portNumber, nil)
}

Alright mister, you've got a lot of explaining to do! Wtf are these weird back ticks next to your struct fields? and why are all the fields in the struct capitalized?

Good questions!

The weird back ticks are an awesome feature of Golang. In this case we are using them to describe what we want the keys of our fields to be called when we serialize them to JSON. So Name becomes username. Now, we could have left it as a POGS ( Plain Old Go Struct ? ) , but then the JSON field would be name with a capitalized N, which really isn't the convention when displaying data in JSON format. But, then I guess we could have lowercased the Name field , and that would solve it right? ( forget for a moment that I actually changed name to username, it would have worked however you named it)

No, it wouldn't . If you're coming from Java, you know all about encapsulation. private String name you would proudly type, and the whole world would know that name is not to be touched unless it has a setter. Well, Go doesn't like verbosity. In fact, Go developers had the audacity to call Java a stuttery language. Person person = new Person() .. well, it does sound a bit like stuttering. Go does respect encapsulation though. Kind of, not as explicitly as Java, but it definitely doesn't rely on the whole we're all grownups rambling of Python developers. Because Go developers know that grownups are quite irresponsible, so it's better not to rely on them. How does Go take care of encapsulation? Easy, if it's capitalized it's not encapsulated ( I almost spelled encapitalized) . So Name as a field is available to the public, while name would not be. Besides exporting or restricting the use of functions and struct fields to different packages, it is extremely useful for filtering what fields to send to the client, and which not to. Besides for JSON, the back ticks are used for many other purposes, such as in ORMs like gorm , but that is definitely going to be an article of it's own.

Hope you enjoyed this article, thanks for reading!

An interface is a type in Go. But, unlike the struct type, the interface type is not concerned with state, but with behavior.

For example, a Dog struct would look like this:

type Dog struct {
    name     string
    age       int
    gender  string
    isHungry bool
}

A Dog interface on the other hand would look like this:

type Dog interface {
    barks()
    eats()
}

The struct shows us some attributes of a dog, but the interface describes what this dog is supposed to do.

Now, let's say we're writing an application about .. well... dogs! We'll have a lot of different breeds. We know that Go does not support inheritance like OOP languages do , so instead of naming the struct Dog, let's name it Labrador, and as our app grows, we'll probably add more breeds.

type Labrador struct {
    name     string
    age    int
    gender string
    isHungry bool
}

For the purpose of our app, we'll want to split these different dogs into two groups - big dogs and small dogs ( suppose we want to know how much food each group needs). We need a function that adds a dog (no matter the breed) , to a group:

func addToGroup(d Dog, group []Dog) []Dog {
    group = append(group, d)
    return group
}

This function is basically just a wrapper to the built-in append function, but for the sake of simplicity let's assume it's some super complex algorithm.

Notice that the addToGroup function only accepts the Dog interface, and a slice of Dogs. Nowhere is the Labrador type mentioned. But, what if we want to add a Labrador named Max to a group called Big dogs? How will the Go compiler know that Labs are dogs?

Easy, Golang asynchronously googles " are labs dogs? " , and then based on that answer it knows. On the odd occasion that Google is down, it goes to Wikipedia. Just make sure you have an internet connection or it will not know.

Ok, probably no one laughed.

In all seriousness though, the Go compiler will know that the Labrador type implements the Dog interface (and thus gains access to all functions that accept a Dog interface) only if the Labrador type implements the methods described in the Dog interface.

In Java, it's a bit more explicit. You would type class Labrador implements Dog and that would already indicate what you are doing. You would have to implement the methods also, but in Golang you only implement the methods, and implicitly your Lab becomes a Dog.

So let's implement the barks() and eats() methods so that the Go compiler will know what a Labrador is:

func (l Labrador) barks() {
    fmt.Println(l.name + " says woof")
}

func (l Labrador) eats() {
    if l.isHungry {
        fmt.Println(l.name + " is eating. Since he is a labrador, give him xxx brand of food.")
    } else {
        fmt.Println(l.name + " already ate. Come back later.")
    }
}

Not really intelligent business logic, I admit, but as you know tutorials tend to keep it as simple as possible.

Now that the Labrador struct implements both methods specified in the Dog interface, it has access to all functions that accept type Dog as an argument.

Let's see some output in our terminal by adding all of this to our main function:

func main() {

    bigDogs := []Dog{}
    max := Labrador{
        name:     "Max",
        age:      5,
        gender:   "Male",
        isHungry: true,
    }

    max.barks()
    max.eats()
    fmt.Println("Our group of big dogs:", bigDogs)
    bigDogs = addToGroup(max, bigDogs)
    fmt.Println("Our group of big dogs now:", bigDogs)
}

We first created a slice of Dogs called bigDogs where we will store all of our big dogs . Then we create a Labrador called Max. We call the barks() and eats() methods just to see that everything works (and also to feed poor Max, since his isHungry attribute is always set to true) .

It works, so let's add Max to our group of big dogs. Had he been a Chihuahua, he probably wouldn't fit in.

As we see , the addToGroup function gladly accepts Max the Lab, since it is clear to the Go compiler that Max is a Lab , and a Lab is a Dog.

But, this is just a toy example. Where does all this actually get used in production code?

Literally everywhere.

For example, the io.Reader and io.Writer interfaces are used all the time. Whenever some type is used for reading some data (wherever it may come from), odds are it is implementing the io.Reader interface. If it is writing somewhere (to standard out, to a file etc.) , it is most likely implementing the io.Writer interface.

They are actually pretty simple to implement. Here is the io.Reader interface:

type Writer interface {
    Write(p []byte) (n int, err error)
}

That's it. Any type that wants access to the functions that accept io.Reader as an argument (and there are quite a few), just needs to implement the Write method. Now, this doesn't mean that this implementation will necessarily be good. Interfaces work in a garbage in , garbage out manner, so if you implement the Write method poorly, you won't get the behavior you're expecting.

Another thing to consider is that in order to implement an interface, the methods must have the exact same signature as described in the interface. If your Write method does not accept a byte slice and return an integer and an error, you didn't do it right.

It's also worth mentioning that you can embed interfaces also. Get a load of this:

type ReadWriter interface {
    Reader
    Writer
}

The ReadWriter interface implements both the Reader and the Writer interfaces, meaning any type that wants access to functions that take ReadWriter as an argument must implement all methods from the Reader and from the Writer interfaces (which are a total of only two methods, luckily) .

Finally, I want to talk about the empty interface. Let's say you wan't to use a hashmap, but you want to use various data types for the map's values. Since the hashmap is statically typed, you need to give it some type, so that would probably disable you from using more than one type. This is where the empty interface comes in.

An empty interface doesn't implement any behavior, so basically any data type satisfies that, just by merely existing.

It's kind of a hack tbh, but it can come handy sometimes, and it helps developers who are migrating from loosely typed languages like Python and JavaScript.

You would define your map like this:

maxMap := map[string]interface{}{}

The two curly braces at the end look a bit strange , right? The first one belongs to the empty interface, and the second instantiates the map.

For better readability, you can make use of the make function:

maxMap := make(map[string]interface{})

For even better readability , you can create your own type, which will basically just implement the empty interface:

type Any interface{}

maxMap := map[string]Any{}

And now we can assign different data types as the values of our map, without the Go compiler being in a nasty mood:

maxMap["name"] = "some name"
maxMap["age"] = 5
maxMap["gender"] = "Male"
maxMap["isHungry"] = true

fmt.Println(maxMap)

I personally thought all of this interface logic was really confusing and unnecessarily complex at first (especially coming from Java, where interfaces are more explicit) , but it actually makes sense after time.

The good thing is that you probably won't be writing a lot of your own interfaces, at least not for most day to day features.

But, it is something you definitely need to know, as it will be appearing all the time in code that you use from modules in the standard library. Just look at the http module . It's flooded with interfaces. Understanding them will help you in debugging a lot.

That's all folks, thanks for reading!

What is a goroutine?

A Goroutine is essentially a very lightweight substitute for a thread. If you are coming from Java, you will probably know that a single Java thread allocates 1MB of memory by default. On the other hand, a singe goroutine allocates only 2kb (!) . It can dynamically add more memory, but it will not waste it.

How to implement a goroutine

Now let's look at some code. Let's say I wan't to access a third party API to get some information. I need quite a bit of info, and I need it fast. Knowing that most of the time it takes to retrieve data from a simple HTTP request is spent waiting for the remote server to respond, I decide to use concurrency.

To make things simple , I will go step by step and first do it the synchronous way. First I need a function that sends an API call and returns the request body:

func getData(url string) string {
    r, err := http.Get(url)
    if err != nil {
        log.Fatal(err)
    }
    defer r.Body.Close()
    body, err := ioutil.ReadAll(r.Body)
    if err != nil {
        log.Fatal(err)
    }
    return string(body)
}

As we know the request , being a network call, can go wrong so I check for any errors. I also call defer r.Body.Close() because that way we tell this function to close the request body after it is finished with it, same way we would close a file after reading it's content.

Finally, we assign a body variable the value returned from a call to the ioutil.ReadAll function, which takes a parameter that implements the io.Reader interface ( one that is implemented quite often in Go ) , and returns a byte array, which we can easily convert to a string afterwards.

Now let's call this function in our main function. I will use my favorite API , the Rick and Morty API, which I use in all of my examples ( luckily, not very many people implement the code from my articles, or this API server would be down 24/7) :

func main() {

    r := getData("https://rickandmortyapi.com/api/character/100")
    fmt.Println(r)

}

So great, we got some info on character 100, who's name is very fortunate - "Bubonic Plague" . Nice. But, we actually need info on all of the Rick and Morty characters , not just Mr.Plague. And we don't want to wait tens or hundreds of seconds do get it, we need it now! Goroutines to the rescue :

func getDataFaster(url string, c chan string) {
    r, err := http.Get(url)
    if err != nil {
        log.Fatal(err)
    }
    defer r.Body.Close()
    body, err := ioutil.ReadAll(r.Body)
    if err != nil {
        log.Fatal(err)
    }
    c <- string(body)
}

Whoa! That's not the syntax you expected , right? I mean , wtf is this arrow doing? And what is a chan?

In order for me to explain let me show you the version you expected, and how we would call it in the main function ( spoiler alert : it will not work as expected ) :

func main() {

    for i := 1; i < 200; i++ {
        go getDataFaster("https://rickandmortyapi.com/api/character/" + strconv.Itoa(i))

    }
}

func getDataFaster(url string) {
    r, err := http.Get(url)
    if err != nil {
        log.Fatal(err)
    }
    defer r.Body.Close()
    body, err := ioutil.ReadAll(r.Body)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(string(body))
}

For now we modified the getDataFaster function only to print the result, and not return it. I'll explain why later. We also use a for loop to get all 200 characters ( there's actually more but we really don't want to spam it so much) . Since i is an integer, we will use the strconv built in module to convert it to a string. Now, here's the cool part. We use the go keyword to tell the go compiler that we want this function to run asynchronously, meaning run so fast it seems all 200 function calls are running simultaneously. Unfortunately, when we run this, we find that it does nothing.

Well, now is about the time to leave a F U in the comments below.

Just kidding.

The reason this doesn't return anything is because the main function is essentially a goroutine of it's own, and it just went through the for loop and exited. It doesn't care that the other 200 goroutines haven't finished their job. It finished it's job and now wants to have a beer.

Enter channels!

Remember that bit of ugly code with the arrow and chan. Those are channels. A channel is essentially a place to store some value from our goroutine and enable another goroutine (our main function in this case) to get that value. That arrow at the end basically says - instead of returning the string(body) like you would in a regular function, jam it in a channel because this is no regular function, it's asynchronous.

Ok, but how does the main function then access these values you ask? Let's see in the next code snippet:

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
    "strconv"
)

func main() {

    ch := make(chan string)
    var data []string
    for i := 1; i < 200; i++ {
        go getDataFaster("https://rickandmortyapi.com/api/character/"+strconv.Itoa(i), ch)
        data = append(data, <-ch)
    }
    fmt.Println(data)

}

func getDataFaster(url string, c chan string) {
    r, err := http.Get(url)
    if err != nil {
        log.Fatal(err)
    }
    defer r.Body.Close()
    body, err := ioutil.ReadAll(r.Body)
    if err != nil {
        log.Fatal(err)
    }
    c <- string(body)
}

Btw, this code includes all of the package and import declarations for folks who are just here for the copy/paste-ing .

As you can see, the first thing we do is declare a channel by using the built-in make function. A channel also needs to be statically typed , so we declare a channel that will hold only strings. Next, we declare a slice of strings called data where we plan to store all this info on all these wacky Rick and Morty characters. We enter our for loop as before, but now we have this weird arrow again. This time the channel isn't the one that is on the receiving side , but rather seems to be the one that is sending . What we're doing here is appending the value that the channel will hold for us to our data slice.

This way we are initiating a blocking operation. This means that the main function will block until a value is actually gotten from the channel. This is how we make the main function wait , instead of carelessly exiting like it did the first time.

This is also the reason why we can't assign a value to a call to a goroutine ( I said I would explain later) , because it is asynchronous, and it will not return any value, it can only add it to a channel.

Finally, we print everything to the console, and since it's fetching 200 results , your console will probably blow up like mine:

So there it is. A very elegant way of retrieving a lot of data very quickly by using goroutines and channels.

Hope you enjoyed. Thanks for reading!

If you're building a web service , for example, a lot of the user input is going to be some type of text, and it will be passed either in the request body, the query string , or perhaps in the request headers.

So, working with strings is one of the most important parts of the job.

When working with strings in Go, for most of the operations you will need a module that is part of the Go standard library, and it is called - well, strings ( I like it when things are obvious) .

So let's look at some code snippets and explain what they do along the way:

package main

import (
    "fmt"
    "strings"
)

func main() {

    fruits := "apple,orange,kiwi,peach"
    fruitSlice := strings.Split(fruits, ",")
    fmt.Println(fruitSlice)
}

This one should be pretty straightforward. Like every Go file, we start by specifying the package name and defining what we will import. Since we plan to run this file as an executable, we will put it in the main package, and define the main function.

I created a string called fruits, but I need it to be a slice. With the use of the strings module, a simple call of the Split function gives me the result I need.

Next, I want to see what my fruit string will look with all of the letters capitalized:

capitalized := strings.ToUpper(fruits)
fmt.Println(capitalized)

Pretty easy. By now you've realized that the main difference between string manipulation in Go and an object oriented language like Python is that in Python we would call the split method directly on the string object e.g fruits.split(',')

But, since Go is not an OOP language, you pass the string as a function parameter . It's basically just a different approach, but the result is quite similar. The function names are also pretty similar to ones that we know from manipulating strings in Python , JavaScript and other popular languages.

Let's look at a couple of more examples that are common for working with strings.

Here we want to replace all occurrences of the word "Bucks" with the word "Lakers" ( my apologies to Bucks fans) .

sentence := "The Bucks are the NBA champions. Go Bucks !"
newSentence := strings.ReplaceAll(sentence, "Bucks", "Lakers")
fmt.Println(newSentence)

In the next one we are trimming the white space of a string, which is really useful when comparing two strings. I would always suggest trimming strings when comparing them, especially if the strings that are being compared are the result of splitting a larger string in to a slice of strings. I have witnessed a number of bugs in applications that were caused due to not trimming strings before comparing them.

    // lets compare the equality of two strings:
    whiteSpacedSentence := "   Hello World   "
    regularSentence := "Hello World"
    if whiteSpacedSentence == regularSentence {
        fmt.Println("they're the same")
    } else {
        fmt.Println("they're NOT the same")
    }
    // now let's trim the first string:
    trimmedSentence := strings.TrimSpace(whiteSpacedSentence)
    if trimmedSentence == regularSentence {
        fmt.Println("they're the same")
    } else {
        fmt.Println("they're NOT the same")
    }

One last operation that I would like to mention concerned with strings is the conversion of different data types to strings. In Go, there are two approaches.

The first looks like this:

byteSlice := []byte{72, 101, 108, 108, 111}
stringFromBytes := string(byteSlice)
fmt.Println(stringFromBytes)

Here we have a byte slice containing some numbers and when you convert it to a string type you get a word that is used in english for greeting people. The numbers represent what the characters are in ASCII encoding when converted to bytes.

However, if you try this on an integer, the Go compiler will have an unpleasant message for you, in the manner of conversion from int to string yields a string of one rune, not a string of digits .

Basically it is telling us that it will not convert the integer to a string , but rather to a rune, which is basically going to be its ASCII value. We don't want that, we just want a string , plain and simple.

Luckily, the Go standard library has a module that will solve this issue easily. It's called strconv, and the function is called Itoa ( I know, they're not very descriptive, but remember the creators of Go were inspired in part by C and that's what it was called in C ) .

Here's the code:

num := 38
numToString := strconv.Itoa(num)
fmt.Println(numToString)

That's it for this article. In the next articles I plan to write about more modules from the Go standard library that are essential for developing real applications.

Thanks for reading!

“ Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).

Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.”

Technically, Go implements some object oriented functionality (e.g interfaces, polymorphism) , but it doesn’t actually implement objects .

What?? You mean a language built in the 21st century, that is gaining so much popularity is not really object oriented?

Yes. However, it does implement something similar, so don't worry. If you come from an OOP language like Java or Python, it won't take long before you're comfortable with Go.

The creators of Go wanted to keep things as simple as possible, and inheritance and polymorphism do tend to complicate matters from time to time.

They didn't really come up with anything new to be honest. They took a concept that is pretty old and modified it a bit.

Structs

Anyone who ever programmed in C has probably heard of structs. But if you're coming from JavaScript, Python or even Java , you probably haven't.

Structs are simmilar to classes, except they don't have methods, and you can't extend them. Then again, they kind of do have methods.. and you kind of can extend them. Ok, before you start cursing and leaving negative comments, time do demonstrate what I mean.

A typical struct is written like this :

type Animal struct {

    latinName string
    continentOfOrigin string
    isExtinct bool

}

Looks a bit familiar? When we define a class in Java, we use a similar syntax, no? Except instead of the type Animal struct we would say class Animal . string and bool are obviously the data types, since we know that Go is a statically typed language.

Now, I said that Go structs don't have methods, but then I sort of changed my mind. Well, here's the Go way of writing a "method" :

func (a Animal) hasLongName() bool {
    if len(a.latinName) > 10 {
        return true
    }
    return false
}

Let me elaborate on the above code snippet. The first keyword func is the way we define any function in Go (think def in Python) . Now this (a Animal) is interesting. It is the function receiver . If a function has a receiver, then it is sort of like a method would be in an OOP language. hasLongName is the name of the function and bool is what data type it will return. A receiver function means we can do something like this:

func main() {

    a := Animal{"Canis familiaris", "Europe", false}
    fmt.Println(a.hasLongName()) 
}

Notice how we use the dot operator , like we would in any OOP language when calling a method? That surely makes things a bit more familiar to Java or Python. Also, notice how we instantiate the struct with the curly braces. In an OOP language, we would probably use paretheses. No new keyword either, but if you're coming from Python you're used to this.

Anyway, this hopefully explains the whole "Go doesn't have methods, but actually it does" ordeal I was rambling about before.

Now, I also said that there is no inheritance, and that is absolutely true. But , there is something similar. It's called composition, and it's also nothing new. Java has a number of design patterns depending directly on this concept. Basically, it's something like this:

// first let's define the Dog struct
type Dog struct {
    Animal
    name   string
    gender string
    size   string
}

// now let's instantiate it in the main function
func main(){
     d := Dog{Animal: Animal{"Canis", "Europe", false}, name: "Fluffy", gender: "Male", size: "Small"}
//(By the way, notice how you can also define a struct with colons ,like here)
    fmt.Println(d.isExtinct)
    fmt.Println(d.name)
    fmt.Println(d.hasLongName())
}

So, what I did was instead of saying something like Dog extends Animal like you would see in Java, I just added Animal as a field , and the Dog type now sort of inherited all of it's fields. This looks relatively simple, right?

There's one thing I would like to stress here. It has to do with a topic I will cover in a separate article, but I feel I should mention it here. The reason is, since you saw how easy it is to write a receiver function, you might be inclined to start writing your own and maybe you'll try something like this:

func (d Dog) changeSize(newSize string) {
    d.size = newSize
}


d := Dog{Animal: Animal{"Canis", "Europe", false}, name: "Fluffy", gender: "Male", size: "Small"}
d.changeSize("Medium")
fmt.Println(d.size)

If you're using a good text editor, it will probably already ask you wtf you are doing. If not, I'll tell you - this snippet of code will not work as intended.

You see, Go is a pass by value language, as opposed to most popular languages you are probably used to which are mostly pass by reference. This means that the d Dog is not going to be good ol' Fluffy that we instantiated a few lines above. It's going to be a new Dog, a sort of clone of Fluffy, but our original Fluffy won't really care.

So how do we actually acknowledge that our original Fluffy has gained a few pounds and is now a medium puppy?

Enter pointers.

Now, like I said, it is a topic that is probably one of the most complex to understand in Go (once again, if you are coming from C, you are probably laughing at me) . So, I won't go into too much detail but for now I'll just share this code and try to explain a bit:

func (d *Dog) changeSize(newSize string) {
    d.size = newSize
}


d := Dog{Animal: Animal{"Canis", "Europe", false}, name: "Fluffy", gender: "Male", size: "Small"}
d.changeSize("Medium")
fmt.Println(d.size)

If you are saying to yourself: "This looks an awful lot like the code that didn't work. " Yes, you are right. Except for the * in front of Dog. Basically it is telling the function that you want to access the values of that particular Dog. Not any clone , but the real Fluffy. For now, it is good to remember it like that. For the future, it is best to wait for my article on pointers, or better yet you can google it now and find a lot of quality articles and videos on the subject .

I hope this clears up as to why Go is not an object oriented language, but also why it isn't that hard to transition from OOP classes to Go structs.

Thanks for reading, and see you in the next one!

I’d like to go over some syntax that you will find in the Go programming language, that you probably won’t see in other popular languages.

1. Implicit type declaration

Since Go is statically typed, you need to declare the type of the variable when defining it. So, if you want to create a variable called city of type string with the value "Miami", you write:

var city string = "Miami"

Pretty simple right? But , when reading Go code, you usually won't see it like this. What you will see more often is :

city := "Miami"

The := operator (also known in Python as the walrus operator) is used for type inference so that you don't have to declare the type, since it is pretty obvious from it's value that it is a string.

This isn't something Go has invented. Java and C# have implemented this long ago, but instead of using := , they both use the var keyword. This way of using type inference is pretty unique.

2. For loops used instead of while

This looks kind of weird the first time you see it. Let's say you need an endless loop . In most programming languages you would write something like : while true { ... } . Not in Go however. Go actually doesn't even recognize the while keyword. The reason for this is that the creators of Go really wanted to keep it as minimal as possible . As a result, Go has only 25 keywords ( Java has 61 ) .

So how do you create an endless loop in Go? One word - for . Want your terminal to write "Hello" endlessly? ( obviously not the cleverest reason for using and endless loop ) Here's the syntax :

for {
        fmt.Println("Hello")
    }

When you think about it, for is predominantly used for iterating over collections, someting you will be doing a lot as a developer. while however, is usually used much less often, so why not just merge the two keywords into one.

3. Error handling

You are writing a program that needs to call a third party API. You are aware that your program now depends not only on your code, but on some server god knows where being maintained by god knows who. To make sure your app doesn't crash, you'd better put the code that sends the HTTP request in a try/catch block (or try/except for my fellow Pythonistas) . Well, Golang is not going to be cooperative about that.

You see, there is no try/catch in Go.

Wait, so Go apps crash all the time, right?

Nope.

Go has (like many languages) the possibility of returning multiple values from a function call. Instead of writing try/catch , Go enables the developer to check if one of the returned values is an error. Let's see how this looks in practice:

resp, err := http.Get("https://someExternalApi.com")
if err != nil {
   log.Fatalln(err)
}

You will be seeing a whole lot of this in Go. I remember when I first saw a large Go code base, it was full of these if err !=nil snippets. It felt like literally 80% of the code. Well, that's how you handle errors in Go. And, it's really useful, because it forces you to check for errors.

Forces me? What are you talking about?

If you don't believe me try this:

resp := http.Get("https://someExternalApi.com")

The Go compiler will refuse to run it. The http.Get method retuns two values , the latter being the error. If you don't define two values, the compiler will say someting like : cannot initialize 1 variables with 2 values

Ok, so what? You will define the error , but how does that force you to actually do anything with it? Well, in Golang, defining a variable and not using it is impossible.

If you write :

resp,err := http.Get("https://someExternalApi.com")
fmt.Println(resp.Status) // this will just print out the response status code

the compiler will say : err declared but not used

The reason for this is that the Go compiler is incredibly pragmatic. It doesn't like monkey business like unused imports or variables, because these will make the compiler seem slow and the binaries that it produces will seem bloated. The speed at which the Go compiler produces it's lean binaries is truly a thing of beauty.

Now, if you are really stubborn, and just don't want to handle the damn error, you can do something like this:

resp, _ := http.Get("https://someExternalApi.com")
fmt.Println(resp.Status)

The _ character tells the compiler that you are aware that this function returns two values but you only want to use the first one. At this point the compiler gives up on lecturing you about error handling, but when your app crashes , at least you can't say that it didn't do it's best to warn you.

4. The gorountine

Goroutines are a topic that deserve it's own article, which I will definitely be writing in the future. For now, I just want you to get acquainted with the syntax so you don't get confused when you see it.

Let's say we are going to be calling a lot of different external APIs in our app. Logically, we want to wrap the above code in a function, so we don't need to rewrite every line for every API call. Let's do that first:

func getApiResponse(url string) {
    resp, err := http.Get(url)
    if err != nil {
        log.Fatal(err)  // notice how I'm being responsible about error handling :)
    }
    fmt.Println(resp.Status) 
}

Great. But, wait. My app sometimes needs to send 500 API calls to get some information. How do I do this. Maybe this? :

urls := []string{"url1","url2","url3"} //this is a slice of strings containing all the urls
for _, url := range urls { 
        getApiResponse(url)
        }

( here I am using _ because the first return value of the range is an index, which I really do not need )

Well this would be ok , right?

Well, not really. The problem with this approach is that the requests will be sent synchronously , meaning one after the other. This can take quite a while. What you want is a way to send them concurrently. Enter gorountines. Like I said , explaining goroutines in detail will go into it's own article, but for now here is the syntax:

urls := []string{"url1","url2","url3"} 
for _, url := range urls {
        go getApiResponse(url)
        }

That's it! You just add the go keyword if front of your function call, and watch the execution time drop enormously.

One thing to note if you actually run this snippet :

(actually two things - the first being that if you really want a response , enter valid urls instead of the "url1","url2" placeholders )

You won't actually see the response, because the main function will finish execution before to goroutines are done. This is where it gets a bit complex, and explaining it fully would require introducing the concept of channels . I won't do this right now, but if you really want to see a return value immediately you can do this:

urls := []string{"url1","url2","url3"}
for _, url := range urls { 
        go getApiResponse(url)
        time.Sleep(time.Millisecond * 100)
    }

This will make the main function wait for 100 milliseconds, thus giving the goroutine time to return the value before the main function exits. This usually isn't the way you would do it in a real app, but for the sake of simplicity , it will do for now.

That's all for this article, I hope you learned something new.

Thanks for reading, and see you in the next one!

For my first article I will keep it simple and brief, and just try to name a few reasons why I decided to start learning Go:

1. The first reason , to be completely honest , is driven by pure greed :) . I think Go is going to be truly dominant in the coming years, and the demand for Go developers is going to explode pretty soon. It was built for the 21st century, made to work great with 21st century technologies such as the Cloud and multi-core processors.

2. It compiles to a single binary that runs machine code. This means that to run a Go app, you do not need any interpreter or virtual machine intermediary like you do for Python or Java. This further means that when putting your Go app in a container, you can use the “Scratch” base image. The result is a very lean Docker image usually no larger than 20MBs . An average Python image is at least 10-15 times larger.

3. The compile time is ridiculously fast. I’ve never worked on a Java app that has hundreds of thousands of lines of code, but I hear that compiling it can take quite a while. Legend says that the Game room (which as we know almost all tech companies now have on prem )was invented because developers had nothing to do while waiting for their Java apps to compile. Another legend says that the creators of Go , wrote the entire language while waiting for their apps written in other languages to compile.

4. Speaking of the creators of Go, they are three of the most legendary members of the tech community, people that have been part of major projects that are still used even though they have been created around half a century ago. Ken Thompson, one of the creators, is the author of Unix , the operating system that inspired the creation of Linux, which is the OS that runs over 90% of all servers today. He also assisted the development of C , the mother of most modern programming languages. When you add the fact that Go is backed by Google, I think it is safe to say that everyone involved in it’s development knows what they’re doing.

5. Finally (and I know it’s a cliche) , the language is so damn simple. It’s small and if you take a 7-8 hour couse of it ( there is a number of good ones online) , you will be able to start building real apps pretty soon. As a Python developer, I like to keep it simple. Golang has the simplicity of Python , and the power of C . Software such as Kubernetes, Docker, CockroachDB and Terraform were made in Go .

I hope these reasons are compelling enough for you as they were for me.

In this blog I will document my leaning path , mostly because I think I will learn even better by sharing what I have discovered.

Thanks for reading, and I hope you will join me on this path!