Lies we tell ourselves to keep using Golang

> It's possible to implement CSP channels in most languages, but they're not first-class like go.

But does that matter? In all my experience, I can't think of any instances where that wouldn't be a distinction without a difference. (Perhaps I'm missing something, though.)

> Building a successful company has very little to do with tech choices.

This is what Hacker News doesn't want to hear, and so needs to hear.

Like obsessing over the school supply list at the beginning of the year and getting everything perfect; it's not the whole of success, nor is it even really a huge part. But it can be fun.

The author doesn’t fundamentally misunderstand programming language design, but rather misunderstands programmers.

Most programmers don’t need someone to tell them which tools to use. Of those green enough to need it, they certainly shouldn’t look to the internet for advice and they absolutely shouldn’t look to HN or random blogs for advice. Instead they should find a local community which can offer them support when they stumble and point them to interesting job opportunities. Because those people are real and they can build relationships and connections which will be much more valuable than some measly programming language.

Many online authors - even if technically skilled - have quite an over-inflated sense of importance. What makes somebody think that their experience in domain X and country Y apply in any way shape or form to the hundreds and thousands of industries, countries and cultures all over the planet?

As people have remarked, Amos's style can be grating and hyperbolic. That doesn't make a lot of his complaints about Go as a language incorrect.

I do think he's misunderstanding that the design intent is "networked C" and that Go + Protobuf is much better than he thinks. A lot of his complaints with the language and runtime boil down to:

- It's got a primitive type system (yep, nobody disagrees)

- It leaves a lot of problems to you (yep, just like C)

- you can't integrate it into existing binaries (yep, distributed systems connected by RPC)

He comes to terms with the last one and admits it, but it is not only the thing Go is good at but it was the design intent. If you start from "we want a language and runtime for writing distributed systems that would otherwise be written in C or Java" then Go is pretty good!

I'm a happy Go, Rust, C, and C++ person. They're each for different things. That Rust worked out (is working out?) despite being an incredibly powerful and complex language (compared to C) is awesome. In the mid-2000s, it's not clear that you'd bet on a language like Rust. It is clear you could do better than Java or C++ for distributed systems programming, and Go hit that pretty reasonably (I do wish the language had a better type system, and I'm glad to see Ian finally land generics, but I'd absolutely reach for Rust when writing code in a small group that can handle the "language complexity" in exchange for the benefits).

As an operations person who cares about deploying repeatable systems at scale, Rust's package management (and the toolchain's "packaging" itself) is an absolute nightmare. But at least I with MUSL can I have a 100% statically linked binary, which really should have been easier but that's another argument.

Seriously though, Rust team needs to have its Come To Jesus moment about not piping shit off the internet to sh.