How Uber Uses Zig
jakstys.lt
jakstys.lt
Here is what I could find:
* https://ziglang.org/news/financials-update/
* https://docs.google.com/spreadsheets/d/14_ljFHGFXY5NhBhlfjgkO0RZHqeVv04fAmCxw3ZusYc/edit#gid=1409515513
2022-01-21 Deposit Uber UBER USA,LLC EDI PAYMNT JAN 20 1454320 REF*TN*0001454320*1\ Support Contract 52,800.00
(edit for formatting only)
> Contract terms were roughly as follows:
> * Uber reports issues to github.com/ziglang/zig and pings Loris.
> * Loris assigns it to someone in ZSF.
> * Hack hack hack hack hack.
> * When done, Loris enters the number of hours worked on the issue.
>
> 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.Unless the reported bugs are not really bugs or the reports of of very low quality there appears to be little downside for what could potentially pay for a full-time dev.
It's closer to the cost of a part-time developer for a full year.
Though I guess including it inline would have been nicer for the readers.
They were paying customers for SPIFFE and SPIRE support when Scytale was an independent company as well
This beef applies to both commercial vendors using corporate logos on their "customers" pages, as well as open source projects wanting to hype up their community.
Why ?
Simple. $big_corp is BIG. I'm sure if you look hard enough you'll find all sorts of commercial and open-source technologies being used at $big_corp.
It doesn't mean they use it for critical functions or even any production functions.
And then when we start talking about "tech-savvy" $big_corp such as Uber, then its almost guaranteed they've got some devs sitting somewhere playing around with bleeding-edge tech .... but it still doesn't mean they are using it in production, or will be using it "soon" ... that tech might well get bored of X/Y/Z move on to the "next big thing".
Or they might deploy it to production but only in Beta test to select customers, or A/B testing to larger groups.
I do not, it is how you gauge if something has been tried and tested in production for example Go. It doesn't hurt whatsoever knowing that Go is used in production by Google in various high demand systems.
The more companies I see using a product in production, the more I can determine feasibility. I just wish more companies would have technical blogs to describe their experiences.
(emphasis mine)
Bit odd how you could miss the only point OP was trying to make. Yes, if you know that TECH_X is used in production at BIG_CORP_Y, it's very helpful. I can tell you that in the BIG_CORP I work for, we quite possibly use or have used any- and everything for something. The point OP was trying to make is: What is that something?
Nail. Head.
If you want a one-liner to summarise my post, this is it.
FAANG size company can use in production much less mature software than most small companies. If they want to use X they don't need to wait when X will be mature - they can make it so for the use cases they have (which may differ from the use-cases you have). They can hire an X expert or dedicate a few engineers who will learn X and become X experts. Even if they will encounter a problem in production (not every bug can be prevented by pre-prod testing) these engineers will debug and fix it and with the help of CI/CD pipeline the fix will be in production in a few hours or days at most.
What would a smallish company do in a similar case - report a bug to developers and hope it will be fixed and the fix will be included in the next release which will arrive as an OS package / Docker image several months later.
Ah yes. The famous "Nobody got fired for buying IBM" school of purchasing.
As to whether that's enough to justify for making a fuss about it, it's up to you, but you can't do that analysis if you stop at the title.
On top of all of that, the blog post and talk are about the journey that the author went trough to bring an unproven technology into their company and I think it deserves to be appreciated in a more nuanced way than a logo on a web page.
They use zig to compile go code transpiled to C is what I got out of it.
Not really sure why they don’t throw some money at go so it could pin the glibc version it compiles against as that seems to be the stated problem.
I certainly would love to see this become equally easy in other languages / with standard toolchains. I write a lot of Rust. I have one program in particular that I'd like to make a one-binary install that works on old glibc versions. My program uses glibc both through Rust's std and through a C library (SQLite) it compiles/links in. I'd prefer to just throw a glibc version in my Cargo.toml and have cross compiling Just Work, rather building within a Docker container with an old glibc version, or having to install both Rust and Zig toolchains, or the like.
I personally take every company's website that lists all their business divisions and all their clients separately without actually listing projects with a huge grain of salt. If you can't at least make a press release about a project, then what's even the point of listing those clients for those projects?
Well, in this case, they describe quite well how they use it...
Zig is the most productive I've ever been with a systems programming language. I've never been less frustrated dealing pointers and allocation in my life.
Quick glance at Zig, it supports the kind of metaprogramming I always wanted in C++! Looks like regular code but guarantees to not typecheck the paths that can't be taken. Also has reflection! And since generic types are created like any other struct, you can write that metaprogramming like normal code as well!
If it works as advertised then you could implement your own type constraints and type checking as regular code for those types, I always wanted to do that. Then I can implement compile time type constraints and type checking to see what the type supports and pick implementation based on that, or throw an error if the interface is passed some invalid type etc. This should make the code ultimately safer than even rust if you master this style of coding as you can move so much checking to compile time.
What are the main problems with the language? This sounds great, just wanna hear what the drawbacks are.
This means that you will not find super complete introductory materials about every aspect of programming with Zig. The language reference is very good but for example the standard library doesn't have docs yet as we're still working on the autodoc tool. On the other hand reading the stdlib source code is very easy in good part thanks to the reasons you already mentioned in your post.
https://github.com/ziglang/zig/wiki/How-to-read-the-standard...
You might also be interested in reading about the project to see if you like where we're going (aside from technical details of the language).
https://kristoff.it/blog/zig-new-relationship-llvm/ https://kristoff.it/blog/maintain-it-with-zig/ https://kristoff.it/blog/interfacing-with-zig/ https://www.youtube.com/watch?v=AqDdWEiSwMM
You can find links to learning materials in the "learn" section of the official website:
Last but not least, at the moment we compensate the lack of learning materials by having a community that it's very good at helping newcomers, so make sure you join one of the communities.
I'm ignorant to the history here, but GCC includes Fortran, Ada, and D compilers, right? I don't see widespread adoption of those…
Took a while to get thumbs-up to publish the talk. Happy to answer questions, if any.
You might consider adding "toolchain" to the title.
Will not change it now though, as this blog post is the last piece of this talk+announcement effort.
Can you explain at a higher level why Uber has the need to go to such a lower level with its programming? What services need the kind of speed that Go, Zig, and the like provide in particular? I guess I was kind of surprised to see a conversation about low-level compilation of programs being super related to Uber's core mission(s)?
Most of the services benefit from speed/efficiency of Go: the more effective the language (runtime) is, the less we pay for hosting it, the cheaper the service to the customers.
Given that, the GC costs are still significant. Depends what you compare against.
I can recommend Bazel for C/C++. If you’re doing Rust or something you’ve already got a pretty good build story and maybe Bazel isn’t worth the trouble. But CMake is a nightmare, and it goes downhill from there. If you’re stuck learning a tricky build system with spotty docs, Bazel at least makes it worth your while.
> "Uber does not have any plans to use zig-the-language yet."
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Emphasis mine
here is archive: https://web.archive.org/web/20220523131231/https://jakstys.l...
Edit: not DNS. Starting a restart-in-a-loop for now. Thanks for flagging.
Will not take this down.
I would say that Uber uses the Zig toolchain, title is a bit misleading as I thought that Uber uses Zig (the language)
edit: I just realized that maybe you were referring to the HN title. The real title is "How Uber Uses Zig" but HN cut the "How", making the title seem a stronger statement that what it's intended to be.
You seem a bit confrontational considering your role.
The Uber title would have been more clear if it said "How Uber Uses zig(1)". No, I don't expect capital-Z Zig to mean the compiler but not the language itself.
IMHO, you'd be wise to consider this paragraph avgcorrection wrote:
> You seem a bit confrontational considering your role.
Not everyone opening up an article on HN will have the context you do that Zig is an experimental language, that it has a toolchain that can do this, etc. Maybe look at how you can work on that rather than say stuff like "The title is as misleading as you want it to be"?
All this stuff is mentioned in the blog post itself, some of it even in the opening TLDR.
Yes. And...it was a surprise, people found the blog post's contents inconsistent with the HN title "Uber Uses Zig". People identify Zig as the language, not the toolchain, in part for the reasons I just described. You mentioned the website describes the toolchain, but I don't think it did it as well as it could.
As the VP of community for Zig, do you want to be telling everyone on HN that they're wrong? Or do you want to be welcoming, to build a Zig website that helps people quickly understand what Zig is, etc.?
https://twitter.com/croloris/status/1528807119402713088
> Peak american culture when HN commenters only read the title of a submission and act surprised when you refuse to spoonfeed them information present in the second paragraph of the linked article."
For the record if the complaint is about me, I did read the blog post before commenting, and I happened to already have the context that Zig has a nice C toolchain. But I'm stunned that someone with that title is responding in this way to people who are surprised about that and saying Zig's website points it out, when it really doesn't very well. And then generalize to complaining about American culture. That escalated quickly...talk about alienating.
Yes, easily. If Uber has a reputation for valuing stability over new shiny tech, I've never head it.
Any kind of business operating at these many places, having to deal with local laws, tax and payment processing in each one of them would require a huge and constant engineering effort.
That kind of stuff used to involve a bunch of planning, now I just open an app and I immediately get a decent estimation of time needed and price to get to my destination, all over the world. I don't find it so surprising that there is a bunch of complexity involved there.
I was very surprised too. So much complexity must slow them down a lot.
You can really say this about almost anything once it's established. A startup can seemingly get really far with just a handful of people, but that startup is undoubtedly also dealing with only a handful of the use cases and edge cases. They also don't have legacy to maintain and upgrade. They also don't have all of the issues of scale.
Couple that with the fact that as outsiders we likely only see a tiny fraction of what the system ultimately needs to deal with.
I'd get this sort of feedback here whenever talking about Khan Academy's work, so I ended up blogging about it to give a sense of how much more there is than what people think about: https://www.kevindangoor.com/posts/why-khan-academy-has-so-m...
It's also a food buying marketplace with, a package, grocery and meal delivery service.
There's also their autonomous research division.
Plus even with just the ride hailing service, they have tons of things that require engineering like load balancing of their drivers to requests in an area, and predictions for pricing and route timing.
There's also the whole messaging component to it.
It's a lot more complex of a company than it appears on the surface.
Fyi... have you already seen the famous Uber engineer comment on the complexity of the app?
https://news.ycombinator.com/item?id=25376346
As a case study, the simpler non-profit RideAustin app fails customers even after Uber/Lyft left Austin: https://techcrunch.com/2017/03/12/austin-is-fine-without-ube...
It takes a lot of money and engineer salaries to make high-demand apps that work. That's not to say Uber staffing isn't bloated; they may be. That doesn't change the fact that armchair observers may still drastically underestimate how many hundreds (or thousands) of programmers it requires to build something equivalent.
Not sure why Uber needs so many people in silicon valley when apparently you can build an equivalent service with a few hundred people in Estonia costing 1/10 per head.
> It genuinely blows my mind anyone who has written software couldn't have guessed at all of this from the beginning.
Classic. People cannot comprehend why it is complex and others cannot comprehend why it would not be complex!