4 ms·

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 multi

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.

dhagz 6y ago
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.
- jrockway 6y ago
  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.
- jacques_chester 6y ago
  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.
dilap 6y ago
> 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 6y ago
  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.
  - dilap 6y ago
    Huh, interesting, thanks for the response. Does that mean Kubernetes is not following the version tagging policy in its repos? That seems...surprising!
    - jacques_chester 6y ago
      Kubernetes has its own tagging scheme, which makes perfect sense in its context.
    - simiones 6y ago
      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.
  - enneff 6y ago
    > 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.
johnnycerberus 6y ago
Java, Go, OCaml, Typescript (>=3.9) are in their own league when it comes to compilation speed.
- eeZah7Ux 6y ago
  you mean slow?
- zenlot 6y ago
  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 6y ago
    I expect anything that has a little Pascal inside to be blazing fast.
    - benibela 6y ago
      And they have already added generics to Pascal It really makes Go look like a joke
      - johnnycerberus 6y ago
        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 6y ago
  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.
grey-area 6y ago
Don’t do that then.

dhagz 6y ago

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.

jrockway 6y ago
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.
jacques_chester 6y ago
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.

dilap 6y ago

> 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 6y ago
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.
- dilap 6y ago
  Huh, interesting, thanks for the response. Does that mean Kubernetes is not following the version tagging policy in its repos? That seems...surprising!
  - jacques_chester 6y ago
    Kubernetes has its own tagging scheme, which makes perfect sense in its context.
  - simiones 6y ago
    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.
- enneff 6y ago
  > 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.

johnnycerberus 6y ago

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

eeZah7Ux 6y ago
you mean slow?
zenlot 6y ago
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 6y ago
  I expect anything that has a little Pascal inside to be blazing fast.
  - benibela 6y ago
    And they have already added generics to Pascal It really makes Go look like a joke
    - johnnycerberus 6y ago
      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 6y ago
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.

grey-area 6y ago

Don’t do that then.