Using only Go code in an application is what we call the pure-Go experience. A recent discussion about why Caddy does not use the industry standard libraries like GnuTLS or OpenSSL is interesting. The assumption was made that these libraries are more used are thus more secure than a Go implementation. The Caddy author responded with:
@Forza, Go’s TLS stack is widely accepted to be one of the best and most robust implementations in the world.
No, we absolutely will not be allowing Caddy to link to C code, especially for its TLS stack. Remember Heartbleed? That entire class of vulnerabilities is impossible with Go.
Go’s cryptography code was written by some of the most experienced cryptographers in the field. No code is perfect, but any weaknesses or bugs tend to be found and fixed quickly. If you have doubts about it you should raise an issue on the Go tracker.
I would 100% trust Go’s memory-safe implementation of TLS over an old C program any day. Especially with authors like Adam Langley and Filippo Valsorda, and with 10+ years of production experience on some of the busiest edge servers on the Internet (Google, Cloudflare, Netflix, etc).
you can easily cross compile to any target from any build machine.
blazing fast compile times
deployment is dead simple – zero dependencies. Docker is not needed.
you are not vulnerable to security issues in the host systems SSL/TLS libs. What you deploy is pretty much what you get.
although there is high quality code written in C/C++, it is much easier to write safe, reliable programs in Go, so I think long term there is much less risk using a Go implementation of about anything – especially if it is widely used.
Go’s network programming model is much simpler than about anything else. Simplicity == less bugs.
Once you link to C libs in your Go program, you forgo many of the benefits of Go. The Go authors made a brilliant choice when they chose to build Go from the ground up. Yes, you loose the ability to easily use some of the popular C libraries, but what you gain is many times more valuable.
This is Go’s ace in the hole that has lead it to become a poster child of the movement away from virtual machines and managed runtimes. Using cgo, you give that up.
In February, the Go 1.18 release will expand the new register-based calling convention to non-x86 architectures, bringing dramatic performance improvements with it.
Instead of relying on external tools like Git, tar, etc, go has many package equivalents:
The author also suggests that if you make a command line tool, also make it available as a library, so other apps can embed it. Again, sounds familiar.
Faster and smaller – great news – especially for edge devices!
Characteristics that are important for cloud servers (like efficiency, ease of deployment, portability, etc) often match up very well for what is needed at the edge. This is one reason why Linux and Go work so well for edge/embedded systems – they are highly optimized for servers where efficiency and portability matters. The middle ground of desktops is the realm of bloatware, and thus why very little of Microsoft’s technology has historically seen widespread use in servers or embedded systems.
2022 Go developer survey is out, generics seems to be well received. 85% do unit testing thats amazing number, perhaps power of go tooling and simplicity in using them. Fuzzer support seems cool. Increased desire for internal documentation server. And 93% of go software gets deployed on Linux !!
Go 1.24 has an interesting feature where you can specify tools in your go.mod file instead of having to install them separately. This is another step forward in having everything you need versioned and controlled in one place:
