Why I Don't Like Golang (2016)

This was solved in rust by approaching it from the other side. You need to be explicit everywhere that a value is "borrowed", so while you never need a `->`, you'll still know it's dereferencing in the more natural place - before the variable, not as an implied step after.

It sounds like you're talking about the standard library rather than the language? The examples I gave have a very small language where you really can't remove anything, whereas in C quite a lot of the language is rarely-used, redundant, or bodged: the comma operator surprises people, for and while do overlapping things, braces are mandatory for some constructs but not for others, null and void* are horrible special cases.

Standard libraries are a different matter, but I'm not too impressed by C there either; it's not truly minimal, but it doesn't cover enough to let you write cross-platform code either. Threading is not part of the pre-99 language spec, and so you're completely reliant on the platform to specify how threads work with... everything. Networking isn't specified. GUI is still completely platform-dependent. The C library only seems like a baseline because of the dominance of unix and C (e.g. most platforms will support BSD-style sockets these days).

I'm actually most impressed by the Java standard library; it's not pretty, but 20+ years on you can still write useful cross-platform applications using only the Java 1.0 standard library. But really the right approach is what Rust and Haskell are doing: keep the actual standard library very small, but also distribute a "platform" that bundles together a useful baseline set of userspace libraries (that is, libraries that are just ordinary code written in the language).

To be fair, in a professional setting that is often not an option when it comes to programming languages. Usually you will have a situation where the language has already been chosen when you join a project. When you start a new project at a company, the language chosen is usually dictated by either what the company uses already or some process for reaching a consensus on what to use. What you don't really want in a professional setting is to use a lot of languages. For a large number of very good reasons.

Picking a language involves compromise.

I think what I perhaps reacted to were the somewhat superficial nature of the blogger's complaints. Especially when claiming to have done non-trivial projects in Go. Perhaps as a programmer, but it doesn't sound like someone who has lead development and had to make hard decisions.

Non-trivial projects usually give you plenty of other things to worry about. For instance how good the language is for collaboration, how easy it is to model things, how clear is the code, how does it make use of the machine resources, will the language still have a following 10 years from now, what does the tooling look like, what quality are the open source contributions, is the standard library usable, do the third party libraries cover enough of what you need?

And then there are the developers. You need to be able to recruit developers beyond your circle of friends. You want that pool to be as big as possible. This is why I avoid languages that have too little mainstream appeal. It doesn't help me much if I can hire some Common Lisp guru to build a lovely piece of software if I can't find anyone to maintain it once he or she leaves.

Being the one to decide what language to use for a project is a thankless job because you will always disappoint someone. Not everyone will or can take in the larger perspective. As a manager I seriously do not want to hire developers that always want to program in some other language, often one with a small following. Or who want to change languages every 2 years. Because if they can't learn to live with one of a selection of mainstream languages that are "80% okay", why would I think they are any better at dealing with difficulties in other languages? I expect good programmers to adapt practices - to make languages work for them. To be professionals.

When we switched from Java to Go in my department it was a team decision. As a manager I let my team decide what to use, HOWEVER, I made it clear that everyone will make an effort to learn whatever is chosen and I don't want any whining or excuses. If they found Go to be the wrong thing, fine, we have Java which is the devil we know to fall back on. But only after everyone has made a real effort.

That was 3 years ago. We now have somewhere in the neighborhood of 100kLOC running in AWS and it has been astonishingly productive. Sure there has been _some_ whining about small details, but on the whole adopting Go was surprisingly fast and surprisingly pain free.

I used Java as my primary language for about a decade and, to borrow your analogy, experienced a shoe that had quite a few pebbles in it from the outset.

What happened over time was that we developed a way of using Java that was less painful. And it turned out that the bones of Java are actually quite good. If you strip away a lot of the cruft people glom onto their code in the belief that it saves them time, adopt sensible ideas from how other languages want you to think, and keep things very minimal and consistent, Java can actually be quite pleasant.

But this requires you to have someone in your company that can teach people. Often peope with many years of experience who will initially insist on not changing their ways.

(The main reason I don't like Java isn't down to the language itself. It is because I don't trust Oracle. It took me nearly a decade to ditch Java as my primary language, but Go provided me with a viable option. Sure, it'll take some time still to reach the level I was at in Java, but after about 3 years, things still look good)

Did you read my comment? How do you ignore the fact that your PR build is failing?