so I've been pondering all the dunking people do on Golang
there's a fundamental contradiction in it for me: we've supposedly got much better languages, designed based on sound, solidly theoretically grounded PLT.. so everyone should be using those, right?
yet in practice, Go has significant adoption, and even as a self-identified PLT enthusiast, it's what I use day-to-day, despite being free to choose another language, though in part because the ecosystem around it is quite lively
if we're this good at programming language design as a field, how are we losing to souped-up C with interfaces and a garbage collector?
how are we losing to Rob fucking Pike?
in my personal experience, a bunch of it is about tooling:
vim-go really hits the spot for me and seemingly never breaks, an experience I've never been able to replicate with any other language
the build story is extremely simplistic but very clear
formatting is just a thing you don't have to think about at all
editor plugins elsewhere: racer (Rust) is kind of a disaster, merlin (OCaml) is usable but needs per-project configuration
neither of them do the neat things my bog-standard Go tooling does
build systems elsewhere: cargo (Rust) is nice, but requires per-project setup, OCaml doesn't even have a single answer to "how do I build my project", your build may involve arbitrary shell scripts, etc
formatting elsewhere: rustfmt is kind of a disaster and requires configuration, idk what OCaml's story is
I came from node-land where everyone uses npm, picks an arbitrary build-system-of-the-day, static analysis / editor tooling is nigh-nonexistent, usable autoformatting isn't really existent
overall, Go generally has a single, though not necessarily great answer to most questions you might have
it was kind of refreshing to me, despite my visceral dislike for the ignorance of advances in PLT it stands for
the lack of complex dependency management works out for me in practice because my code falls into roughly two categories:
* self-contained programs or libraries that themselves use only the standard library
* larger amounts of code in my work monorepo, where having n versions of deps is more often unhelpful than not
I've found some value in the limited abstraction capabilities forcing me to build more concretely, instead of allowing me to build inappropriate abstraction boundaries with ease
It's really easy to mess that up in generic programming and never truly realise - I've been forced to clean up a lot of conflation of concerns early due to the lack of real generic programming.
it's not all sunshine, obviously: I spend a tonne of time thinking about data ownership due to the lack of immutability, checked thread-safety, etc
nullable everything is a fucking scourge even though you can sometimes make clever use of it
the lack of enums / tagged unions is the absolute fucking worst and I spend too much time designing data structures because of it
I miss the shit out of Result/Either/etc style error handling, instead of having two nullable return values (no tuples, multiple return values!) that you get to check yourself
nor do you actually have any clue about what your errors look like at the type system level
enjoy your interface{Error() string} and checked downcasts
my favourite feature by far is the I/O / concurrency runtime: it's solid as heck, you don't have to argue with people using some other concurrency framework because there isn't anything else you could or would want to use (node sort of has this)
of course none of the synchronisation primitives actually compose well, other than channels (there's a single, rather inflexible `select` primitive)
so you end up reinventing a bunch of the `sync` package out of channels, or using additional goroutines to wrap them, though g'luck if you want cancellation in the latter case
the uniformity in Go code and project setups also ensures external code is easy to adopt and treat as your own, and thanks to having really solid editor tooling, exploring external code is something I do often and with pleasure