Go has a lot of advantages.

Yes, you are a little bit limmited sometimes because of the lack of generics and the like, but at the same time, if you learn to use Go interfaces well, you end up using them most of the time happily. The parallelism primitives are great too.

As much as I love complex type systems, pattern matching, algebraic data types etc., I know that if Go had those things, it wouldn't be the language I love to write everyday anymore.

Somehow, Go is a really practical language and you end up being very productive in it, at least from my experience.

Saying that people who write Go should be stupid is shallow thinking. Complex languages aren't the only complexity that you should have. Some people concentrate on sophisticated architectural design (like Kubernetes).

There is one thing in Go, that I haven't met anywhere else. I can really understand any codebase I stumble upon in a matter of seconds. This is a huge boon to productivity.

Anyways, I never had any problems switching between Go and languages like F# or Scala on a daily basis. Rust looks interesting, though I think it will end up being too complex for a lot of people to understand, which will hinder its growth.

> There is one thing in Go, that I haven't met anywhere else. I can really understand any codebase I stumble upon in a matter of seconds.

Care to elaborate a bit more?

I understand that when you see for(...) { b[i] = f(a[i]); } then you instinctively know that it's a loop that maps over some sequence, and so on. But let's say you have a 50-100kloc codebase with a 100 files in it. In what unique to Go way does Go help you understand the big picture/coarse architecture of such a project?

Oh, that it doesn't.

I meant smaller parts of code, and not for loops actually. (I prefer maps, filters etc.). Things like gofmt and the simplicity (in that, small number of concepts) of the language lead to most people writing fairly idiomatic code. This way most codebases look the same and you read each other's code as it were yours.

I'm just getting into Go and have found what you said to be true. It's easy to read other people's code on GH (Java is much the same way). Compare that to something like Scala, where no ones code looks the same.

I'd like to echo what you said. I tend to be a victim of analysis paralysis, spending hours thinking up the most clever design. Go offers far fewer alternatives so there goes the temptation. Given a smallish task, I simply sit down and grind out code, and a couple of thousand lines later I have a simple, self-contained executable that does what I wanted to do. I feel there's a kind of magic in Go's brute simplicity.

Check out sourcegraph, it's great for reading Go and Java code and has a GitHub integration.

Honestly the biggest thing go has going for it is gofmt. Its one of the few things I miss when I work with other languages.

Doesn't every semi-decent IDE have an option to reformat your code? What makes gofmt so special?

That all code is written the same from the get-go, and you can readily browse it in places like github, etc.

No external choices the language dictates style. It ships with the sdk & contributors are expected to use it so there is a cultural agreement out of the box. It's a cli tool so it's immensely scriptable and easy to integrate.

I think it may actually be the thing I miss the most. (together with implicit interfaces)

My biggest problem with it is implicit interface.

I genuinely despise that about it.

Why don't you like implicit interfaces, it's the feature I love the most actually?

I like it as well although I can see there would be times when you might want to be explicit.

I understand, but why would it be the greatest issue to despise, I'm just curious.

So, do people who write timeseries databases in Go (like influxdb and prometheus), people who solve complex infrastructure problems (like k8s and docker), people who do distributed software (like consul) feel stupider because they write in Go?

Probably not. As someone who finds Go cringeworthy, I still find it extremely useful for certain types of programs. I write far simpler Microservices in Go, and I don't feel stupid. It's pretty rough and boring tool, and using it is a chore, but if the tool fits the job well enough, you can get good craftsmanship done even with a hammer.

I think it's in the same position Java found itself in the early 2000s, another boring and unimaginative language that ended up being a workhorse.

A good engineer can build a bridge out of rotten trees.

But they could still build a better bridge, in less time, with proper materials.

You know, I think, maybe it's not a coincidence that almost all high-scale infrastructure tooling is written in Go nowadays.

Almost all high-scale infrastructure tooling? Are there many databases, parallelism frameworks, indexing systems, or machine learning frameworks in go?

I’d be interested if you can name any fields where non-Google go projects dominate. I only know of containers.

Service Discovery and configuration (Consul, etcd), Monitoring (Prometheus and Influx), non-container cluster management (Nomad), databases (CockroachDB), messaging (NATS, Jocko), Terraform. Other than that, I think everybody noticed the frequent posts "xxx database written in Go". Also, most high scale computing companies now use Go for their infrastructure parts.

EDIT: You can also check out all the stuff the CoreOS team puts out.

I’ve actually never used any of them, and none of the devs or ops people I usually talk to used them either.

We never even heard of any of those except for CockroachDB.

Are you sure these are "dominating the entire industry"-products, as you mentioned before? Or is it more that they’re only used in SV?

Totally not, I'm working in Poland. And, I'm sorry to say, if you haven't heard about Consul, then you're really not in a position to judge if infrastructure tools are or aren't written in Go. Consul is the de'facto industry standard for service discovery for a few years already.

EDIT: Cockroach is actually the most SV'ish of all those.

I think you exaggerate. Consul is probably the go-to discovery service discovery for new projects at startups and tech companies that aren't afraid of the bleeding edge, but if you count installed base and less bleeding-edge companies ZooKeeper probably still reigns supreme.

Definitely. And while ZooKeeper is common, (and apparently Consul is now the hot new thing, I guess?), many places also build their own systems.

I wouldn’t call Consul "industry-dominating technology", as you’d do with ElasticSearch, Hadoop, Spark, etc.

I'd call Spark a much more bleeding edge product than Consul. And no, it's not the hot new thing at all. It's just a standard tool.

And the funny part is that all of them are Java. :) Well, except Spark which is Scala.

Yes, exactly. In a list of most important tools out there, Go only turns up for a few tasks that used to be done in C++, as layer between the OS and services.

Almost everywhere else, it’s not "industry-dominating" at all, so I’m not sure why people use the argument "go is used everywhere and everything is in go" (which is obviously false) to argue that go is a good language.

(besides, C is actually used everywhere, but no one would use that as argument to show how C is a good language).

> Consul is the de'facto industry standard for service discovery for a few years already.

So standard that it doesn’t even have a Wikipedia page? Nor is there even one for this specific type of datacenter-oriented service discovery?

This is all pretty niche tech, used by a handful of startups that engineer technology for billions of users, but not used anywhere else. I’ve never seen any companies on national scale operate with this – nor would they need to.

The thing is, I know a lot of companies using it at nationwide scale (non-startups). I think there's a reason you are getting downvoted.

Anyways, Service Discovery like this is less niche than containers are. If containers are still niche for you, then there you go.

> I think there's a reason you are getting downvoted.

Well, so are you, your comments are even so grey I can barely read them anymore (and I can’t downvote you).

Regarding the rest: Containers are far less niche than Consul is. For service discovery, the market isn’t nearly as monopolized as containers are. And containers are far more used than consul is – most places I’ve seen build their own service discovery systems, or hardcode a main node and then have services in containers register with that, etc.

While for containers, at the moment, there’s almost only docker, due to the ecosystem.

etcd is also used quite a bit for service discovery, but it's written in Go too :)

Are you using it personally? I never met anyone using it for that. How's your experience with it been? (in case you did use it)

In the ops world, these tools are pretty much the standard. If you look at the state of many of the tools targeted at infrastructure were, with in the best scenario a decently maintained Python code-base - it's no surprise the ops world jumped on Go.

Go's main attraction there is that it's a simple, script-like language that compiles to easily deployed static binaries. That enables people who's main job is not necessarily coding, but with a good scripting background to solve problems by writing more complex/performance-critical stuff which was previously not feasible in languages like Python, Ruby, ...

These projects requiring more performance would have required a seasoned dedicated C/C++ coder before, but now they can be started and maintainer by people initially not focusing on programming, but on solving problems they are facing in their daily job. They don't have the time to invest learning a language with complex typesystems where initially, you'll be fighting the language itself more than solving actual problems. For programmers, this investment is useful, it's their main skill and is worth something. Ops people have other things to worry about, and just want to solve problems.

It does mean wheels are being reinvented, but the major projects now have pretty smart people working on them, hitting the limits of the language and it's garbage collector, pushing them forward.

> In the ops world, these tools are pretty much the standard

Thankfully, this is true only in the HN bubble. One example: Amazon.

Amazon is a big enough company that it's obvious that they'll roll their own stuff usually.

I am forced to use PHP at work. I hope that the stimulation I throw at my brain on lunch breaks and evenings offsets what you describe. Maybe it isn't enough and I'm on a long road down towards a point of no return.

That said if I look back on the past 6 months, I believe I have improved. In fact, a core principle I hold dear goes as follows:

"If I look back 6 months and I'm not any better, there's a big problem".

At one point, it seemed to annoy my non-technical boss because he couldn't understand why some of the code I wrote 6 months ago is perhaps not as good as it could be. He has kept me around so maybe it isn't a bad thing :)

We will, I think, always have programmers who don't want to learn anything new. It's interesting that there exists "Continuing Professional Development points" in the UK for healthcare: you get a rebate for each hour spent on courses to further your education. Maybe software engineering would benefit from this given the amount of, quite significant, cost sunk into large scale projects. Their universal credit programme should be incentive enough.

Entirely different problem though. If not Go, then what?