3 ms·
My read on Go versus other options, having used it for a year or so and then switching back to other old favorites(Python, Haxe, Lua), is that it really doesn't
by megameter 5y ago
My read on Go versus other options, having used it for a year or so and then switching back to other old favorites(Python, Haxe, Lua), is that it really doesn't want you to redefine the language. Go code is Go everywhere and asks you to work with a largely homogenous set of concerns everywhere.
That is great if you are building the environment for your application, but it's not great if you are building the application, because a differentiated app will always possess a unique application "vocabulary" - it's a thing that gets thought about in terms of a medium that is not the host language. Go resists extension, so most teams opt for primitivism rather than developing proprietary compilation mechanisms to express their spec. Everyone gets worried about the risks of generating code and how to maintain that: it's a "known" to have a larger fungible uniform codebase. The result is that "slow and steady" feeling when working with Go to do relatively high-level things - it lets you do it, but you have to work hard.
- closeparen 5y agoI think this is exactly right. I have separately used Go for more system-level code that pretty much directly wires together the standard library. Exec, x509, tar, gzip, flag, os, io, various encodings... here there is no contest. Go is a killer language for networked UNIXy stuff. These tools also compose really well, despite the absence of generics, because they speak the common language of byte arrays. Now that I think about it, Go is a language for processing byte arrays in the same way that LISP is a language for processing lists. Go is just more subtle about this specialization, and invites you to use it for other things it is less good at.