From 7e82e68d7a7504d32e6335945d16abadb5f5ffed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Motiejus=20Jak=C5=A1tys?= <motiejus@jakstys.lt>
Date: Mon, 23 May 2022 16:04:18 +0300
Subject: [PATCH] Ken's comments

---
 content/log/2022/how-uber-uses-zig.md | 32 +++++++++++++++------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/content/log/2022/how-uber-uses-zig.md b/content/log/2022/how-uber-uses-zig.md
index 4f9610d..105638d 100644
--- a/content/log/2022/how-uber-uses-zig.md
+++ b/content/log/2022/how-uber-uses-zig.md
@@ -47,8 +47,8 @@ TLDR:
 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
 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
-languages in back-end code is minimal.
+(like front-end for Node and Python for data analysis/ML). C++ is used for a few
+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
 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,
 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
-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"
     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.
 
 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
 work (think person-months for our monorepo), there was no immediate need, and
 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
 
-I was working on a toy project that is built with Bazel and uses CGo. I wanted
-my binary to be static, but Bazel does not make that easy. I spent a couple of
-evenings creating a Bazel toolchain on top of [musl.cc](https://musl.cc), but
-didn't go far, because at the time I wasn't able to make sense out of the
-Bazel's toolchain documentation, and I didn't find a good example to rely on.
+I was working on a non-Uber-related toy project that is built with Bazel and
+uses CGo. I wanted my binary to be static, but Bazel does not make that easy. I
+spent a couple of evenings creating a Bazel toolchain on top of
+[musl.cc](https://musl.cc), but didn't go far, because at the time I wasn't
+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`
 
@@ -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
 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
   (e.g. `-target x86_64-linux-gnu.2.28` will compile for x86_64 Linux and link
   against glibc 2.28).
-- Host and target are decoupled. The setup is the same for both linux-aarch64
-  and darwin-x86_64 targets, regardless of the host.
+- Host and target are decoupled. The setup is the same for both `linux-aarch64`
+  and `darwin-x86_64` targets, regardless of the host.
 - Linking with musl is "just a different libc version": `-target
   x86_64-linux-musl`.
 
@@ -201,7 +204,7 @@ dependency on system libraries and undoing of a lot of technical debt.
   justification.
 - 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
-  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
   developers was unpredictable. Some issues got resolved within days, some took
   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:
 
-- [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.
 - [~motiejus/bazel-zig-cc][bazel-zig-cc]: uses `zig cc`. Buggy, risky, unsafe,
   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
 [zig-motiejus-issues]: https://github.com/ziglang/zig/issues?q=author%3Amotiejus+sort%3Acreated-asc
 [kmicklas]:  https://github.com/kmicklas
+[bazel-hermetic]: https://bazel.build/concepts/hermeticity