This is cool. I don't know why the author wrote <<Uber signed a support agreement with Zig Software Foundation (ZSF) to prioritize bug fixes. The contract value is disclosed in the ZSF financial reports.>> ... but did not provide the amount.
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
The contract details are outlined in the blog post. Depending on the number of hours worked to fix some issues, it is likely fair.
> 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.
Considering that most companies give zero, nada, shit, to open source projects they heavily use and even base their systems on, no it's not "close to free".
It's closer to the cost of a part-time developer for a full year.
Exact. It is money to fix bugs. Presumably these bugs would be desirable to fix anyways, this just changes the priority.
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 impossible to tell without details of what the support agreement includes. My large company has support contracts with a lot of vendors, and many of them are for way less than $52k
Honestly, I'm not sure, but it is a worthy question. I quickly searched that doc: It is the only "Support Contract" entry. I sincerely hope they get more.
Presumably that depends on how support that contract covers, and over what time period. If it covers 1 hour/month over a monthly time period it's a huge amount. If it cover 40 hours/month over a yearly time period then it's a pretty small amount given the usual rates for such services (although still more than some people make for that amount of work).
I have beef with people who boast $big_corp uses X/Y/Z.
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.
Having reference customers that are willing to be publicly associated with your product is one of the most important tools in the product marketing toolbox. It's not meant for you as a consumer, but rather for the decision-makers/buyers at similar organizations.
> I have beef with people who boast $big_corp uses X/Y/Z.
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.
> doesn't hurt whatsoever knowing that Go is used in productio by Google in various high demand systems.
(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?
Considering the context of the original comment: a top-level comment on an article that details exactly how Zig is used at Uber, it's understandable that people misunderstood.
In the case of Google it is Go's built-in web server was good enough to handle workloads that any smaller company wouldn't come close to a Google tier web load. I get what was meant, I guess I should of elaborated why I chose Go as an example.
> I do not, it is how you gauge if something has been tried and tested in production
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.
I think the big difference here is the "How". In general, I'd agree, but the article seemed pretty honest that this was a small project (in manpower, not necessarily scope); yet they did everything right by supporting the project. It was also honest about not using the language, but its tools.
It helps senior purchasing managers to defend their decision to even more senior managers (many non-technical) to pay a relative unknown name a biggish sum of money for their product (or support).
Even so, plenty of people were still willing to buy from established IBM competitors during that era. There's a difference between that and buying from someone no one in the C-suite has ever heard of, which is where `zig` is currently.
You should read the full post or watch the video, even the TLDR at the top of the blog post would have clarified exactly what is the scope in which Uber is using Zig.
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.
"CGo" is a FFI technique for Go code to call into C. My read is that they haven't transpiled any Go to C; they're compiling and linking a mixed Go+C program. And IIRC, Go on Linux makes direct syscalls rather than using libc, so the need to pin glibc versions is exclusively on the C side. That's probably why the Go folks haven't invested much effort into it. I don't know if there's anyone you could throw money at who would get glibc pinning for CGo implemented and merged.
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 get what you're saying. I know of a few digital agencies that list every client they've ever worked with, but not list what actual projects they worked on. In a huge number of cases, those projects were almost inconsequential. One in particular at which I previously worked has a website all about game development and VR, because they aspirationally want to work on those things, but all of their actual work has been tiny RoR marketing pages that a friend-of-a-friend farmed out to them as a favor. It disingenuously makes it seem like they built full VR apps for those clients.
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?
Which is why if I'm spending more than 10-20k for a technical product, I ask for customer references to speak with - unless the product is already widely used and well-known. If a company can't provide references in the context of an "enterprise sale" they aren't worth your time.
Whats even worse is when vendors do this without even having any affiliation with the companies they are name dropping.
Example: planetscale.com "Trusted by Github, Square, Soundcloud...)" just because they are using the same open source database.
I was thinking as I read that comment that it seemed unlikely you would not only (1) attempt to use companies' logos without their permission and without accurately representing the relationship, but also (2) get away with it
It is often in the contract or in the general terms of the commercial agreement so you have to watch out what you are signing. Especially if you work at a company which is somewhat known in the industry - the sales departments of SaaS companies start acting like sharks just because you use their product for some niche use-case on which the business doesn't really depend.
In classic HN fashion, I will sidestep the content of the article and just say...
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.
I strongly agree. I thought I would have this same feeling with Rust way back when I first learned about it, but the more I use Zig and Rust, the more I prefer the former for systems programming
Sounds great, maybe I should take a look at zig. Rust feels too much like a data processing language instead of a systems language.
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.
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 can't wait to see Zig become better in the embedded world. Anything to avoid having to write more C would make me happy. Until that time, Nim is my go-to, and it's quite nice as well for similar but different reasons. I think they both have their place.
Rust definitely has a steeper learning curve, and sometimes it forces you into designs that may or may not be your preferred choice. (Typically your data ownership diagram in Rust needs to look like a tree with no cycles.) Many folks who learn Rust eventually feel like "the compiler was right all along", but not everyone feels that way, and the time investment to get to that point can be a lot.
This really shows the genius of `zig cc`: companies adopting the toolchain will have a much easier time adopting the language too in the years to come.
Obscurity depends on how closely you're looking. In fluid dynamics (meteorology, atmospheric sciences) and other scientific fields, Fortran definitely sees widespread adoption.
Thanks for publishing this, it was an interesting look into the topic!
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)?
Some services span many many hosts (not sure I can say how many though). Not because they are inefficient; that's because it takes many cpus to do to support our trips/eaters/etc.
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.
Appreciate the answer. In hindsight do you think any solutions could have been purchased that the company "rolled" itself? Was it necessary to create such a huge engineering organization and deep level of technology for what's essentially a ride hailing and food delivery company, or was it more needed to burnish the company's image to investors as a "technology company"? I don't mean to offend with this question, I'm just honestly curious.
I will have to look at “zig cc”. Right now I’m using NixOS for this, but more options never hurts.
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.
I recall reading https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... as well and thinking this would be great to integrate with Bazel for hermetic cross-compile of go/cgo. Great to see they actually went and did it! Will definitely be trying this.
Yeah, it seems odd to me that the title is "How Uber Uses Zig" but the first line of the page literally says "this blog post is not affiliated with Uber"...
The title is as misleading as you want it to be, Zig (the language) is famous for not being yet stable, did you really expect Uber to use it in production?
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.
> The title is as misleading as you want it to be, Zig (the language) is famous for not being yet stable, did you really expect Uber to use it in production?
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.
I'd expect most people to read "Zig is a general-purpose programming language and toolchain" as saying Zig has a toolchain for compiling itself, which is unremarkable. The idea that an experimental language's toolchain might be superior at (cross-)compiling and linking C than gcc or clang is not obvious and isn't described that well on the front page. I see the "Maintain it with Zig" section has a bullet point about this, but it's not that prominent IMHO and doesn't say why. I heard elsewhere how great Zig is for cross-compiling C. (Easily targeting arbitrary glibc versions is a great feature!)
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"?
> 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.
> 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.?
If you say so. Fortunately I'm not in charge of community relations. Looks like the person who is just took to twitter to complain, generalizing this discussion to American culture.
> 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.
I still find it hard to comprehend how a one of the tools of a taxi calling app has this much complexity and have thousands of engineers working on it . It surely must solve a difficult technical problem but I suspect the business impact is minimal as these apps were able to become widely successful initially without this level of complexity
>I still find it hard to comprehend how a one of the tools of a taxi calling app has this much complexity and have thousands of engineers working on it .
Fyi... have you already seen the famous Uber engineer comment on the complexity of the app?
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.
Bolt (Taxify) built a similar service with a few hundred people and has now taken a significant market share in Europe. At least the people I talk to recommend taking bolt over uber since it is the same service but cheaper. It has a map and you can see where you are live etc, and it schedules rides intelligently so you can get a ride with a car that is full but is about to drop off near you, just like uber.
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.
> I still find it hard to comprehend how a one of the tools of a taxi calling app has this much complexity and have thousands of engineers working on it
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 guess it is just a taxi calling app, but I have to say that for me personally, Uber has become a very useful tool because I can just instantly get wherever I need to go whenever I travel to a new place I've never been before. I hardly ever use Uber in my home city, but when I travel I use it all the time.
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.
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.
To be fair to them, Uber is more than just a ride hailing service.
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.
have you worked at a large tech company before? there are so many opportunities for micro-optimization that, if they pay for themselves, are worth hiring for.
This is why I tend to follow the project's Twitter account and NOT the authors. Authors are humans with human opinions. Some folks seem more hellbent on USING their project's popularity to spread their views... but, I don't think I've ever seen a project's Twitter retweet the author (it's usually the other way around).
> ...immediately....
Really?
You might want breath a little bit and then relook at Zig. If you've got C code and you're stuck with it, Zig might be the "C" girl that got way!
Here is what I could find:
Great work! Keep it up Zig community.(edit for formatting only)