How Uber Uses Zig(jakstys.lt)
jakstys.lt
How Uber Uses Zig
https://jakstys.lt/2022/how-uber-uses-zig/
116 comments
I don't know about such deals, but isn't 52k like nothing for such agreement? It's close to free support.
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.Does this mean 52k upfront + (hour rate) * hours? If not, how much "time" of ZSF does Uber own?
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.
It's closer to the cost of a part-time developer for a full year.
It's a 52k bonus for basically doing what you're already doing.
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.
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 is $52k to prioritize bugs which Uber reports to be impacted by, ahead of other bugs
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).
The amount is in a screenshot in the article itself with the subtitle "The amount of money that changed hands is public, because ZSF is a nonprofit."
There was a screenshot towards the bottom of the article which showed the figure(s) so that wasn't really excluded.
Though I guess including it inline would have been nicer for the readers.
Though I guess including it inline would have been nicer for the readers.
People don’t bring Uber their flowers for actually supporting OSS with their dollars.
They were paying customers for SPIFFE and SPIRE support when Scytale was an independent company as well
They were paying customers for SPIFFE and SPIRE support when Scytale was an independent company as well
[deleted](1)
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.
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.
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?
(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?
> 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.
Nail. Head.
If you want a one-liner to summarise my post, this is it.
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.
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.
In this case the article is clear that Uber is moving their entire C/C++ build chain to this technology. It’s clearly not a small side project!
We are though. Look for "Timeline of 2022 so far" for the current status, and what our production rollout plans for 2022 are.
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).
> It helps senior purchasing managers to defend their decision to ....
Ah yes. The famous "Nobody got fired for buying IBM" school of purchasing.
Ah yes. The famous "Nobody got fired for buying IBM" school of purchasing.
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.
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.
I read the article and am still confused.
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.
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.
"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 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.
>It doesn't mean they use it for critical functions or even any production functions.
Well, in this case, they describe quite well how they use it...
Well, in this case, they describe quite well how they use it...
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?
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.
hehe, I (and a handful of colleagues at the time) were the "Haskell at JPMorgan" crew, so giggle about X tech at Y org discussions generally :)
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.
We have a commercial relationship with every company in our top banner.
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.
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.
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.
The worst part is that it's not done yet :^)
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:
https://ziglang.org/learn/
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.
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:
https://ziglang.org/learn/
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.
I have almost no systems programming experience, but I'm curious, how is it better than Rust?
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.
Couldn't have written it better myself - you hit the nail on the head.
The easiest way to put it is to just install/set up both languages, and jump into definitions of random stdlib functions.
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.
Maybe. Or the language will fall into obscurity and everyone will just use the C compiler.
I'm ignorant to the history here, but GCC includes Fortran, Ada, and D compilers, right? I don't see widespread adoption of those…
I'm ignorant to the history here, but GCC includes Fortran, Ada, and D compilers, right? I don't see widespread adoption of those…
Obscurity depends on how closely you're looking. In fluid dynamics (meteorology, atmospheric sciences) and other scientific fields, Fortran definitely sees widespread adoption.
And Ada is widely used in aerospace. Less these days for new projects, but often enough that one needs to be familiar with it.
Author here.
Took a while to get thumbs-up to publish the talk. Happy to answer questions, if any.
Took a while to get thumbs-up to publish the talk. Happy to answer questions, if any.
I agree with a sibling comment: when I read "Zig" I assumed the language.
You might consider adding "toolchain" to the title.
You might consider adding "toolchain" to the title.
Good suggestion, though the title of my original talk (in the linked video) was even less assuming: "How Zig is used at Uber".
Will not change it now though, as this blog post is the last piece of this talk+announcement effort.
Will not change it now though, as this blog post is the last piece of this talk+announcement effort.
I'm actually somewhat glad I got "baited" into watching it. I don't think I would have been as likely to watch it had it included toolchain.
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)?
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.
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.
Two words: vertical integration.
pip install ziglang
https://github.com/ziglang/zig-pypi
https://github.com/ziglang/zig-pypi
[deleted]
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 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.
Great post. It's shocking to discover that the lead developer of Zig only earns 1500$ a month, and still manages to donate 10% to the musl project: https://andrewkelley.me/post/why-donating-to-musl-libc-proje...
A word of caution: Uber uses `zig cc` toolchain to compile C/C++ code, not Zig language. Moreover, from the article itself:
> "Uber does not have any plans to use zig-the-language yet."
> "Uber does not have any plans to use zig-the-language yet."
Title is a bit misleading, since they're not actually using Zig the language.
https://ziglang.org/
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Emphasis mine
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Emphasis mine
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 author works at Uber, that line means that its just his personal blog and that his opinions are not necessarily the same as Uber's.
[deleted]
I was getting a 404. taken down?
here is archive: https://web.archive.org/web/20220523131231/https://jakstys.l...
here is archive: https://web.archive.org/web/20220523131231/https://jakstys.l...
DNS. Looking.
Edit: not DNS. Starting a restart-in-a-loop for now. Thanks for flagging.
Will not take this down.
Edit: not DNS. Starting a restart-in-a-loop for now. Thanks for flagging.
Will not take this down.
> Uber does not have any plans to use zig-the-language yet.
I would say that Uber uses the Zig toolchain, title is a bit misleading as I thought that Uber uses Zig (the language)
I would say that Uber uses the Zig toolchain, title is a bit misleading as I thought that Uber uses Zig (the language)
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.
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.
> Zig (the language) is famous for not being yet stable, did you really expect Uber to use it in production?
Yes, easily. If Uber has a reputation for valuing stability over new shiny tech, I've never head it.
Yes, easily. If Uber has a reputation for valuing stability over new shiny tech, I've never head it.
> 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.
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.
Zig is a programming language and toolchain, it's on the website. Uber is not only using the compiler but also the linker.
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"?
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.
> 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.?
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.?
You are being unnecessarily antagonistic.
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.
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.
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.
I wonder what nationality one is supposed to associate with talking behind people's back in public.
I hate HN's automatic title parsing. I get offended every time I post something and the title is automatically converted to something unintended.
haha its hilarious but true that zig is really an amazing c compiler build system that happens to include an alternative safer c like language.
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?
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.
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.
from that thread ...
> 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!
> 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!
It's hard to fathom how people can think software like Uber is not complex. I have to assume they've never worked in a large software company before.
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.
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'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...
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...
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.
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.
https://www.uber.com/global/en/cities
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.
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.
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.
Autonomous research division is gone, right?
> Our Go Monorepo is larger than Linux kernel, and worked on by a couple of thousand engineers. In short, it’s big.
I was very surprised too. So much complexity must slow them down a lot.
I was very surprised too. So much complexity must slow them down a lot.
This is like saying: Why Google need to hire so many engineers? It's just a single search field.
The user facing part of the technology behind such a company is just a fragment of the whole puzzle
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.
Having worked briefly for Grab, I can comprehend it.
[deleted]
tomatowurst(1)
Here is what I could find:
Great work! Keep it up Zig community.
(edit for formatting only)