[throwaway894345]

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.

[ex_amazon_sde]

I've worked with lots of languages as well and dependency management in Go is the worst.

Not being able to package build and runtime dependencies with proper versioning is an incredible pain.

[pydry]

>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.

Ironically, the fact go tried to make me use GitHub as a stopgap package manager (& denied one was necessary) while they built their own was what made me run away screaming.

They've since fixed that but seeing them fail at what Perl managed in 1995 and what became standard is larger languages around the turn of the millenium in a brand new language in 2010 wasn't a great omen.

[throwaway894345]

People scoff about "GitHub as a package manager", but it hasn't chafed me much. Moreover, the scoffing isn't very substantial--it's often some variation of "but GitHub goes down all the time?! You will never be able to build/distribute your software!", which is trivially refuted (the GitHub UI goes down all the time, but its git service going down is much rarer; you can use a caching proxy if you're really concerned about reliability of the git service just like you would with a more typical package repo; GitHub isn't necessary to distribute Go applications unlike Pypi/NPM/etc for Python/JS apps). There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing and I haven't stumbled on them (e.g., I don't have any private repo dependencies for my projects, but perhaps it would be a PITA for those who do?).

[pydry]

>it's often some variation of "but GitHub goes down all the time?!

It was never about github's downtime. It was about having to manage the code of your dependencies yourself.

>you can use a caching proxy if you're really concerned about reliability

yay one more piece of infrastructure that will break.

>There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing

I really think they were.

[winrid]

Go has been by far the worst language for me to deal with dependencies. Java probably being the best, especially if you factor in build times.