Ken's comments

This commit is contained in:
Motiejus Jakštys 2022-05-23 16:04:18 +03:00
parent ac96c45b1a
commit 7e82e68d7a

View File

@ -47,8 +47,8 @@ TLDR:
Uber started in 2010, has clocked over 15 billion trips, and made lots of cool Uber started in 2010, has clocked over 15 billion trips, and made lots of cool
and innovative tech for it to happen. General-purpose "allowed" server-side and innovative tech for it to happen. General-purpose "allowed" server-side
languages are Go and Java, with Python and Node allowed for specific use cases languages are Go and Java, with Python and Node allowed for specific use cases
(like front-end for Node and Python for data analysis/ML). Use of other (like front-end for Node and Python for data analysis/ML). C++ is used for a few
languages in back-end code is minimal. low level libraries. Use of other languages in back-end code is minimal.
Our Go Monorepo is larger than Linux kernel[^1], and worked on by a couple of Our Go Monorepo is larger than Linux kernel[^1], and worked on by a couple of
thousand engineers. In short, it's big. thousand engineers. In short, it's big.
@ -83,7 +83,8 @@ wave --- I still remember the complexity.
At the time, the Go monorepo already used a hermetic Go toolchain. Therefore, At the time, the Go monorepo already used a hermetic Go toolchain. Therefore,
the Go compiler used to build the monorepo was unaffected by the compiler the Go compiler used to build the monorepo was unaffected by the compiler
installed on the system, if any. Therefore, on whichever environment a Go build installed on the system, if any. Therefore, on whichever environment a Go build
was running, it always used the same version of Go. was running, it always used the same version of Go. Bazel docs [explain this
better than me][bazel-hermetic].
{{<img src="_/2022/uber-zig-gm-221.png" {{<img src="_/2022/uber-zig-gm-221.png"
alt="A Jira task asking for a hermetic C++ toolchain." alt="A Jira task asking for a hermetic C++ toolchain."
@ -96,7 +97,7 @@ unavoidable for some our Go code to use [CGo][cgo], so it needs a C/C++
compiler. Go then links the Go and C parts to the final executable. compiler. Go then links the Go and C parts to the final executable.
The C++ toolchain was not hermetic since the start of Go monorepo: Bazel would The C++ toolchain was not hermetic since the start of Go monorepo: Bazel would
use whatever it found on the system. That meant clang on macOS, gcc (whatever use whatever it found on the system. That meant Clang on macOS, GCC (whatever
version) on Linux. Setting up a hermetic C++ toolchain in Bazel is a lot of version) on Linux. Setting up a hermetic C++ toolchain in Bazel is a lot of
work (think person-months for our monorepo), there was no immediate need, and work (think person-months for our monorepo), there was no immediate need, and
it also was not painful *enough* to be picked up. it also was not painful *enough* to be picked up.
@ -122,11 +123,12 @@ All of these issues were annoying, but not enough to invest into the toolchain.
### 2020 Dec: need musl ### 2020 Dec: need musl
I was working on a toy project that is built with Bazel and uses CGo. I wanted I was working on a non-Uber-related toy project that is built with Bazel and
my binary to be static, but Bazel does not make that easy. I spent a couple of uses CGo. I wanted my binary to be static, but Bazel does not make that easy. I
evenings creating a Bazel toolchain on top of [musl.cc](https://musl.cc), but spent a couple of evenings creating a Bazel toolchain on top of
didn't go far, because at the time I wasn't able to make sense out of the [musl.cc](https://musl.cc), but didn't go far, because at the time I wasn't
Bazel's toolchain documentation, and I didn't find a good example to rely on. able to make sense out of the Bazel's toolchain documentation, and I didn't
find a good example to rely on.
### 2021 Jan: discovering `zig cc` ### 2021 Jan: discovering `zig cc`
@ -137,12 +139,13 @@ understand the remaining article better, because I gave the talk to a Zig
audience). To sum up the Andrew's article, `zig cc` has the following audience). To sum up the Andrew's article, `zig cc` has the following
advantages: advantages:
- Fully hermetic C/C++ compiler in ~40MB tarball. - Fully hermetic C/C++ compiler in ~40MB tarball. This is an order of magnitude
smaller than the standard Clang distributions.
- Can link against a glibc version that was provided as a command-line argument - Can link against a glibc version that was provided as a command-line argument
(e.g. `-target x86_64-linux-gnu.2.28` will compile for x86_64 Linux and link (e.g. `-target x86_64-linux-gnu.2.28` will compile for x86_64 Linux and link
against glibc 2.28). against glibc 2.28).
- Host and target are decoupled. The setup is the same for both linux-aarch64 - Host and target are decoupled. The setup is the same for both `linux-aarch64`
and darwin-x86_64 targets, regardless of the host. and `darwin-x86_64` targets, regardless of the host.
- Linking with musl is "just a different libc version": `-target - Linking with musl is "just a different libc version": `-target
x86_64-linux-musl`. x86_64-linux-musl`.
@ -201,7 +204,7 @@ dependency on system libraries and undoing of a lot of technical debt.
justification. justification.
- bazel-zig-cc kinda works, but both bazel-zig-cc and zig cc have known bugs. - bazel-zig-cc kinda works, but both bazel-zig-cc and zig cc have known bugs.
- I can't realistically implement the necessary changes or bug fixes. I tried - I can't realistically implement the necessary changes or bug fixes. I tried
implementing `zig ar`, a trivial front-end for llvm's `ar`, and failed. implementing `zig ar`, a trivial front-end for LLVM's `ar`, and failed.
- Once an issue had been identified as a Zig issue, getting attention from Zig - Once an issue had been identified as a Zig issue, getting attention from Zig
developers was unpredictable. Some issues got resolved within days, some took developers was unpredictable. Some issues got resolved within days, some took
more than 6 months, and donations din't change `zig cc` priorities. more than 6 months, and donations din't change `zig cc` priorities.
@ -232,7 +235,7 @@ research on this unproven prototype.
Given that we now needed a cross-compiler, we had two candidates: Given that we now needed a cross-compiler, we had two candidates:
- [grailbio/bazel-toolchain][grailbio/bazel-toolchain]. Uses a vanilla clang. - [grailbio/bazel-toolchain][grailbio/bazel-toolchain]. Uses a vanilla Clang.
No risk. Well understood. Obviously safe and correct solution. No risk. Well understood. Obviously safe and correct solution.
- [~motiejus/bazel-zig-cc][bazel-zig-cc]: uses `zig cc`. Buggy, risky, unsafe, - [~motiejus/bazel-zig-cc][bazel-zig-cc]: uses `zig cc`. Buggy, risky, unsafe,
uncertain, used-by-nobody, but quite a tempting solution. uncertain, used-by-nobody, but quite a tempting solution.
@ -366,3 +369,4 @@ Many thanks Abhinav Gupta and Loris Cro for reading drafts of this.
[milan-youtube]: https://www.youtube.com/watch?v=SCj2J3HcEfc [milan-youtube]: https://www.youtube.com/watch?v=SCj2J3HcEfc
[zig-motiejus-issues]: https://github.com/ziglang/zig/issues?q=author%3Amotiejus+sort%3Acreated-asc [zig-motiejus-issues]: https://github.com/ziglang/zig/issues?q=author%3Amotiejus+sort%3Acreated-asc
[kmicklas]: https://github.com/kmicklas [kmicklas]: https://github.com/kmicklas
[bazel-hermetic]: https://bazel.build/concepts/hermeticity