4 ms·
Go is my primary programming language during the last 10 year. I absolutely love Go because of the following features: * Great code readability. I can open any
by valyala 6y ago
Go is my primary programming language during the last 10 year. I absolutely love Go because of the following features:
* Great code readability. I can open any project in Go and instantly start reading and understanding the code. This is because of simple syntax, which doesn't provide ability to write implicitly executed code, and `go fmt` tool, which formats everybody's code to a single code style.
* Go discourages unnecessary abstractions and encourages writing essential boring code without various "smart" tricks. The end result is much shorter code base, which is easy to read and refactor.
* Fast compile times. For instance, my latest project - VictoriaMetrics [1] - contains almost 600K lines of Go code excluding "_test.go" files. Go builds the final `victoria-metrics` executable in less than a second during development. This means that I can quickly iterate on code modifications and testing without the need to wait for minutes and hours for build process to finish (hello, Rust and C++ :) ).
* Single statically linked output binary with relatively small size. For example, VictoriaMetrics is built into 19MB statically linked binary with Go 1.15.4. And this binary contains all the debug symbols. Binary size shrinks to 12MB when stripping debug symbols. Such a binary can run on any host without the need to manage external dependencies - just upload the binary and run it.
* Ability to build executable for any supported target platform by specifying GOOS and GOARCH environment variables. For example, I can build binary for FreeBSD on ARM from my x86 laptop running Ubuntu.
* Great and easy-to-use tooling for race detection and CPU/memory/locks profiling. There tools significantly simplify code optimization and allow to catch data races at much lower mental cost comparing to race-free Rust :)
P.S. I hope Go will never adopt generics. I didn't need generics during the last 10 years of active development in Go [2]. Before Go I was working with C++ and was experiencing constant pain with reading and debugging C++ templates in stl and boost libraries. I don't want to experience the same feelings with Go.
[1] https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/
[2] https://github.com/valyala/ https://github.com/valyala/
- shiba_developer 6y agoYou're absolutely right. Generics especially in form of contracts would be a mess.
- kinjba11 6y ago> constant pain with reading and debugging C++ templates C++ templates are a nightmare agreed. What C++ does is just one way, a poor way, to implement generics. Please do not conflate generics with C++. If you've ever worked with C#, Java, TypeScript, or others you'll know that "generics" come in many different flavors. Some are quite nice. Generics are coming to Go ([https://www.gophercon.com/agenda/session/233094 https://www.gophercon.com/agenda/session/233094]). Slices, chans, maps, arrays are all generic in Go - and they are great! Stuff like the sync package (https://golang.org/pkg/sync/ https://golang.org/pkg/sync/) with interface{} all over? Not so great. Generics solves a real problem.
- valyala 6y agoIt would be great if generics could be used by a small team of professional Go developers who clearly understand strong and weak sides of generics. Unfortunately this is impossible in real world :( I predict that generics in Go will lead to much more poorly written hard to read and debug packages and apps.
- GordonS 6y agoAre you using an IDE? Coming from dotnet I'm kind of spoiled here, with both Visual Studio and Rider being excellent choices. They also bring things like a great debugging dev UX, and the possibility to change variable values and code during an active debugging session - is there anything like that for Go?