[alphazard]

Go criticism is always focused on the language itself, which is admittedly non-optimal. But it's non-optimal in the direction of missing features. Contrast that with most languages which are non-optimal in the direction of having too many features which are poorly designed.

Go's position on the simplicity vs feature set continuum is perhaps the least interesting reason it's popular. There are a myriad of other reasons for its success:

- It spits out static binaries with minimal fuss.

- The import statement maps strings to symbols. No complicated module system to learn. The strings are resolved to something like URLs, but that's not part of the language. It's very easy to see code on GitHub and import it.

- Packages are just directories.

- No new package namespace with squatters and poor infrastructure. Go packages, in practice, are named with DNS. You know, the namespace that already exists and everything else has standardized on.

- Rejection of complicated version selection. Go almost went down the npm route, there was even an "official experiment" that looked much like other package managers. Then the Go leadership stepped in and sorted things out. https://research.swtch.com/vgo-mvs

Go is set up to be the language of an ecosystem in a way that most other languages are not. If you are a language designer: take Go's import statement, packages, and modules, and just copy them. You aren't going to do better, and you probably weren't trying to innovate in that area anyway.

[mdaniel]

> The import statement maps strings to symbols. No complicated module system to learn. The strings are resolved to something like URLs, but that's not part of the language. It's very easy to see code on GitHub and import it.

This is for sure untrue, unless one is already steeped in the golang ecosystem.

  $ cat go.mod
  requires (
    github.com/pulumi/pulumi/sdk/v3 v3.43.1
  )

oh, cool, I can just navigate to https://github.com/pulumi/pulumi/tree/v3.43.1/sdk/v3 to view the source ... oh, :sad-trombone: it's 404. Well, why is that?

  $ curl https://github.com/pulumi/pulumi/blob/v3.43.1/sdk/go.mod | head 1
  module github.com/pulumi/pulumi/sdk/v3

Oh, because the "module" line is decoupled from the apparent URL. Then there's this `gopkg.in/yaml.v2` nonsense, as described by this: https://go.dev/src/cmd/go/internal/help/helpdoc.go#L251

Meaning navigating to https://gopkg.in/yaml.v2 gets one thing, but https://gopkg.in/yaml.v2?go-get=1 produces another and only a view-source of the latter shows what golang is going to use. Yes, I'm aware that out of the kindness of the author's heart the browser version does link to the alleged source repo, but alleged is the key part of that

[alphazard]

The Go module system has some cruft that could only really be removed in Go 2. The gopkg stuff was an attempt to bring the fragmented ecosystem along to the current solution. It's not perfect, but the important stuff (like version selection) the go.sum file etc, is well designed.

You're quoting me talking about the Go import statement, and then shifting to talking about Go modules. The import statement, at the level of the language maps a string to a symbol. Packages are just directories. I meant to compare it to the more complicated package/module systems which are built into other languages like Python or Rust.

I said:

> It's very easy to see code on GitHub and import it.

Which I maintain is true. I usually just type the import line into my text editor and the tooling figures out the rest, or prompts me to "go get". Your example talks about going in the reverse direction, which I never claimed was easy. I don't think I've ever had to do that either. If I want to see the exact version of a library, the go tool has downloaded it to the local filesystem.

[worik]

Plus very fast compile times.