> 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.
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?
Is this really true? We learned about generics in college so I assumed that everyone knew it (especially if they work at Google).
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).
https://github.com/kubernetes/kubernetes/blob/master/pkg/con...
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.
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.
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.
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.
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.
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.
Google is now IBM 25 years ago or so.
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
> 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.
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.
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.
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().