I'm now a few years into my journey as a programmer. As a bootcamp grad, I began my coding journey with web-development languages: HTML, CSS, JavaScript. Then, I branched out to Python for some extra backend flavor. Tinkering with these dynamically typed languages helped me grow immensely as a developer. They brought me from, well, zero to a full-time professional engineer. But recently, I had the opportunity to learn my first compiled language: Go.

The contrast between Go and the other languages I've worked with taught me some really valuable lessons.

To start, Go is a compiled language, which also means it is a statically typed language. When a Go application runs its build step, the compiler checks types at build time. If something is not right, the build will fail with an error message describing the issue, thereby blocking you from even deploying until certain bugs are fixed. This is in contrast to dynamically-typed languages, which perform type checking done at runtime rather than at build time.

Since dynamic languages don't catch a lot of bugs during the build process, this difference can make apps written in dynamic languages a bit (or a lot) less reliable and more prone to bugs. Though there are some workarounds (Typescript in Javascript; type hints in Python), the extent to which statically typed languages like Go require type declarations while you're writing the code makes life much easier. Refactoring is a relative breeze and much safer when the machine is checking your work. You don't get that without good typing.

The compiled nature of Go also means that it runs a step closer to the machine. There’s no need for an engine to interpret the code for your machine’s processor line-by-line at runtime. This makes for much faster and much more efficient computation than you would get from an interpreted language.

In addition to types, there are plenty more opinionated, idiomatic conventions that are designed to make developers’ lives easier when they come back to read the code. For example, Go does not throw errors. So, errors needs to either be checked and handled in every instance, or intentionally ignored with the conventional underscore. And that’s just scratching the surface. By being opinionated on conventions like this, Go strives to be boring. Boring code is synonymous to easier-to-understand, uncoupled, human-readable code. This must be worth something, because there’s a big community around Go, and plenty of resources available for new folks to learn how to get started with Go. Here are just a few resources:

• https://gobyexample.com/
• https://go.dev/, which includes a nifty Go playground
• The GO GitHub repository
• Tons o’ books (just google “Golang books”)

And, there’s so much more out there. The rabbit hole goes deep with this language… Go has idiomatic approaches to concepts like data structures, concurrency, routines, channels, and more. But, we’ll save the rest for another post!