Languages that try to disallow idiocy become themselves idiotic.

—Rob Pike, one of the creators of the Go programming language

Many programming languages — such as C++ or Java, for example — introduce all kinds of complex abstractions that are intended to stop the person writing code in the language from doing something that they may not actually ever try to do.

In other words, the compiler and standard library are built around the idea that they’re always and inevitably going to be better than the programmer who uses them!

Golang takes a middle path: it offers just enough abstraction to keep us from needing to worry about low-level memory management or pointer arithmetic, but it doesn’t forbid us from accessing the bare metal of the machine, if that’s what we really want.

It even gives us a package named "unsafe", because the language accepts that sometimes we might just know best. That’s a pretty good philosophy.

Indeed, the "unsafe" package provides a way to access low-level operations that are not normally accessible through the standard language APIs.

These operations are considered unsafe because they bypass the languages type system, as well as skipping other safety checks that the Go compiler performs, which means that they can lead to undefined behaviour or crashes if not used properly.

The language’s focus on safety is one of the biggest benefits of writing Go code, but it comes with costs, so we shouldn’t be afraid to step outside of those bounds, but we should be hyperaware of the risks whenever we do so.