"So, if Go is as bad as the comments so far make it out to be, what are some alternative languages?"

While a good question anyhow, it's not as bad as the comments make it out to be. Anything can be made to look bad by only looking at the negatives, anything can be made to look good by only looking at the positives. And the balance shifts depending on what sort of application you're writing. There's a reason that Go has seen a lot of success writing network servers. There's a reason why Go has no penetration into the scientific computing community, and I tend to warn away anybody even thinking about it.

In particular, a lot of the people screaming about Go do not consider some of the positives. For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some really good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) This can be done in other languages, but it often involves jumping through hoops to create your own objects that mirror other object's methods so they can implement an interface or something; in Go it's trivially easy. Between that and the way errors are handled, I find it relatively easy to write very bullet-proof code.

And while I also consider it annoying that Go lacks half of generics (interfaces are actually half of generics, but it's missing generic types), there are also often ways of spelling your APIs so it matters less. My code actually doesn't end up with very many interface{}s in it, and many of the ones that do are "real", in that the code in question really doesn't care what's there.

If you don't put those positives onto the balance, you don't get a proper view.

It doesn't help that, frankly, this was not a very good article and I strongly agree it has tone issues. This brought out a lot of people who might otherwise have just clicked over without commenting.

> For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some really good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.)

I'm confused. How does not having to write "implements Reader, Writer" (25 characters to type) have anything to do with purity and IO effects?

> interfaces are actually half of generics

Interfaces aren't generics at all. Java had interfaces and Object as a supertype before it had generics, and it still had zero support for generics.

I do agree with you that Go has maybe 50% of the use cases for generics covered, but not because it has interfaces. Those don't count. It's because it has maps and growable arrays built in.

"Interfaces aren't generics at all."

It's a definition game. One component of "generic" is "generic algorithm". Go has that covered; the Sort package provides a "generic" algorithm via an interface specification. A lot of C++ template code is built around implementing generic algorithms at compile time rather than Go's run time, for instance.

If you choose to call that "not generics", that's a valid choice of definition, and certainly makes sense in a Rust context, but it's not universally valid.

For context, I'm not trying to bend a definition to "defend Go"... I generally have a low opinion of software engineer's ability to create universal definitions of terms that apply across all languages, and I observe that pretty much any term you can imagine varies across language communities. I'm not the one creating terminology vagueness. And I have observed that every time someone contradicts me and insists some term really is rigorously defined and agreed to by all major language communities, you can count on two or three disagreements from not-me in the replies...

You can add methods on a type you don't control, without casting/subclassing that type. - the original interface does not have to even know that your interface exists.

> Anything can be made to look bad by only looking at the negatives, anything can be made to look good by only looking at the positives.

And then you have the faux-"fair and balanced" posts about Go by jerf, which always ends up favouring Go for some inexplicable reason.

I like it, because I'm writing network servers for the most part. Don't use it for scientific, numeric, or desktop GUI work. You can find posts on /r/golang where I actively discourage that. The further you get from a network server, the worse off you are.

How much more balanced do you want? If "balanced" looks like advocacy, well, maybe the problem is the community has overshot into the trough of disillusionment: https://en.wikipedia.org/wiki/Hype_cycle

If the community was over-praising Go... no, actually, when the community was over-praising Go, you know, that thing that caused the backlash we're in now... I was more negative. It wasn't the Best Language Ever. It's also not the Worst Language Ever.

And I'm generally against seeing "Library X, BUT IN $X!" on the front page of HN for all values of $X, but, that's a separate discussion.

Haskell is my preferred statically-compiled-but-with-coroutines-and-channels language. It's harder to learn and the tooling is not as good as Go's, but its type system is far more powerful and useful. You can build useful generic abstractions over all types of channels and use them in every context. In Go you either have to use interface{} and pay the perf hit or write a code generator.

> Specifically, a compiled language that can be deployed without worrying about dependencies. That's the feature that has had me looking into learning Go.

Any language with a compiler for native code. All of them support static linking, that is nothing special in the Go toolchain.

It's been a few years since my last C++ class, and I haven't done any compiled programming since. So I either completely forgot about static linking, or it just didn't get covered.

Why have I seen several go apps that use static linking, but every C or C++ app I see uses dynamic linking?

A quick google makes me think that the main downsides to static linking are resources and upstream bugs. Those issues would apply to go the same way they'd apply to C. Right? So why does it seem (from my limited experience) that go uses static linking more than other languages do?

The authors are very vocal against dynamic linking.

http://harmful.cat-v.org/software/dynamic-linking/

Modern applications use dynamic linking most of the time, because despite the possible headache with versions, it offers a much more flexible architecture.

You mean any compiled language with static linking? Don't they all support that?

I mean you can even get the jvm/java apps bundled as a single binary if you really want to.

Statically linked binaries is not a new thing. You can do that on many languages.

C++.