Loris comments

This commit is contained in:
Motiejus Jakštys 2022-05-21 18:11:40 +03:00
parent 15130d60f1
commit ac96c45b1a

View File

@ -9,11 +9,11 @@ Disclaimer: I work at Uber and am partially responsible for bringing `zig cc`
to serious internal use. Opinions are mine, this blog post is not affiliated
with Uber.
I talked at [Zig Milan][zig-milan] meetup about "Onboarding Zig at Uber".
I talked at the [Zig Milan][zig-milan] meetup about "Onboarding Zig at Uber".
This post is a little about "how Uber uses Zig", and more about "my experience
of bringing Zig to Uber", from both technical and social aspects.
The video is [here][milan-youtube]. The rest of the post is a loose
<big>The video is [here][milan-youtube]</big>. The rest of the post is a loose
transcript, with some commentary and errata.
{{<img src="_/2022/uber-zig-frank-tweet.jpg"
@ -26,10 +26,12 @@ transcript, with some commentary and errata.
TLDR:
* Uber uses zig to compile its C/C++ code. Now only in the [Go
* Uber uses Zig to compile its C/C++ code. Now only in the [Go
Monorepo][go-monorepo] via [bazel-zig-cc][bazel-zig-cc], with plans to
possibly expand use of `zig cc` to other languages that need a C/C++
toolchain.
* Main selling points of C/C++ toolchain on top of zig-cc over the
alternatives: configurable versions of glibc and macOS cross-compilation.
* Uber does not have any plans to use zig-the-language yet.
* Uber signed a support agreement with Zig Software Foundation (ZSF) to
prioritize bug fixes. The contract value is disclosed in the ZSF financial
@ -61,11 +63,11 @@ thousand engineers. In short, it's big.
hint="graph"
>}}
I can't tell this better than my colleague [Abhinav Gupta][abg] from the Go
Platform team (the transcript is available in the "alt" attribute):
I can't say this better than my colleague [Abhinav Gupta][abg] from the Go
Platform team (a transcript is available in the "alt" attribute):
At this point of the presentation, since I explained (thanks abg!) how Uber
uses zig, I could end the talk. But you all came in for the process, so after
uses Zig, I could end the talk. But you all came in for the process, so after
an uncomfortable pause, I decided to tell more about it.
{{<div-clear>}}
@ -102,7 +104,7 @@ it also was not painful *enough* to be picked up.
At this point it is important to understand the limitations of a non-hermetic
C++ toolchain:
- Cannot cross-compile. So we can't compile Linux executables on a Mac if they
have CGo (which many of our services do). This was worked around by... not
require CGo (which many of our services do). This was worked around by... not
cross-compiling.
- CGo executables would link to a glibc version that was found on the system.
That means: when upgrading the OS (multi-month effort), the build fleet must
@ -131,7 +133,7 @@ Bazel's toolchain documentation, and I didn't find a good example to rely on.
In January of 2021 I found Andrew Kelley's blog post [`zig cc`: a Powerful
Drop-In Replacement for GCC/Clang][zig-cc-andrewrk]. I recommend reading the
article; it changed how I think about compilers (and it will help you
understand the remaining article better, because I gave the talk to the Zig
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:
@ -151,8 +153,8 @@ of `zig ar`, which Bazel relies on.
### 2021 Feb: asking for attention
I [reported bugs][zig-motiejus-issues] to zig. Nothing happened for a
week. I donated $50/month, expecting "the zig folks" to prioritize what I've
I [reported bugs][zig-motiejus-issues] to Zig. Nothing happened for a
week. I donated $50/month, expecting "the Zig folks" to prioritize what I've
reported. A week of silence again. And then I dropped the bomb in
`#zig:libera.chat`:
@ -162,7 +164,7 @@ reported. A week of silence again. And then I dropped the bomb in
<andrewrk> did you get a different impression somewhere?
```
Oops. At the time I hoped that whoever notice the conversation will immediately
Oops. At the time I hoped that whoever notice the conversation would immediately
forget it. Well, here it is again, more than a year later, over here, for your
enjoyment.
@ -190,35 +192,36 @@ CI. It failed almost all tests.
Most of the failures were caused by dependencies on system libraries. At this
point it was clear that, to truly onboard bazel-zig-cc and compile **all** it's
C/C++ code, there needs to be quite a lot of investment to remove the
dependency on system libraries and undoing of a lot of tech debt.
dependency on system libraries and undoing of a lot of technical debt.
### 2021 End: recap
- Various places at Uber would benefit from a hermetic C++ cross-compiler, but
it's not funded due to a large investment and not enough justification.
it's not funded due to requiring a large investment and not naving enough
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.
- 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. Donations don't change `zig cc` priorities.
more than 6 months, and donations din't change `zig cc` priorities.
- The monorepo-onboarding diff was simmering and waiting for it's time.
### 2021 End: Uber needs a cross-compiler
I was tasked to evaluate arm64 for Uber. Evaluation details aside, I needed to
compile software for linux-arm64. Lots of it! Since most of our low-level infra
is in Go monorepo, I needed a cross-compiler there first.
is in the Go monorepo, I needed a cross-compiler there first.
A business reason for a cross-compiler landed on my lap. Now now both time and
money can be invested there. Having a "WIP diff" with `zig cc` was a good
start, but was still very far from over: teams were not convinced it's the
start, but was still very far from over: teams were not convinced it was the
right thing to do, the diff was too much of a prototype, and both zig-cc and
bazel-zig-cc needed lots of work before they could be used at any capacity at
Uber.
When onboarding such a technology in a large corporation, the most important
thing to manage is risk. As zig is a novel technology (not even 1.0!), it was
thing to manage is risk. As Zig is a novel technology (not even 1.0!), it was
truly unusual to suggest compiling all of our C and C++ code with it. We should
be planning to stick with it for at least a decade. Questions were raised and
evaluated with great care and scrutiny. For that I am truly grateful to the Go
@ -235,26 +238,26 @@ Given that we now needed a cross-compiler, we had two candidates:
uncertain, used-by-nobody, but quite a tempting solution.
`zig cc` provides a few extra features on top of `bazel-toolchain`:
- configurable glibc version. In grailbio case you would need a sysroot
- configurable glibc version. With `grailbio` you would need a sysroot
(basically, a chroot with the system libraries, so the programs can be linked
against them), which needs to be maintained.
against them), which would need to be maintained.
- a working, albeit still buggy, hermetic (cross-)compiler for macOS.
Glibc we can handle in either case. However, `bazel-toolchain` will unlikely
ever have a way to compile to macOS, let alone cross-compile. Relying on the
system compiler is undesirable on developer laptops, and Go Platform feels that
first-hand, especially during macOS upgrades.
We would be able to handle glibc with either, however, `grailbio` is unlikely
to ever have a way to compile to macOS, let alone cross-compile. Relying on the
system compiler is undesirable on developer laptops, and the Go Platform feels
that first-hand, especially during macOS upgrades.
The prospect of a hermetic toolchain for macOS targets tripped the scales
The prospect of a hermetic toolchain for macOS targets tipped the scales
towards `zig cc`, with all its warts, risks and instability.
There was another, attention problem: if we were considering the use of Zig in
a serious capacity, we knew we will hit problems, but would be unlikely to have
the expertise to solve them. How can we, as a BigCorp, de-risk the engagement
question, making sure that bugs important to us are handled timely? We were
sure of good intentions of ZSF: it was obvious that, if we find and report a
legitimate bug, it would get fixed. But how can we put an upper bound on
latency?
There was still another problem, one of attention: if we were considering the
use of Zig in a serious capacity, we knew we will hit problems, but would be
unlikely to have the expertise to solve them. How can we, as a BigCorp, de-risk
the engagement question, making sure that bugs important to us are handled
timely? We were sure of good intentions of ZSF: it was obvious that, if we find
and report a legitimate bug, it would get fixed. But how can we put an upper
bound on latency?
### Money
@ -269,11 +272,11 @@ Contract terms were roughly as follows:
- Hack hack hack hack hack.
- When done, Loris enters the number of hours worked on the issue.
Uber has the right to *time* of ZSF members. We have no decision or voting
power whatsoever with regards to Zig. We have right to offer suggestions, but
they have been and will be treated just like from any other third-party
bystander. We did not ask for special rights, it's explicit in the contract,
and we don't want that.
Uber has a right to ZSF members' *time*. We have no decision or voting power
whatsoever with regards to Zig. We have right to offer suggestions, but they
have been and will be treated just like from any other third-party bystander.
We did not ask for special rights, it's explicit in the contract, and we don't
want that.
The contract was signed, the wire transfer completed, and in 2022 January we
had:
@ -284,7 +287,7 @@ had:
and hermetic.
{{<img src="_/2022/uber-zig-deposit.png"
alt="Wire transfer of $52800 from Uber to Zig Software Foundation"
alt="Wire of $52800 from Uber to Zig Software Foundation"
caption="The amount of money that changed hands is public, because ZSF is a nonprofit."
hint="graph"
>}}
@ -341,7 +344,7 @@ sister teams in Seattle and Bay Area are hiring too. Ping me.
Credits
-------
Many thanks Abhinav Gupta for reading drafts of this.
Many thanks Abhinav Gupta and Loris Cro for reading drafts of this.
[^1]: Errata: I incorrectly said "by an order of magnitude". The order of
magnitude is the same.