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

In order to have a meaningful discussion, let me expand on what I mean by "boring".

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.

If a language still has major aspects that practitioners struggle with after 2-3 years, it isn't "boring". If you have to expect every codebase in the same language to have different coding standards, it isn't boring.

A boring language is one where what you've learnt on one project has a high probability of being usable in a completely different company or on a project that does something entirely different from what you've done before. It is a language that disappears because you spend more time talking about how to solve problems and less time talking about how to express those solutions in a language.

Now I can understand that some people like the excitement of exploring new languages. And you should. On average you should try to learn at least one new language each year. Even if it is on your own time if your employer is stingy.

However, asking your employer to let you use some language on a project because you find it "exciting" is a big ask. Projects tend to have deadlines, they have quality targets, many projects are built by teams, so entire teams have to be conversant in the language. What if you need to scale up with more developers? How easy is it to recruit programmers in a given language and at a given level of proficiency? How about maintenance after you have left the company or grown tired of whatever language you were once very excited about? And what happens when a language goes out of fashion but the company running the code still depends on it?

People with responsibilities are not scared of talent. Rather the opposite. They depend on talent.

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.

As for mediocrity: I think you would need to back that argument up with something. Do you really think the choice of language is what makes a programmer brilliant or mediocre? 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?

If you think caring about the long term value of code is "boring": try to start your own company and bet your own money. If you are that convinced of how "exciting" languages lead to brilliance it shouldn't be a tough choice to make.

Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. A linear search is generally more efficient than a random walk, but depends on an accurate assessment of the direction and magnitude of each step. A binary search also depends on a global ordering criterion. All that would too much to ask of many users of Go.

> Imho because it is highly opinionated and the designers of the language also suggests best practices.

In my experience this is actually a plus. I've lead a department that made the transition from Java to Go, and one of the really noticable things were entire classes of fruitless (and frankly, unnecessary) discussions disappeared. Having an opinionated language that comes with a canonical formatter and lots of established idioms made it easier to scale up to more people because more of the code looked homogenous more of the time.

However, with any new language someone takes up there is the risk that people will try to bring along their old habits from other languages and be unhappy if they can't just continue writing C/C++/Java/Python/C#/JavaScript/Lisp in Go. If this takes hold, you will waste a lot of time having fruitless discussions.

It is easier to adapt to a coding style that is shared than it is for every project and every team to invent their own. For instance, I've worked for only one company where using C++ was even somewhat pleasant: and it was in large part because a) the company had a very strictly enforced code standard for C++ (and other approved languages), and b) you had to demonstrate you could stick strictly to the code standard before you were able to approve changelists. At the time that company had some 7000 developers, of which probably 3-4000 had "C++ readability" rating.

The upshot being that after getting used to it, it was pretty easy to understand other people's code. And you would spend a lot of time reading other people's code.

I suspect Go being opinionated is a direct result of this experience.

This is not really what I had in mind. I know java has these features, but how would they make your program shorter? Could you be more specific? Maybe share an example of a real problem that is made easier by these features?

Often people will give made up examples, but the trouble with made up examples is you can't tell if they actually matter in practice or not. Sure, if we invented a way to turn popcorn into gum, itd be easier to turn popcorn into gum, but no one wants to do that in reality. I'm after real examples.

How is Go a toy language?