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