No, Google employs far too many developers for the median to be close to 'elite'. I'm sure there are elite teams at Google, but I very much doubt the average Googler is, and that's probably been the case for a decade at this point. The famous Rob Pike quote sums it up quite well:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software.
I think Rob Pike's commentary on Go is why I decided to go into research. Google hires kilotons of developers and pays them gigadollars every year, then makes them work in dumbed-down languages because they can't be trusted with power tools.
How has our industry gone so far astray that we pay people hundreds of thousands of dollars a year when they can't even understand generics? In what universe does it make sense to design an entire new language rather than offering new hires two months of training? Why are we pretending programming is a skilled trade when the things people actually wind up doing are so easy they can be learned in three months at a boot camp?
Rob Pike is a legend. He is the man who brought us Plan 9. How is this what he wound up working on?
Professionals with many years of experience could and would still make mistakes with C and C++. And many mistakes are very costly at Google's scale.
Wanting to make the situation better through a simpler, safer fit-for-purpose tool doesn't mean an industry is flawed anymore than the prevalence of sawstops means that carpentry is flawed.
Generics nothing more or less than a safety feature. Right now code that would use generics instead use the empty interface instead, which is effectively opting out of the type system entirely.
I'm personally ambivalent on whether go adds generics or not but framing a lack of generics as a safety feature is the most absurd thing I've heard today.
Go makes concurrency easier (sorta) and eliminates some memory safety issues. But if you want a tool that helps you write more correct programs, you really need a much stronger type system than Go offers.
Holy spin. Rob Pike was explicitly talking about young inexperienced programmers who are 'not capable of understanding a brilliant language.' He wasn't talking about experienced developers and made that as clear as he possibly could. Go is made simple for novices, not safe for veterans.
You don't really get a choice when you decide you're going to write a project in a language. Senior devs will be required to work in the same language as the junior devs.
Go is not a particularly safe tool. It is a simple tool. That isn't the same thing. Sophisticated type systems are designed to improve safety at the expense of adding abstraction.
The skills the median google engineer needs can absolutely be learned in three months at a boot camp but simultaneously those skills are worth a million a year to google. There's massive returns to scale of the infrastructure for effective software development, but very few organisations have figured it out.
> then makes them work in dumbed-down languages because they can't be trusted with power tools.
The languages are “dumbed” down so that the resulting code is intelligible to those that work on the system, so that the code is communication.
Overly smart tools allow a smart person to make mistakes so complicated that nobody can fix it (even themselves). Or a smart person builds great solutions so complex that nobody else can work on the code.
A good engineer chooses restrictions that help themselves and others build better solutions that a team can work on.
Just because a language focuses on simplicity does not automatically make it bad. People use Go to solve complex issues, so it makes total sense none of that working memory should be occupied with understanding language features, even if they're as simple as generics.
A more extreme way to write Go is "space shuttle style" Code, as used in the Kubernetes Volume Controller, a radically different approach to "I want all my complex features that I can use to shoot myself in the foot".
You might be able to handle a firearm, but we have plenty of injuries and deaths through mishandled firearms every year, don't think you're exempt from that (or if you insist, at least do not talk down the need for safety).
I assume it is hyperbolic. The OP clearly has issue with the Go language. The rant contains the common misunderstandings about it (no generics, must be bad), etc. Go has survived 11 years without generics (they might be coming) and underpins some of the most popular software out there. Clearly, it has something going for it. Pike and Google understand generics, but generics have pitfalls. So when Pike and co decided to design a new language, they took lessons from the years of history, rather than repeating the same mistakes. Go is a language that is easy for people to learn, but more importantly, get right. It is just as powerful as virtually any other language out there, so caters to the advanced programmer as well. Those attributes are something not a lot of languages can legitimately claim. And people, for some reason, get really upset about it. shrugs. I say kudos to someone for building a language that isn't a research project that crammed every possible "cool" concept in. I like learning languages and would rather appreciate them for what they are than whether they have X thing. If X thing is big enough to be a problem, then I don't use the language, simple. No need to get all worked up about it and post rants on unrelated articles.
As someone else noted, I am taking a swing at Go's lack of generics.
More to the point, I am criticizing the reason for that. Designing a simple language is fine. I like simple languages a lot. Go was designed not because simple languages are good for some jobs but because Google decided their engineers aren't up to using more powerful tools.
I don't know Go. I've only written about 200 lines of it. I don't pretend to know whether or not it's any good. What I do know is that the reasoning behind it is bizarre to me.
/Google decided their engineers aren't up to using more powerful tools./
I think you fundamentally misunderstand the reason for using Go. It's NOT about whether a developer is/isn't capable of understanding how to write code with a particular set of tools.
Instead, it's almost entirely about making that code simple to read and understand at a later date. Complex/'powerful' language tools complicate reading, which slows down later fixes and small modifications at best, and at worst leads to additional bugs in later iterations over the code. Thus, the core belief in Go's design is that 'powerful' languages are optimizing for entirely the wrong things.
From my perspective, this is a good change of focus. I want simple tools that I don't have to worry about. We have finite attention, so we should actively try to reduce cognitive load whenever possible, as it frees up attention for other things. For example, it's a much better use of my time to think about bayesian optimization than whether an array pointer is being safely handled... If I need to worry less about the latter, I have more time to think about the former.
> More to the point, I am criticizing the reason for that.
Go's lack of generics is not due to ideological reasons. The designers are not particularly against them and are open to adding them given a good proposal. They always said that generics may well be added at some point.
> doesn't google employ the elite of world programming?
Yes, some of them. But they are few and far between the tens of thousands of devs now that just glue services together with grpc and protos. The Google that produced cool shit just 7 years ago has grown like 10x in employees. Additionally, any engineer that has stayed that long is a millionaire several times over in stock and is very unlikely bothering with anything as boring as the embedded youtube player.
Did you completely miss the memo on google duplex, tensorflow, kubernetes, etc?
G is still way more technologically advanced than any other top tech company, and is currently positioned at the top of the AI research ladder in many (if not all) sub disciplines
Yeah, you’ve just described IBM 25 years ago. Lots of pockets of innovation in a sea of mediocrity. It wasn’t even that long ago that IBM was considered a top 5 company in cloud, AI, and quantum computing.
> G is still way more technologically advanced than any other top tech company
That’s a senseless statement. Google has lots of nice tooling for developers and managing their infrastructure, but that doesn’t make them the most “technologically advanced”. They use a mono-repo for a ton of stuff, most shit is boring grpc calls and regular database lookups. There is nothing on the leading edge of the crypto/blockchain world, there isn’t anything particularly interesting in p2p, etc.
> Did you completely miss the memo on google duplex, tensorflow, kubernetes, etc?
It’s funny you should mention kubernetes since most of the innovation there comes from outside of Google. Look at who is driving ebpf networking adoption, etc.
You’re right though that Google is currently an AI leader. But again, that’s <1% of their engineering workforce. When I left a few years back most people were working on simple shit resting and vesting. It’s an incredible place to retire in place, but that will eventually catch up with them and it’s bad for career development as a SWE.
Most bugs happen at the boundaries between what different people are working on. They're often process and architecture issues rather than programming issues. Security bugs often have this flavor.
This seems something trivial to miss. The developer is asked to put the player into a page that has basically just the player and exposes and API. The API should allow playing videos and playlists. They do the obvious thing and it all works.
The fact is that the security here wasn't the default. They need to explicitly realize that this allows the website to list playlists and consider that this should not allow listing the playlist with the user's credentials.
This seems like an incredibly likely vulnerability to me and I am not surprised that even "elite" programmers missed it.
> This seems like an incredibly likely vulnerability to me and I am not surprised that even "elite" programmers missed it.
Was that a typo? Seems to me it should be an incredibly UNlikely vulnerability for "elite" programmers to miss it. If you meant that as written I don't understand it; please explain.
Probably due to the scale they're operating at. Maybe there were parts of things that didn't have such a vulnerability alone but did when put together. Maybe there isn't a clear owner of the code so no one felt responsible to find and patch such a thing. Maybe the entire system is too complex for one or even a small team of developers to grok so things can easily slip through the cracks from time to time.
I've learned to be suspicious of someone's reputation when I don't know what they've done to earn it. Everyone thinks Google employs the best engineers on the planet, but I suspect the reason most people believe that is just that everyone else does. How many people have actually come to believe that because they've done their homework?
Google is an ad company. Their entire business model is based around manipulating public opinion. Don't trust a word you hear about them.
Decide for yourself. Do the products Google makes look like they are made by the best engineers in the world? In my case, the answer is a resounding no.
>Thankfully, YouTube has a solution for this as well, the YouTube Player API. This API allows you to just add a JS library to your site, and then simply create/modify/control the YouTube players on your site however you’d like, using JavaScript. For example, if you want to pause a video, you can just call player.pauseVideo().
