Ask HN: Go programming language is over ten years old. What do you think of it?

This is the problem with how boring is used. According to Wiktionary it just means "unable to engage or hold the interest". So how can this be a criteria for using a technology? Why do you redefine the word and deviate from the common meaning? What is the reason behind this? Why is it necessary that your understanding of "boring" has to be explained? It is a simple word which had a defined meaning for hundreds of years probably.

But here is my take on it: This was simply an attempt made by clever people within the industry to redefine the word so that they do not have to explicitly say what they really mean. Just call things without having a proper definition "boring". What is not boring must then be exciting. If we define boring to be good (which is actually crazy since the word itself has a negative connotation) everything exciting must be bad. Simple black/white thinking. And now we can simply call things "boring" as we like and indirectly call everything else bad.

Also it totally makes no sense to call technologies "boring" or "exciting" and thereby categorizing them for suitability. "Boring" is highly subjective. Some find Go boring, other find it to be exciting. Some find VBA boring, others experience it to be exciting. This has nothing to do with how complex, simple, fancy, hyped or old a technology is.

> To me, a boring language is one that is easy to learn, easy to read and which encourages somewhat homogenous code - through coding style and common idioms. It has few surprises and few dark corners.

Why is that boring to you? To me a language where I could easily reach a common ground with my colleagues so that we can together focus on business problems would be a very exciting language.

> Now I can understand that some people like the excitement of exploring new languages. Excitement of exploring new languages does not mean that the explored language is exciting/boring (whatever that means)

>However, asking your employer to let you use some language on a project because you find it "exciting" is a big ask.

One should only ask the employer to be allowed to use a new language if there is some benefit or if it is an experiment which will clarify whether it will be beneficial. This has nothing to do with boring/exciting.

> They may, however, be somewhat scared of "specialists" (in the sense of programmers who will insist on niche languages or niche technologies) because if you pay someone to write code, you don't want to have to search for "specialists" to maintain it or limit the size of your recruiting pool. You have an investment to manage.

True. This is where the risk parts enters the stage. It is always like this. The specialist might put you ahead of your competitors at a high risk while the generalist will keep you with the average at a low risk.

> Do you really think the choice of language is what makes a programmer brilliant or mediocre? Where did I even say this? What does talent have to do with the programming language being used?

> Then why doesn't reality agree with that view? If that were true then for every Donald Knuth, Fabrice Bellard, Jeff Dean and John Carmack there should be lots of even better programmers that do all their work in "exciting" languages. Where are they? They should be far easier to enumerate than the people who use "boring" languages?

Uh, with what view? Definitely not mine. Who says that the programming languages those people use are boring? I think you can simply choose any language and you are likely able to find 4 people who are potentially better programmers than the four mentioned. Not because they are bad or mediocre but because of the sheer amount of programmers in the world. Those four are simply famous but we have no proof/numbers on how "good" they are compared to the rest of the world.

> If you think caring about the long term value of code is "boring": try to start your own company and bet your own money.

And again. I never said this. Which definition of "boring" are you using here?

Also that sentence is dangerous. Even if caring for long term value would be boring (for some it might be exciting!) the real motivation for this is to secure previous investments which is a perfectly valid reason. Whether the way of achieving is is boring or not is completely irrelevant. And even further: If I would find an exciting(for me, since excitement is subjective) way to secure or even grow my investments I should not do it because it has to be boring? Securing investments or caring for long term value has nothing to do with whether something is boring or not.

> If you are that convinced of how "exciting" languages lead to brilliance it shouldn't be a tough choice to make

And once again. I never said this. I just said "Also we are scared of specialists and talent and want to stay mediocre" which not even mentions programming languages/technologies. I was just referring to how the word "boring" is misused and what might be the true intention behind the usage.

So in a summary: Good or bad decisions in business have nothing to do whether something is boring or not. This should never drive business decisions. But it seems like the word "boring" does.

At what point are we just creating a new language that compiles to Go, though?

Exceptions create drastically shorter applications versus Go's explicit returns. I'll have to see if I can run an analysis later; I would wager that 20-30% of the lines in our monorepo are related to error handling. This is in large part due to the style of having the if err return err take 3 lines, but that's the prevailing style. Additionally, it requires an explicit handling block everywhere that might return an error, even if you don't want to handle that error there (i.e. in a web app, not handling an exception defaults to a 503 error. It takes 0 code to return a 503 on an error, which is usually the default error path).

For generics, I needed to write a map merge for two map[string]interface{} maps. Fairly basic, for scalar values prefer the value from the first map on conflict, for slices append the two arrays, for maps do a recursive merge. I used a type switch to get the type of each value, when I realized that []string and []interface{} were different, and that I wouldn't be able to append to a []interface{} unless I convert the []string. Fine, so I need a function that creates an []interface{} and converts each index in the []string to an interface{} and puts it in the array. Except because of the type signatures, I now also need one for every scalar type in Go. Is it an overwhelming amount of effort? No, but it did turn 6 lines of code with 12 lines of unit tests into something like 50 lines of code with 100 lines of unit tests (more type switches). Generics should have allowed me to say that I don't care what type the input is (and interface{} doesn't work here). Worse, now if I adjust a unit test, I have to do it in several places, not just one.

Those are the things that frustrate me in Go. It ends up feeling like I'm brute forcing software development; it's not the fastest way to do it, but it'll work if we're just willing to rewrite the same function 10 times with different type signatures, or write if err statements 10 times so that we can get the error up to the 11th caller in the stacktrace, who's actually going to do something useful about the error.