5 ms·

Not a Golang expert or zealot, but a few things come to mind that make it suited for large scale projects and collaboration: 1) Extremely fast build times (eve

Not a Golang expert or zealot, but a few things come to mind that make it suited for large scale projects and collaboration: 1) Extremely fast build times (even for large codebases). 2) The package system plugs directly into Git/Github. The second reduces friction for distributed/large teams to share packages with a lower administrative burden. I can't compare to modern Java/C# because I haven't used either for quite some time.

apta 7y ago
> 1) Extremely fast build times (even for large codebases). Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well). > 2) The package system plugs directly into Git/Github. This doesn't suite everyone, as not all projects are open source. > with a lower administrative burden. Any serious company is not going to (1) allow arbitrary code to be pulled from github/etc. and (2) needs to maintain a local repository of it anyway in case github/maven/etc. goes down.
- sagichmal 7y ago
  > Not much faster than C# or Java in practice Go compile times are pretty inarguably faster than these in practice, yes.
  - apta 7y ago
    Seems like you haven't worked with actual large scale golang code bases then.
    - hu3 7y ago
      I have. Both C# and Go 500k+ LOC codebases. Compilation time between them is a magnitude apart it's not even arguable.
    - vijaybritto 7y ago
      Well, I have. 300k LOC which was ported over from Java to reduce complexity. Go is mind blowingly fast in compilation times compared to Java. Arguing on it is a waste of time tbh
- throwaway894345 7y ago
  Go’s tooling is generally straightforward and there is usually one canonical/standard implementation. No insane DSLs to build your program, no daemons required for fast builds, and batteries are included (test framework is part of the tooling). No crazy documentation syntax, no docs packages to publish and link against your dependencies, etc. In general, Go is simple so your organization can focus on business problems.
- kubanczyk 7y ago
  > Any serious company is not going to (1) allow arbitrary code to be pulled from github/etc. Parent said "Git/Github". You can use private git repo, you can use private github repo.
- closeparen 7y ago
  That's why the module system is designed to facilitate corporate artifact caches. [0] [0] https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/ https://arslan.io/2019/08/02/why-you-should-use-a-go-module-...
pjmlp 7y ago
> Extremely fast build times (even for large codebases). Pascal and Modula-2 compilers were already doing that in MS-DOS days. As several other AOT toolchains.
tsimionescu 7y ago
2) is one of the major disadvantges of Go for my team. It requires our source control system to be Go-mod-compatible. It requires commits/tags in source control to publish internal builds. Its complete reliance on semver completely breaks when you want temporary branches for internal versions. It makes it very difficult to have multiple Go modules in the same repository. Overall, it's a horrible system.
- Kaze404 7y ago
  My favorite is having to change Git's global settings if you want to use a dependency that's a private repository. The system is awful through and through.

apta 7y ago

> 1) Extremely fast build times (even for large codebases). Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well). > 2) The package system plugs directly into Git/Github. This doesn't suite everyone, as not all projects are open source. > with a lower administrative burden. Any serious company is not going to (1) allow arbitrary code to be pulled from github/etc. and (2) needs to maintain a local repository of it anyway in case github/maven/etc. goes down.

sagichmal 7y ago
> Not much faster than C# or Java in practice Go compile times are pretty inarguably faster than these in practice, yes.
- apta 7y ago
  Seems like you haven't worked with actual large scale golang code bases then.
  - hu3 7y ago
    I have. Both C# and Go 500k+ LOC codebases. Compilation time between them is a magnitude apart it's not even arguable.
  - vijaybritto 7y ago
    Well, I have. 300k LOC which was ported over from Java to reduce complexity. Go is mind blowingly fast in compilation times compared to Java. Arguing on it is a waste of time tbh
throwaway894345 7y ago
Go’s tooling is generally straightforward and there is usually one canonical/standard implementation. No insane DSLs to build your program, no daemons required for fast builds, and batteries are included (test framework is part of the tooling). No crazy documentation syntax, no docs packages to publish and link against your dependencies, etc. In general, Go is simple so your organization can focus on business problems.
kubanczyk 7y ago
> Any serious company is not going to (1) allow arbitrary code to be pulled from github/etc. Parent said "Git/Github". You can use private git repo, you can use private github repo.
closeparen 7y ago
That's why the module system is designed to facilitate corporate artifact caches. [0] [0] https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/ https://arslan.io/2019/08/02/why-you-should-use-a-go-module-...

pjmlp 7y ago

> Extremely fast build times (even for large codebases). Pascal and Modula-2 compilers were already doing that in MS-DOS days. As several other AOT toolchains.

tsimionescu 7y ago

2) is one of the major disadvantges of Go for my team. It requires our source control system to be Go-mod-compatible. It requires commits/tags in source control to publish internal builds. Its complete reliance on semver completely breaks when you want temporary branches for internal versions. It makes it very difficult to have multiple Go modules in the same repository. Overall, it's a horrible system.

Kaze404 7y ago
My favorite is having to change Git's global settings if you want to use a dependency that's a private repository. The system is awful through and through.