Less is exponentially more (2012)

It's interesting the things that people think are essential and the things they are willing to put up with. I'm willing to put up with writing my own sort.Interface, adding in a few lines of boilerplate for error handling, loops, and the odd linked-list/btree/etc. I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc. I'm willing but very reluctant to use a language that requires me to write a bunch of scripts to automate publishing source code and documentation packages. I'm willing but very reluctant to use a language with minutes-long build times. I'm willing but very reluctant to use a language that where most packages are poorly documented, lacking even basic type information (looking at you, Python and JS). I'm willing but very reluctant to use a language in which the ecosystem is an absolute mess due to the pervasive use of inheritance. I'm unwilling to use a language that simply can't be optimized (and "just write it in C" or "just use multiprocessing" are only applicable to a narrow range of bottlenecks--good luck processing a large Python data structure, for example).

This isn't Go fanboyism; I've worked with lots of languages in my career, and I still get really excited and try new languages all the time, but they all tend to optimize for nice-to-have things (such as a type system that can handle those 1-5% of use cases where Go would have you drop to interface{}) in exchange for essential things like sane tooling. Rust stands alone as a possible exception, but only since it shipped non-lexical lifetimes, rust-analyzer, and a long tail of other improvements that have recently brought its usability down into a range that is acceptable for general application development.

Less is more... until you need more.

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud.

I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity.

IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go.

The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You.

The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory.

Because of go fmt, all Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects.

I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing.

So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib.

And most of all we get a platform that understands and managed complexity in a favorable way.

$0.02. Ok, maybe $0.05 (inflation).

Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance) make things an order of magnitude more expressive.

This does a poor job of justifying the claim that golang is more expressive despite having fewer features than similar languages. I agree to a certain extent that golang's simplicity is an advantage. However, its simplicity does actually make it less expressive.

For example, in Java one can trivially create a class like `Maybe` with a method `Maybe map(Function mapper)`. This can be used with any classes filling in the parameters. I believe golang is unable to express this.