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?

> 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.

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.

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.

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.

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.

"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.

>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...

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.

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.