Golang Impressions

I had previously started dabbling in C for work. C/C++ from a language standpoint isn’t the hardest thing in the world. But getting all the dependencies linked properly in a C/C++ environment is indeed the hardest thing in the world.

So we started using Golang. The performance is great, considering how high level the language is. It feels like a combination of C and ES6, considering it takes a more functional approach and doesn’t support classical OOP, yet it has a simple package/import system and built-in data structures like map and dynamically sized arrays (called “slices”).

Testing is built-in via the go test command, provided you’ve created some files that end with _test.go. A single independent binary is compiled via go build. Golang is very picky about where a project is located, often requiring you to place it in $GOPATH/src/github.com/myrepo/myproject. When you start using the go get and go install commands, it makes more sense.

Concurrency was one of the huge selling points for me. Golang doesn’t exactly let you create “threads” per se, but “goroutines” instead- which is a way of telling the compiler that the logic should be treated as a “threadable” subroutine. From there, the compiler decides exactly how to handle those cases. An object called a “channel” can be safely read and written to by goroutines. There are also atomic data types that help with thread-safe operations.

Ultimately, I’ve been spending less time on toolchains and more time building features. Golang truly is a modern systems language.

I would post some code, but there’s nothing syntactically spectacular about the language. Some of my early Golang study code can be found here: https://github.com/ryanbennettvoid/go-stuff

Leave a Reply

Be the First to Comment!