Go is a statically typed, compiled, imperative language with support for elements of functional and object oriented programming, its main language goals are readability, first class concurrency support, minimal build times, performance and runtime efficiency.

While readability is somewhat subjective, Go manages to achieve the rest of its goals. Go has seen success in building web services and tooling the most, some of the most notable projects built with Go include Docker, Kubernetes, Hugo, and CockroachDB.

This is an attempt at an unbiased evaluation, but it's still an opinion piece, I'm a backend developer, with Javascript and Python as my primary languages at the time when I first picked up Go. I mostly use Typescript and Go now.

Criteria

I already had an idea of what kind of language I needed to complement my tech stack, which helped narrow down my options.

Performant at CPU-heavy tasks
First class concurrency support
Compiles to native binary
Statically typed

This left me to pick between Rust and Go, I opted for Go for multiple reasons:

Lower learning curve, not only was it easier to learn, it would leave simpler legacy codebases behind me.
At the time when I made my choice, Rust's Async implementations didn't seem as mature as Go's (Built in language feature vs third party library at v.0.*).
A slightly larger job market for Go developers.

The neutral parts

Go is similar to C in syntax, it's an imperative language with some elements of other paradigms, Go supports functions as a first class value, but it does not support generics yet, This leaves you with the following:

func mapInt(arr []int, cb func(a int) int) []int {
    newArr := make([]int, len(arr))
    for i := range arr {
        newArr[i] = cb(arr[i])
    }
    return newArr
}

You're able to define higher order functions, but only for specific types, or alternatively, using an empty interface type, which leads to more verbose type casting code.

Go uses C-style Structs for objects, but you can define methods for structs. as well as embed struct types into each other, allowing for some inheritance.

type Human struct {
    name string
}

func (h Human) Greet() {
    fmt.Printf("my name is %v \n", h.name)
}

type Employee struct {
    Human
    salary int
}

func (e Employee) ShowSalary() {
    fmt.Printf("%v's salary is %v \n", e.name, e.salary)
}

func main() {
    employee := Employee{Human{"bob"}, 10} // you must assign an instance of the embedded struct
    employee.Greet()
    employee.ShowSalary()
}

Struct embedding isn't common, I have yet to need it, it seems more common with library code than user code, e.g with ORM models.

The bad parts

I prefer to start with the bad news, Go is quite opinionated, and would not be to the liking of many. Most opinions are language enforced rather than suggested practice.

Error handling

Errors in Go are values, there are no exceptions, with the exception of panics.

The default way of error handling is that functions return the error value as the last value, if the error is nil (null value), the function executed successfully.

val, err := doTheThing()
if err != nil {
    fmt.Fatalf("encountered an error: %v", err)
}
fmt.Println("received value: %v", val)

Go does not allow you to accidentally forget about methods that return an error

val := doTheThing() // compile error
val, _ := doTheThing()

You're free to explicitly ignore the error, but that means val is an empty value, if not a null pointer, and using a null pointer will cause a panic.

Error as value avoids the pitfalls of uncaught errors, without the strictness that declared exceptions like Java uses, exceptions also introduce a performance penalty. But Go does not attempt to solve the problem, it decided the solutions are not good enough, you're left to deal with every error manually.

Take for example, creating multiple SQL prepared statements. creating a prepared statement requires a network request to the DB, and the SQL statement to be correct, many things can go wrong.
Thus the function sql.DB.Prepare() can error out, But when you're preparing multiple statements the error handling will always be the same for each one.

conn := sql.Connect(connectionString)

selectAllUsers, err := conn.Prepare("SELECT * FROM users;")
if err != nil {
    fmt.Fatalf("error preparing statement: %v", err)
}
selectUserById, err := conn.Prepare("SELECT * FROM users WHER id = ?;")
if err != nil {
    fmt.Fatalf("error preparing statement: %v", err)
}
selectAllActiveUsers, err := conn.Prepare("SELECT * FROM users WHERE status = 'active';")
if err != nil {
    fmt.Fatalf("error preparing statement: %v", err)
}
updateUserStatus, err := conn.Prepare("UPDATE users SET status = ? WHERE id = ?;")
if err != nil {
    fmt.Fatalf("error preparing statement: %v", err)
}
deleteUser, err := conn.Prepare("DELETE FROM users WHERE id = ?;")
if err != nil {
    fmt.Fatalf("error preparing statement: %v", err)
}

The number of redundant error checks here increases proportionally with every SQL statement you require, there is however, a pattern you can use.

Whenever you have a number of methods that would lead to the same error handling, without any operations being taken between the calls, you can turn the operations into a struct type, one that defines all the operations, and handles error checking.

// this struct wraps over making prepared statements to the DB
struct sqlStatement struct {
    conn *sql.DB
    err  error
}
// a method on the sqlStatement struct to create prepared statements
func (s *sqlStatement) prepare(query string) *sql.Stmt {
    // make sure no error was found previously
    if s.err == nil {
        // set the struct's error value to the function's error result
        // if an error was encountered, stmt would be nil
        stmt, s.err := s.conn.Prepare(query)
        return stmt
    }
    return nil
}

statement := sqlStatement{conn}

selectAllUsers := statement.prepare("SELECT * FROM users;") // succeeded
selectUserById := statement.prepare("SELECT * FROM users WHER id = ?;") // error! sqlStatement.err was set to the error
selectAllActiveUsers := statement.prepare("SELECT * FROM users WHERE status = 'active';") // sqlStatement.err is not nil, do nothing
updateUserStatus := statement.prepare("UPDATE users SET status = ? WHERE id = ?;") // sqlStatement.err is not nil, do nothing
deleteUser := statement.prepare("DELETE FROM users WHERE id = ?;") // sqlStatement.err is not nil, do nothing

// first error we caught is preserved
if statement.err != nil {
    fmt.Fatalf("error preparing sql statements: %v", statement.err)
}

This pattern allows us to get rid of redundant error checking, but it's not perfect, first, you have to manually extract the operation into its own type.

Secondly, if you have to use the values returned by any of the operations, you would have to error check at that point again, e.g:

struct userApi struct {
    api *apiRepository
    err  error
}

func (a *apiQuery) query(id string) User {
    if s.err == nil {
        user, s.err := s.api.QueryUser(id)
        return user
    }
    return nil
}

func (q *apiQuery) update(id string, user User) {
    if a.err == nil {
        s.err := s.api.UpdateUser(id, user)
    }
}

api := userApi{apiConn}

// incorrect usage:
user := api.query(1) // errors out, api.err is set to error
if user.Status == "VIP" { // user is a nil value, because the query failed, this will cause a panic because we attempted to use a nil pointer (nil.Status)
    user.Balance += 100
    api.update(1, user)
}

// correct usage:
user := api.query(1)
if api.err != nil {
    fmt.Fatalf("error retrieving user: %v", api.err)
}
if user.Status == "VIP" { 
    user.Balance += 100
    api.update(1, user)
}

As you can see, if we rely on the value returned from any of those operations, we would have to error check again.

Go chooses maintenance and readability over writability in the case of error handling, preferring verbosity over unexpected control flow changes.

Type system limitations

Go's built in types include generics, maps map[KeyType]ValueType, slices []Type, channels chan Type, but user defined types can not include type parameters yet. Take for example a Box type:

type Box[T] struct {
    value T
}

func (b *Box) Store(item T) {
    b.value = item
}

func (b *Box) Retrieve() T {
    return b.value
}

intBox := Box[int]{}
intBox.Store(100)
var val int = intBox.Retrieve

We don't care what's stored or retrieved, until we actually use the Box, this isn't possible with Go yet, you'd have to use the empty interface type, interface{}.

type Box struct {
    value interface{}
}

func (b *Box) Store(item interface{}) {
    b.value = item
}

func (b *Box) Retrieve() interface{} {
    return b.value
}

intBox := Box{}
intBox.Store(100)
val, ok := intBox.Retrieve.(int)
if !ok {
    fmt.Fatalf("failed to cast box value to int")
}

This can quickly become a pain point when multiple possible types are used, you would require a type switch statement to check which type the value was, and if your function has to return the value, you'd have to return an empty interface again, and repeat the type assertions on the layer above.

Generally you'd avoid moving generic interface{} data between functions due to the redundant amount of type checks you'll have to perform when making any action on the data.

You can reduce the amount of clutter by type casting without checking for validity, this reduces the boilerplate but forgoes type safety, an unchecked failed type assertion is a panic during runtime.

type Car struct {
    price int
}

type Building struct {
    price int
}

x := Car{100}
var i interface{}
i = x
y := (i).(Building) // panic!

However, Go v1.18 is slated to introduce generics.

Another limitation is the lack of tuple types, despite functions practically being able to return tuple types, you're unable to replicate that elsewhere, for example in channels.

func results() (int, err) {
    return 10, nil
}

a, err := results() // works

resultsChannel := make(chan (int, error)) // parse error, expects only one type

a, err := <- resultsChannel // does not work

to group results together, you're forced to declare your own tuple type.


type intResult struct {
    result int
    err error
}

resultsChannel := make(chan intResult)

res := <- resultsChannel
a, err := res.result, res.err

Somewhat a minor inconvenience, and arguably solvable with Generics, but first class tuple types would've been more consistent with Go's error handling system.

The good parts

Now into the parts that Go does well

References and Values

In contrast to languages like javascript, java and python, Go allows you to choose whether you want to pass a value or a reference.

Passing a value would clone it, while passing a reference would pass a reference type that points to the memory block with the value, this is true for both primitives and struct types, with the exception of reference types like slices and maps.

for types, a type of int denotes an integer, *int denotes a reference to an integer, this the same for every type, e.g string, *string, Person, *Person,

func PureFunction(num int) {
    num += 10
    fmt.Println("Pure: ", num)
}
a := 10
PureFunction(a) // "Pure: 20"
PureFunction(a) // "Pure: 20"
PureFunction(a) // "Pure: 20"
fmt.Println(a) // 10

func MutatingFunction(num *int) {
    *num += 10
    fmt.Println("Mutate: ", *num)
}
b := 10
MutatingFunction(&b) // "Mutate: 20"
MutatingFunction(&b) // "Mutate: 30"
MutatingFunction(&b) // "Mutate: 40"
fmt.Println(b) // 40

This applies to structs too, You're able to define struct methods that either clone the method's struct, or mutate it

type Human struct {
    firstName string
    lastName  string
    age       int
}

func (h Human) NewKid(name string) Human {
    h.firstName = name
    h.age = 0
    return h
}

func (h *Human) AgeUp() {
    h.age += 1
}

bob := Human{"bob", "johnson", 32}
adam := bob.NewKid("adam")
fmt.Println(bob, adam) // {bob johnson 32} {adam johnson 0}
bob.AgeUp()
adam.AgeUp()
fmt.Println(bob, adam) // {bob johnson 33} {adam johnson 1}

Go allows for easy and efficient copying of structs, this allows for some very easy immutable and pure function code even with objects/structs, having clone by default means you can use the same struct in multiple functions without worrying if the state would mutate in an unpredictable way.

If your struct represents a value instead of an entity, prefer reassigning value over mutating state.

Concurrency

Go's concurrency model is based around goroutines, lightweight green threads controlled by the go runtime instead of the operating system.

Go is smart enough to know how to spread your goroutines between the available computer resources. You can have thousands of goroutines spread over any number of OS threads, with blocked goroutines making way for other hanging goroutines.

Cooperation between goroutines is done through channels or shared memory space.

Let's take for example the following function:

func filterBadFruit(fruits []Fruit) ([]Fruit, error) {
    cleanFruit := make([]Fruit, len(fruits))
    for index, fruit := range fruits {
        if fruit.IsHealthy() {
            cleanFruit[index] = fruit
        }
    }
    if len(cleanFruit) < 1 {
        return nil, errors.New("no healthy fruit found!")
    }
    return cleanFruit, nil
} 

goodApples, err := filterBadFruit(mixedBag)
if err != nil {
    fmt.Fatal(err)
}
sendToCustomer(goodApples)

Filtering the bad apples is a compute-bound operation, we have to iterate over all the elements and conditionally perform operations. let's assume we have another call for filtering bad oranges.

goodApples, err := filterBadFruit(mixedAppleBag)
if err != nil {
    fmt.Fatal(err)
}
goodOranges, err := filterBadFruit(mixedOrangeBag)
if err != nil {
    fmt.Fatal(err)
}

Here we would have to filter all the apples first, and then filter all of the oranges, we can split the workload into another goroutine, Go's runtime would handle splitting the goroutines over the OS's threads, allowing for parallel execution.

To spawn a new go routine we use the go keyword before a function call.

goodApples, err := go filterBadFruit(mixedAppleBag)
if err != nil {
    fmt.Fatal(err)
}
goodOranges, err := go filterBadFruit(mixedOrangeBag)
if err != nil {
    fmt.Fatal(err)
}

This would not work, and the compiler will complain about this too. once a goroutine is started, it's no longer connected to the goroutine it started from, you can't expect it to return values like normal.

As mentioned earlier to have goroutines communicate, we either use shared memory or channels. We'll attempt to use shared memory first.

func filterBadFruits(fruits []Fruit, results *[]Fruit){
    cleanFruits := make([]Fruit, len(Fruits))
    for index, fruit := range fruits {
        if fruit.isHealthy() {
            cleanFruits[index] = fruit
        }
    }
    if len(cleanFruits) < 1 {
        results = nil
    }
    *results = cleanFruits
} 

// Apple and Orange struct types fulfill the Fruit interface
var goodApples []Apple
var goodOranges []Orange
go filterBadFruits(mixedAppleBag, &goodApples)
go filterBadFruits(mixedOrangeBag, &goodOranges)
if goodApples == nil {
    fmt.Fatal("no good apples were found!")
}
if goodOranges == nil {
    fmt.Fatal("no good oranges were found!")
}
go sendToCustomer(goodApples)
go sendToCustomer(goodOranges)

Here we changed our filtering function to take a reference, where we store the results, references can be shared safely between goroutines as long as they're only read. But we have multiple problems here.

Firstly, we're writing and reading from the same reference without any synchronization, this can lead to undefined behavior.

Secondly, related to the first point, we read the results before making sure the two functions are finished, remember if goodApples == nil is executed by another goroutine, it has no reason to block and wait for filterBadFruits to finish executing before checking if it's nil, in this case, we will always find goodApples == nil to be true, and crash, because filterBadFruits takes way more time than a single check.

Thirdly, we have no way of sending errors encountered back to the main goroutine, we were able to circumvent this issue here since we only had one error case, which we represented
with the nil value, not a good idea.

Had you ran this code, and got the panic error no good apples were found!, you'd assume you somehow have a problem with the apples supply, not that you have incorrect concurrent code.
We can send another pointer for errors, but this doesn't solve our first two issues.

One solution here is channels, a channel is a built in Go type chan Type, you can use it to send values channel <- value or receive values value := <- channel.

There's two types of channels, non-buffered and buffered channels, non-buffered channels will stop your code on both send and receive lines, until another goroutine sends or receives back.

meaning your code will stop at value := <- channel until another goroutine passes a value with channel <- value, and vice versa, you're unable to send until another goroutine accepts your message.

As for buffered channels, you can define a buffer size, allowing you to send without waiting, but receiving is still a blocking operation, and if the buffer size is reached, sends are blocked as usual.

For our use case here, any would work.

func filterBadFruits(fruits []Fruit, results *[]Fruit, errChan chan error){
    cleanFruit := make([]Fruit, len(fruits))
    for index, fruit := range fruits {
        if fruit.IsHealthy() {
            cleanFruit[index] = fruit
        }
    }
    if len(cleanFruit) < 1 {
        errChan <- errors.New("no healthy fruit found!")
    }
    *results = cleanFruit
    errChan <- nil
} 

var goodApples []Apple
var goodOranges []Orange

appleError, orangeError := make(chan error), make(chan error)

go filterBadFruits(mixedAppleBag, &goodApples, appleError)
go filterBadFruits(mixedOrangeBag, &goodOranges, orangeError)

err := <- appleError
if err != nil {
    fmt.Fatalf("error getting apples: %v", err)
}
go sendToCustomer(goodApples)

err = <- orangeError
if err != nil {
    fmt.Fatalf("error getting oranges: %v", err)
}
go sendToCustomer(goodOranges)

The difference here is that the main goroutine will block and wait at err := <- appleError, while the two filterBadFruits goroutines continue their work.

once the apple filtering goroutine finishes and responds, either with an error or with nil, meaning no error, we can access the goodApples result safely, because know the other routine finished its work and it wouldn't possibly write to it again. The same is repeated with the orange results.

That is just one example of concurrency patterns in Go, for example, if your goroutines return multiple results at different times, it's better to use a channel for results too.

Another thing to note is that, in this case, our goroutines were handling compute-bound workloads, running this code on a single threaded machine wouldn't bear any useful results.

That said, it would still work as intended. If your goroutines were handling IO-bound workloads, you would still benefit from goroutines, as blocked goroutines are replaced by the runtime, meaning you can run multiple concurrent network or file system requests on a single thread, akin to Nodejs's Promise.all/allSettled.

While Go makes concurrency easier, it doesn't make it easy, concurrent programming is a non trivial problem.

Standard Library

Go has a very comprehensive standard library, and defines multiple standards, including the SQL and HTTP APIs.

Go's database/sql package defines a standard way to interact with SQL databases, the only dependency being the driver, this is similar to Java's JDBC and C# SQL packages, although it can be quite verbose, third party libraries like sqlx and sqlc provide ways to abstract away the redundancy of the standard API without breaking compatibility.

The same holds true for the net/http package, which provides both client and server implementations. The server implementation is quite comprehensive compared to the default HTTP server implementations I've tried in Nodejs and Java, net/http provides multiple conveniences out of the box like parsing of query parameters, and multipart/url-encoded request bodies.

While it also suffers from the same verbosity problem, it's considerably more serviceable than the average language http server implementation, and it's a very likely solution to opt to only use the default net/http package for creating APIs and websites.

Go also comes with well rounded templating libraries, one for general text, and the other for generating HTML, the latter works well with the net/http package for creating server side rendered web apps.

Overall, the Go standard library makes it possible to build entire applications with the bare minimum dependencies, without relying on frameworks.

This is often the general opinion online, people will shun framework usage, but I would personally suggest to use frameworks when you feel the need arises, a framework where it's not really justified is not as bad as incorrectly implemented abstractions over the standard library.

Language Tooling

The language tooling provided by the language out of the box is great, and covers many aspects.

gofmt is the default go formatter, having a language style ensures a uniform style between codebases, and adds to readability, it may not be to everyone's liking, but a set standard has more positives than negatives IMO.

The language server gopls has improved a lot in recent times, and it provides a very good user experience out of the box with VS Code, auto imports, auto completion of function arguments based on type inference, instant formatting on save, the debugger and break points also work out of the box without any configuration.

Go also provides a test runner built into the go toolchain, files postfixed with _test.go and functions prefixed with Test and take a *testing.T parameter are ran with the go test command, while the standard library doesn't offer comprehensive assertion functionality, you can easily create some with the reflect library. Go allows for comprehensive testing without any third party libraries.

Go also offers other build tools, including built in race condition checking and benchmarking.

Conclusion

Go chooses not to be a flexible language, and that is by design, for the sake of build speeds and readability/clarity, they took a very opinionated route.

The more you try to bend the language to your own mold the more disappointed you will become, the best option is to accept the Go's opinions, at least while you're writing Go code, I believe the positives of Go outweigh its shortcomings, but that's a subjective take that depends on how much of Go's opinions go against your own.