[jacques_chester]

If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable.

Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically instant for me on the same codebases.

[johnnycerberus]

Java, Go, OCaml, Typescript (>=3.9) are in their own league when it comes to compilation speed.

[zenlot]

If anyone wants to check fast compile times try Delphi, RAD Studio has community edition which is amazing. It feels like it compiles while you type :)

[johnnycerberus]

I expect anything that has a little Pascal inside to be blazing fast.

[benibela]

And they have already added generics to Pascal

It really makes Go look like a joke

[johnnycerberus]

The features I like about Go do not overlap with the ones of Pascal. But yes, it makes Go look underdeveloped in that department.

[atom_arranger]

  1. OCaml
  2. Go
  3. Java
  ...
  999. TypeScript (any version)

The TypeScript team should consider rewriting the type checker in Rust or Go IMO. It's free, they can do what they want, but the performance is really not good (compared to what it could be) and affects a lot of people.

[eeZah7Ux]

you mean slow?

[dilap]

> Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable.

That's interesting, could you explain this more?

Context: I used to use Go a lot, but mostly haven't since Go modules, and I'm curious to know the details of the problem and why it happens.

[jacques_chester]

It doubles down on Go's assumption that git repository === a proper package/module system. It mixes up URLs and URNs.

If your git repositories aren't tagged just so, then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequently transmitted through other dependencies.

This is just jolly good fun when it turns out that your dependencies are pulling in incompatible versions of things. Since the official Kubernetes policy for downstream consumers is "we don't care about downstream consumers", it happens more quickly than one would expect.

As much as I have hated playing whack-a-mole with Maven or Bundler, I hate even more playing whack-an-adamantium-and-invisible-with-xray-eyes-mole against go mod.

[enneff]

> you often wind up with multiple snapshots from the same repo

Either I’m misunderstanding you or you’re mistaken. You can’t have multiple versions of the same module in a go build.

[neetle]

_Technically_ you're right. Go considers v0/v1 to be a distinct module from v2. Most people would consider this to be the same module, but Go doesn't. If you want to know more, you can go read the manifesto released by the maintainers about how this is "the best thing ever".

If you never tag v1, you'll never have to deal with it.

[dilap]

Huh, interesting, thanks for the response.

Does that mean Kubernetes is not following the version tagging policy in its repos? That seems...surprising!

[simiones]

The Go version tagging policy is a horrible idea for any multi-module git repo, especially one that releases both a product and some libraries.

It would mean that you need to create Go compatible tags for your library releases OR adjust your product versions to match Go's assumptions.

The whole implementation of Go modules is a shit show once you get into the weeds.

[jacques_chester]

Kubernetes has its own tagging scheme, which makes perfect sense in its context.

[dhagz]

I'm currently working on a project that depends on the k8s APIs and I haven't noticed ballooning compile times.

I'm only pulling in k8s.io/api, k8s.io/apimachinery, and k8s.io/go-client though.

[jacques_chester]

My code before a transitive dependency pulled in the k/k universe took milliseconds to compile. Afterwards it took about 10 seconds to compile. Laboriously compiling thousands and thousands and thousands of lines of nearly-identical code turns out to be much slower. There are no clever shortcuts for a compiler that cannot deduce a higher intent.

[jrockway]

I have the same experience. I maintain lots of software that directly depends on k8s.io/go-client and it feels the same as any other Go project.

[grey-area]

Don’t do that then.