Yes, that title shouldn't have been posted to HN (see https://news.ycombinator.com/newsguidelines.html) and we've changed it accordingly. If anybody suggests a better title, we can change it again.

I am not agreeing with your sentiment for Go but I do want to strongly agree with this statement:

> I'm afraid I might end up having to maintain code written in it one day

I have similar fears about Ruby. This is also true of many contractor firms where they write beautiful tested code which is designed to work really well right now, but not designed to last (think views rendering database objects).

I think this is a sentiment people need to have when they see something cool or some sort of solution: Will I, in 4 years, want to maintain this? Will some person, in 4 years, curse my name for having written this?

I think python is going to keep eating ruby's lunch as more universities teach it.

I don't dislike Go. I just think there are zero use cases where Go is the best choice. But what I do dislike is when people try to hype and con others into adopting a language to justify and increase the return on their own time investment.

> But what I do dislike is when people try to hype and con others into adopting a language to justify and increase the return on their own time investment.

The same can be said of any programming language community, IMHO.

True. This is why I find the point of the post kind of "backward". I don't think most people hate something because they feel attacked in their identity. I feel like it's the opposite: most people defend a certain technology at all cost because they feel attacked in their identity when somebody criticizes it.

Sure. I think it's more prevalent among Go zealots, probably because so many were lured into it by the inital hype, but it's not at all Go-specific. Another example is the hype and love-hate relationship people have with Javascript MVC frameworks. Even with React, which actually deserve the hype, there are many who default to "hating" it because they're sick of being fooled by all the hype.

I agree the title's a bit baity.

But this part stuck out for me:

> When I first heard about Go, I thought "What? No exceptions? Pass."

Lo about 12-13 years ago I balked at Python's significant whitespace, but I came around. And rust's lack of exceptions, but I'm coming around. I think there's certainly something to be said for "identity" (maybe it makes more sense to describe it as prejudice/bias/context, but whatever).

I haven't given Go a fair eval yet so I can't say much (except I don't "hate" it.)

"I dislike Go because I agree with the criticisms of it and I'm afraid I might end up having to maintain code written in it one day"

and:

"I also don't like Go much, but it's not because it challenges my identity"

You are EXACTLY who the article is talking about. One of Go's selling points is maintainability. Go's inherent bias towards maintainability challenges your identity.

Selling points are not facts, they're just arguments people who are trying to sell something like to make.

Go's users and designers make all sorts of claims about it. As it happens, I've evaluated them and find that I often disagree with them.

For instance, Go projects often don't specify the versions of their dependencies and choose to just clone the code into their own source tree instead - if you're lucky. If you aren't then the project simply depends on whatever is found in the dependencies git master branch. I find this to be poor practice from several perspectives, maintainability amongst them.

I never said code written in Go is hard to maintain. I said I don't want to maintain it, because I don't want to debug or write Go myself. You're arguing with a straw man.

the article is suggesting that when people say they don't want to debug or write in Go is because it challenges their previously formed beliefs in what they believe they need from a language. The fact that there may be another way or that projects are increasingly succeeding, challenges their identity.

Counterpoint: Show the fact that Go is easy to maintain.

The language is, honestly, too young to have much "rubber meets the road" legacy code for anyone to make a strong evidential case with. It's all theory until a decade from now.

The burden of proof is on the people making the "selling points" to prove that they are true -- in this case, if the Go community claim that Go is easy to maintain, the burden of proof should be on them.

(Note: I'm not arguing for or against this point; I've never used Go, so couldn't possibly know)

Isn't that fairly subjective? Some people find Lisp hard to parse and therefore to maintain but that doesn't mean it's inherently unmaintainable.

Yes totally subjective - different people work on different projects which eventually opinions are formed from.

I don't think Go was intended to improve upon any Lisp deficiency.

If that's an accurate summary (I am not commenting on that fact), it's a completely clickbaity summary. Because it applies equally to why everyone hates every even semi-popular language (other than their one true love, if it's considered sufficiently popular).

For a one line summary, it's pretty accurate, but it's also a great illustration of why basing opinions on one line summaries is often a bad idea.

The difference between Go and pretty much every other semi-popular language is that Go is very much defined by what it isn't rather than by what it is. In that way, its success is an implicit criticism of other languages much more than the success of any other language would be.

What's worse, is that it's a criticism backed up by empirical data. But programmers are unique and lucky, in that they get to be illogical and dogmatic while getting to appear rational and technological.

Bad code is bad code regardless of language. Some languages just make writing bad code more palpable than others.

The issue is not "is the code maintainable" or "does Go lead to unmaintainable code".

The issue is, do I wish to spend my days debugging code and writing more code, in Go? I used languages with Go's limitations back in the 1990's. I don't want to go back.

Writing and debugging code in Go is extremely more pleasurable than debugging, say, python. I write Go all day while our data scientists write python. Unfortunately python gives those guys enough rope to hang themselves and me too. It's simply harder (not impossible of course) to write unmaintainable code in a limited, static language like go.

Python in a nutshell: What you gain in flexibility and terseness, you more than lose in needing 100% unit test coverage, because every line could fail to execute (with an error that many other languages would find at compile time).

Yeah, I wouldn't want to maintain a large Python codebase either.