399todsacerdoti2375/11/2025, 3:01:56 AM airs.com ↗
Comments (237)
egl2020 · 6h ago
When I worked at Google, Ian Lance Taylor was in the pool of randomly assigned code reviewers. He was polite, firm, and informative. It speaks well of Taylor and the project that he was doing this kind of review--- it's a version of the YC advice about founders doing customer support.
And maybe I'm shallow, but it was a thrill to see his initials show up on my code reviews. Thanks for all your work on golang.
notepad0x90 · 6h ago
What a nice praise. It is refreshing to see someone being remembered as 'polite'. It is a critical life-lesson I've learned myself, it is better to be considered things like polite, kind and nice instead of smart, 10x <whatever>, capable.
caprock · 3h ago
I've found a lot of value in the habits of politeness, especially in written communication. It's disappointing when it's not a first class citizen in a company culture for things like code review. There are plenty of rationalizations for how it might not be needed, but that just feels like laziness.
ncruces · 5h ago
As an “insignificant” outside contributor to Go (I think I worked on half a dozen proposals and PRs), I can say just the same, even for things that in the end got dropped or rejected: polite, firm, informative; I'd add curious.
Had a great experience contributing to the project, and Ian was a big part of that. Which for a big project like Go says a lot.
henvic · 3h ago
Same!
aleksiy123 · 4h ago
I have something similar except it was Titus Winters on my final c++ readability change.
I tried to push back on one of his comments as well.
Imo it just feels kinda cool that someone who really really knows what they are doing gave you a stamp of approval on something.
jrockway · 5h ago
I also really enjoyed the Go readability process. It made me a much better programmer.
I did Python readability at Google and "take this one massive CL and if they make it good by the end of the process they're done" never felt quite as useful as Go's process. I'm glad they made their own rules; it benefited me. (Even if during the process I was thinking "I JUST NEED TO CHECK IN THIS CODE SO I CAN GO BACK TO BED" when getting paged in the middle of the night ;)
benesch · 17h ago
It’s hard to overstate the amount of service Ian provided to the Go community, and the programming community at large. In addition to gccgo, Ian wrote the gold linker, has blogged prolifically about compiler toolchains, and maintains huge swaths of the gcc codebase [0]. And probably much, much more that I’m not aware of.
I’ve had the pleasure of trading emails with Ian several times over the years. He’s been a real inspiration to me. Amidst whatever his responsibilities and priorities were at Google he always found time to respond to my emails and review my patches, and always with insightful feedback.
I have complicated feelings about the language that is Go, but I feel confident in saying the language will be worse off without Ian involved. The original Go team had strong Bell Labs vibes—a few folks who understood computers inside and out who did it all: as assembler, linker, two compilers, a language spec, a documentation generator, a build system, and a vast standard library. It has blander, corporate vibes now, as the language has become increasingly important to Google, and standard practices for scaling software projects have kicked in. Such is the natural course of things, I suppose. I suspect this cultural shift is what Ian alluded to in his message, though I am curious about the specific tipping point that led to his decision to leave.
Ian, I hope you take a well-deserved break, and I look forward to following whatever projects you pursue next.
It's very important for both the compiler tools chains of go to continue working well for redundancy and feature design validation purposes. However, I'm generally curious -- do people / organizations use gcc-go for some use cases ?
fweimer · 3h ago
GCC Go does not support generics, so it's currently not very useful.
sbochins · 5h ago
Back in 2016 when I was at google, I started on a team that was all golang. I was working on my first project, building out a new service and got many readability approvals from Ian. One time I got an an approval with some follow up requests, which I somehow didn’t notice and landed the change. He got back to me asking me to follow up. I didn’t realize he was one of the core Golang developers! He was super gracious, even though he didn’t need to be and I’ll always remember that. It’s really something that he invested so much time into seeing how the language was actually used and identifying core problems. Very admirable.
djha-skin · 4h ago
> ... Gooogle has changed, and Go has changed, and the overall computer programming environment has changed. It’s become clear over the last year or so that I am no longer a good fit for the Go project at Google. I have to move on.
I wish I had more elaboration on this paragraph. It seems like a real change happened of which Ian took notice.
mattlondon · 4h ago
Probably asked to make it more AI or something.
"Please add Gemini to the go compiler errors, or take a hike."
skirmish · 3h ago
Almost exactly what I heard, he was told (paraphrased) "for people at this level and pay, we expect them to be working full on time on AI".
YZF · 3h ago
Sad and not surprising. Presumably when you are in the US with US sized total compensation this is even more of a problem. It is also a sign that the technical buffer layer (people like directors, VP, CTO) is not functioning well and also points to issues with company vision and roadmap.
I don't think it's wrong per se to suggest that Google should not be in the business of "Go" e.g. but presumably there are many other areas where similar technical expertise can be used in this size of company.
That said I've seen good people get stuck in large companies. They are put in a certain bucket and find it very hard to change. Sometimes leaving is the correct answer.
As someone who switched to Go in its early days (from C++) and had some interaction with the community (bugs, conventions etc.) it's a little sad but I think also just the way things go.
bbarnett · 3h ago
I have yet to see a thing made better by LLMs.
I've seen things with more impressive results, but then interlaced with garbage results. Far less reliable is the outcome.
Whether it's the now horrible pixel camera app, search results, or really anything else, it's all garbage
Meanwhile, yay!, let's use a billion times the compute.
sashank_1509 · 3h ago
Wow talk about ridiculous. Hopefully this is not the case, I’m in Google and I don’t want to see it deteriorate to this point.
compiler-guy · 3h ago
If you are internal to Google, you can find his goodbye letter with a fair amount of additional detail. He chose not to make that additional detail public, so I won't either.
gwerbret · 2h ago
Without going into the aforementioned detail, would you say he burned his bridges on the way out?
compiler-guy · 2h ago
No.
RainyDayTmrw · 18h ago
> But Gooogle [sic] has changed, and Go has changed, and the overall computer programming environment has changed. It’s become clear over the last year or so that I am no longer a good fit for the Go project at Google. I have to move on.
That's kinda surprising to hear. I wonder what happened. It would have been easy to leave out these 3 sentences or replace them with fluff. The author choosing to write this out suggests that there is some weight here.
UncleMeat · 10h ago
I've seen a lot of high level engineers at Google leave over the past couple of years. There's vastly more pressure from management and much less trust. And a bunch of L7+ folks have been expected to shift to working on AI stuff to have "enough impact." The increased pressure has created a lot of turf wars among these folks, as it isn't enough to be a trusted steward but now you need your name at the top of the relevant docs (and not the names of your peers).
Prior to 2023 I pretty much only ever saw the L7s and L8s that I work with leave Google because there was an exciting new opportunity or because they were retiring. Now most of the people I see leave at this level are leaving because they are fed up with Google. It's a mess.
jnwatson · 5h ago
I think there's a simpler answer. Google has drastically slowed hiring. Less hiring means fewer natural opportunities for growth.
I joined in 2021. I feel like I caught the tail end of old Google. Any decent idea was greenlit.
Now, it is a lot harder to find resources to do things. (This is of course relative. It is still far easier than any other place I've worked at).
The company has transitioned into something a little more traditional.
UncleMeat · 3h ago
For at least some of the L7+ people I know who have left they weren't interested in growth (others I'm not certain). I know one person who left because they weren't able to get the VPs to greenlight their stuff and eventually got frustrated by it but I definitely know others who left because "continue to be a responsible steward for this large ecosystem that is important to Google's ongoing success" was no longer a viable path to sustained work (as opposed to promotion).
riku_iki · 1h ago
> Less hiring means fewer natural opportunities for growth.
IC's natural way of growth is to produce larger impact by solving harder problems, there are always hard unsolved problems which hold some business opportunities.
Balinares · 2h ago
I don't know what it's like right now, but around the time I left last year, it was a proper exodus. What a sorry waste.
babyent · 15h ago
What if I told you..
Most of the actual groundwork has already been laid by passionate, actual engineers.
Today big tech is just a place people go to make money, and they don’t necessarily care about long term vision.
Mostly filled with the most uninspiring, forced-to-do-kumon types who have little “passion” for engineering or computers. Zero imagination and outside the box thinking. Just rote memorization to get in and then getting PIP’d or laid off to go do the same at the other big corps. TC or GTFO types.
Better luck at startups that are the Google’s of yesteryear.
WWLink · 13h ago
I have never worked at google, but when I was in college 10+ years ago the allure was that they were making all kinds of cool new stuff, and they had enough money to not just pay you well, but they (could afford to) have 80/20 time where you could work on developing cool new stuff while on the clock!
But really, Google was cool. Google was hip. So was Apple. Lots of cool things were coming from those companies between 2000 and 2012 or so. My interest in Meta was similar - the reality labs projects seemed really cool when I looked into them back before all the giant cuts lol.
In addition to those things, these were all seen as companies run by engineers, where the software and the tech was seen as the big core thing the company cared about. People thought programmers at google weren't treated as "cost centers" like they often are at companies where software is just a piece of the puzzle.
But yea, times change. In a way a lot of it was just infatuation and dreams that may not have had a basis in reality.
johannes1234321 · 7h ago
> may not have had a basis in reality.
I believe there is a lot of reality. As well as they gave a lot of brilliant co-workers which seems to have made it a great place to spin ideas. Also from stories too leader ship was at least open to listen to criticism in "thanks God it's Friday" meetings.
While from observing some friends the promotion play was always tough as well. If you wanted to be promoted you always had to use your 20% time "wisely" which for some meant to still work on the main project. For other to strategically work on a side project they could use for the promotion panel.
Today's Google seem to be fully focused on numbers, where a lot of the spirit is gone. Back in the days when I visited some friends working for Google we went to Google for breakfast or met at Google for dinner as it was just a good place to hangout. (Which motivated people to stay at Google for more than their regular hours) Nowadays it seem to be more of a workplace.
FirmwareBurner · 7h ago
>Nowadays it seem to be more of a workplace
God forbid
pixl97 · 6h ago
I mean, if it's a production line that is one thing, but if you are looking for creative new products then don't expect much from them in the future.
FirmwareBurner · 4h ago
What's the alternative? Does having a daycare for highly paid adults to dick around all day create innovation? You can't force creativity out of people no matter how much you pay them or how well you treat them.
The web is way more mature right now than 20 or even 10 years ago. There's way lass untouched niches waiting to be filled by the new killer product. And Google already owns the search market, the ads market, the smartphone market, the email market, the browser market, the maps market, and soon maybe AI market, etc. What new untapped multi billion market is left for them to conquer? The pond is already fished out at this point. So of course most Googlers are gonna have to be factory workers keeping the factory running instead of dicking around creating new useless things that bring in maybe no significant revenue. The days of Google & Co. spending billions on pipe dreams is over for now.
Innovation is at start-ups which Google then buys because it has ad revenue. People go to work at Google because it pays well and less headaches than working at startups, not because they're gonna invent something new.
ok_dad · 2h ago
Some of my best work is done when I’m just dicking around.
FirmwareBurner · 2h ago
Can you share any examples? We're you dicking around and created a new database?
ok_dad · 1h ago
Just because it’s my best work doesn’t mean I created a database. I don’t work at Google so I don’t have access to their world class resources and knowledge. For me, my best work is furniture that I didn’t plan beforehand, I just had a general idea of the dimensions and purpose.
sofixa · 2h ago
> Does having a daycare for highly paid adults to dick around all day create innovation? You can't force creativity out of people no matter how much you pay them or how well you treat them
Google is proof that yes, it does create innovation. How many products and tools came out of people dicking around?
FirmwareBurner · 2h ago
That was many MANY years ago. I'm talking about today.
What new product has Google launched recently that it didn't cancel? Google's main money makers are all still products from 15-20 years ago.
Given all this it's proof that no, paying people to dick around doesn't generate more creativity once you peaked.
j7ake · 26m ago
Two people affiliated with Google won Nobel prize last year.
blitzar · 13h ago
20-30 years ago when you graduated if you wanted to get paid you targeted banks, accountancies or consultancies.
Now you go for big tech (and startups). The cliche of the young "banker" personality type is now the "tech" personality type, and is coming soon to an Ai startup near you.
asadotzler · 4h ago
Maybe 30-40 years ago it was finance, but by 1996 with the Netscape IPO, it was clear to anyone coming out of school (as I was then) that tech was the future and finance was already old and tired after 15 years of dominance.
There was a mad rush between mid-1997 and mid-2001 to get into tech, then the dot-com bust happened, but that only lasted about 2 years before things ramped up again. That was 20 years ago.
Suggesting that the first decade of the web didn't flip the bit from finance to tech is ahistorical.
absolutelastone · 1h ago
Their timeline sounds right to me. The dot com bubble was about big dreams but ended up with far less reality when stock options crashed to nothing. There was a finance bubble after the internet bubble and you could make a lot more money as a quant.
The big tech firms finally started doing RSU's insteda of stock options in the early 2000's, though most startups still were (and are) lagging way behind.
dmoy · 5h ago
I mean even today, if you really want to make a ton of money in software, you're still targeting finance stuff. Not banks, but like HRT or similar.
ryandrake · 5h ago
People really over exaggerate how much a rank-and-file software IC actually makes at these companies. Yea, they make a decent amount, but they're not casually making $2M bonuses like the investment banker types over at Goldman Sachs are, unless they are those rare outlier high-level employees. A lot of it might be stock, too, so their "good year" comp might be 3X to 4X their "bad year" comp.
People see their cousin's uncle's neighbor's roommate making $400K at Meta and just assume every single employee there makes that much. Or they point to those salary sharing sites where people self-report their best salary + highest possible bonus + equity as if every year was 2021, and think of them as representative.
orangecat · 4h ago
People see their cousin's uncle's neighbor's roommate making $400K at Meta and just assume every single employee there makes that much.
Every single employee, no. But the average L5 really does make over $300k in total compensation. Yes some of that is stock, but the companies are now stable enough so that doesn't cause a ton of variation.
dmoy · 3h ago
At Meta and L5, probably over $400k or $450k for the average eng.
I think it's true both ways:
A lot of people assume it's like finance money, but it's not.
And on the flip side there's a lot of people coming from normal company or startup land, and assume that the $400k + average performing L5 is a myth, when that's pretty typical for big tech.
And I definitely agree with sibling here: $300k or $400k is good money, but in a place where the median house costs $1.5 million or something insane like the parts of the bay area that have a <45 minute commute, it doesn't go as far as you'd think. And it's incredibly risky, because now you're tied to always getting that level of comp for decades or you'll get evicted. (And while $400k + L5 Meta comp may be typical at Meta, it's not exactly trivial to maintain, or nearly as relaxing as a software gig you can do at other companies)
fldskfjdslkfj · 1h ago
That's the avg initial comp package but the stock had a pretty nice run so a lot of people are making 600k++.
whiplash451 · 4h ago
I’ll be that guy, but $300k pre-tax at current cost of life is not an insane number at all.
alabastervlog · 3h ago
I both agree that $300k household income is roughly the bottom edge to support a Fussellian upper-middle lifestyle these days (and that edge is retreating upwards fast…), but also notice that it’s about 94th percentile for US household income.
Household. A married couple both making that are 98th percentile.
whiplash451 · 3h ago
Sure but less than 8% of Americans live in the top 10 most expensive cities.
In what percentile of your social class do you sit with $300k? Probably not very high.
blitzar · 3h ago
Said like a 1990's banker / a 2020's tech worker.
archagon · 2h ago
That’s silly. As a high-income FAANG engineer living in the heart of SF, I was easily able to save more than 70% of my money.
ldjkfkdsjnv · 3h ago
Another thing, is the number of engineers at HRT is not that many, and the number making > 600k is probably less than 2000. A miniscule amount
dmoy · 3h ago
Definitely true, yes. And it's insanely competitive to get in, and at some of the shops (e.g. Citadel), your work life balance has a giant lead weight on one end of the balance beam, with a vacuum attached that is actively sucking things from the other side down the ramp.
tmpz22 · 7h ago
I've always used the analogy of 90's Wall Street to explain the Tech industry behind the curtains. Our 2008 moment will be when society realizes AI is nothing but a tool for wealth transfer from what remains in the middle class to the top ultra wealthy.
We had a brief window in the mid 2010s when folks started to throw rocks at the tech buses where I thought people were starting to realize it. Around Bernie's presidential run - which makes sense because he preached wealth inequality. But somehow during COVID tech slithered back into everybody's good graces.
* I don't condone people throwing rocks at the buses for both the humanitarian reasons and the fact that few if any executive or social changes could result from that behavior. But it struck me as a microcosm of the prevailing sentiment towards technology workers.
evmaki · 2h ago
> AI is nothing but a tool for wealth transfer from what remains in the middle class to the top ultra wealthy.
Is that inherent to the technology, or is that just inherent to the way we've chosen to organize society? Really, any technological paradigm shift going back to the industrial revolution has mainly served to enrich a small few people and families, but that's not some immutable property of technology. Like you say, it's a tool. We've chosen (or allowed) it to be wielded toward one end rather than another. I can smash my neighbor's head in with a hammer, or I can build a home with it.
At one point in the United States, there was political will to update our social structures so that the fruits of technological and economic progress did not go disproportionately to one class of society (think early 20th century trust busting, or the New Deal coming out of the Great Depression). I'm afraid we find ourselves with a similar set of problems, yet the political will to create some other reality beyond further wealth concentration seems to be limited.
spacemadness · 5h ago
Tech provided some means to stay connected during that time, so it’s not surprising. People felt even more disconnected initially and extroverts were not getting their needs met as easily. However I think the added exposure to algorithmic feeds caused an acceleration of social decay and a growing disenchantment with social media in some camps.
ayrtondesozzla · 5h ago
> AI is nothing but a tool for wealth transfer from what remains in the middle class to the top ultra wealthy.
Refreshing to hear that stated so clearly.
On your general point, I don't know if I feel the same optimism at this stage, much as I'd love to be proven wrong. Populations seem to never tire of jumping from one tech fairy tale to the next.
Developers seem to never tire of burying their head in the sand either, and I sometimes wonder if the two are correlated.
Why do you think this recent AI push will be the straw that breaks the camel's back? What if the camel just keeps plodding along?
ok_dad · 2h ago
Because that’s what tech companies want today. They don’t want hackers and shit, they want corporate automatons who will code for scraps.
PaulDavisThe1st · 7h ago
What if I told you that ...
in 1992?
coliveira · 7h ago
When they put Sundar Pichai, a person of little brilliance, to lead Google, it was clear that they want to transform the place into just another money maker and destroy the original culture of the company.
rixed · 5h ago
I would date this turnpoint decision back to when L. Page said in a meeting that, from now on, Google had to have as many engineers than Microsoft.
pjmlp · 5h ago
As someone that mostly enjoys the Microsoft ecosystem, that isn't necessarly a good goal.
ocdtrekkie · 6h ago
Sundar is brilliant, just not in the ways you want. He went from developing an IE browser extension to a web browser to running the world's most powerful company. He understood that what Google needed to keep the numbers going up was not better search, but better market capture.
absolutelastone · 1h ago
It has always seemed to me that level of strategic direction doesn't come from the CEO's brain, but from the big investors. The CEO's job is to execute what they want.
haiku2077 · 2h ago
I wouldn't call Google the world's most powerful company. Saudi Aramco, for example, has more power.
dehrmann · 22m ago
> Saudi Aramco
It's powerful to a point. If it tries to flex its power too much, and international military coalition rolls over Saudi Arabia.
NotAnOtter · 5h ago
Whenever I read these "I was at <faang> for 20 years and am now leaving" it always translates to "I have become unreasonably wealthy, mostly due to the company itself N-tuppling in value. And now after 20 years I don't need or care to have a day job that requires me to show up when I don't feel like it."
ryandrake · 5h ago
I'm sure people who have worked at FAANG for 20 years aren't starving in the streets, but you don't know enough about their financial situation to predict whether they are "unreasonably wealthy." How much of their salary went straight in to their landlord's pockets? Towards student loan interest? Towards health issues, childcare, or taking care of extended family members? Maybe they tried investing and lost money. Heck, maybe they just prioritized travel over saving money, or something. You can't just assume someone has F-you money just because they worked for 20 years.
spacemadness · 4h ago
For the most part, yes, yes you can.
NotAnOtter · 37m ago
I half-typed a longer message but when it came time to actually do math assuming some averages for annual saving, interest, google stock growth, etc. I decided it wasn't worth the effort.
You wrote me original message with less words
abxyz · 4h ago
Anyone at Google from 2005 to 2025 is a multi millionaire many times over based on stock value alone. Even a savant at squandering money would struggle to come out of 20 years at Google without unreasonable wealth.
neilv · 2h ago
There's the fact that they almost certainly don't need to work another day in their life.
But they probably haven't for many years.
So their reasons for choosing now to leave are probably a bit more interesting not wanting to show up if they don't need the money.
kardianos · 5h ago
That's not what Ian said, and he always says what he means.
fawley · 4h ago
It's possible for Ian to mean what he says, while also missing additional context (high net worth) that changes the perspective of the reader.
ikiris · 3h ago
Dude you have no clue what you’re talking about. I used to love when I’d see him as my reviewer because somehow he had the code reviews back in minutes and was always great to work with.
nashashmi · 7h ago
The appreciation for engineering and phd research is missing. All focus stems from the CEO on profitability and revenue and commerce.
Edit: seems like he wrote about this before:
> Much of these problems with Google today stem from a lack of visionary leadership from Sundar Pichai, and his clear lack of interest in maintaining the cultural norms of early Google
mdwrigh2 · 6h ago
Wrong Ian -- Ian Hickson wrote about that in a blogpost, this post is about Ian Lance Taylor
RainyDayTmrw · 3h ago
On a second reading, the extra "o" might not have been a typo, but instead a reference to the early days of the Google search results page, where extra letters "o" were used for pagination.
jhatemyjob · 3h ago
I'm surprised you find it surprising. It's well established among ex-Googlers that it jumped the shark with Emerald Sea. There will always be pockets of sanity within such a large corp but it's been decadent for over a decade.
hiddencost · 18h ago
I think management started turning the screws. They're doing that everywhere. Management isn't technical anymore.
RainyDayTmrw · 18h ago
One would think that someone prominent like Ian Lance Taylor or Russ Cox (who also left within this past year, as noted by another commenter) would be relatively insulated from that.
atombender · 10h ago
Russ Cox didn't leave. He's still on the Go team at Google, but he's stepped down from his position as tech lead.
pjmlp · 5h ago
It is almost the same, Anders Hejlsberg still colaborates with the .NET / C# teams, however others now drive where it goes.
nine_k · 16h ago
Maybe they are safe from being laid off, though you never can tell [1]. But it does not mean they enjoy the tension, the demands, the disagreements, etc that likely crop up. At their position, they can afford to not put up with that, not hold onto the enviable salary, like many others doubtlessly and begrudgingly do.
That’s not true from talking to folks. If you aren’t focused on “the right thing” you can definitely be laid off now. The right thing being AI mostly.
lokar · 7h ago
Insulated by whom? Most of the old time sr Eng mgmt is either gone (replaced by oracle people, or people like them) or have shifted to that mode of operation.
vlovich123 · 17h ago
Why would you think that? You still have management, you have to go through perf calibration and justify your performance. Engineering like most human profesional activities is a very social endeavor where you rely on the people that surround you and you always have people pressuring you to do something.
90s_dev · 17h ago
> you have to go through perf calibration and justify your performance
He did sound relatively defeated when he accused himself of not accurately predicting the future needs of Go users, as if it were even possible!
Maybe management has just been unjustly critical of his performance, and he's taking it too much to heart? Hard to tell, but I just get that feeling.
rtpg · 15h ago
Or management is cynically thinking they could get more bang for their buck with multiple people (I gotta imagine at 19 years at google gets you a healthy multiple compared to new hires)
throwaway519 · 8h ago
Management is more technical fallacied than it's ever been: HR believe they are fine tunng for good.
kortilla · 17h ago
This theme has been repeated a bunch over the last 10 years or so. Google has been in a constant state of decline since the employment surge in the back half of 2010s culminating with a hiring fervor in 2020 that diluted out all of the extremely talented employees.
This severe decline of the median engineer means comp gets cut back, perks get cut back, and most importantly, autonomy gets cut back. Oppressive process and political gamesmanship reign supreme.
Even when I left nearly a decade ago, the idea that something like Gmail could be made in 20% time was a joke. 20% time itself was being snuffed out and dipshit PMs in turf wars would kill anything that did manage to emerge because it wasn’t “polished enough”.
At this point Google is far beyond recovery because it is inundated with B, C and now D players. It’s following the same trajectory of Intel, Cisco, and IBM.
I think the main point remains (skunk work is now impossible)
kortilla · 3h ago
The purpose of 20% time was to allow things like gmail to be created
nvarsj · 5h ago
Exact same thing happened to M$ in the late 90s/00s. At some point the MBAs and money chasers come in and it's just downhill from there.
happyopossum · 17h ago
> comp gets cut back, perks get cut back
That hasn’t really been happening - perks and comp have been pretty stable for the past 3+ years at least, so…
endtime · 7h ago
It has been happening - I was there from 2011 to 2022 and it happened steadily for my last five years. The food got worse, they stopped handing out free phones every year, they cut equity refresh multipliers for strongly exceeds ratings, 20% time became 120% time (as noted elsewhere), and -- shortly after I left -- they changed the rating system such that there were real quotas for people being below expectations. Gone were the days they'd randomly hand out Osprey backpacks outside the cafeteria for no reason (I still use mine), or when your manager could send you to space for creating Memegen, or even when Memegen was controlled by its creator and the team he got funded for it, and not HR.
I actually attribute it to Ruth more than Sundar, but who really knows? All I know is I saw a major decline...and people were already saying similar things when I joined, and they were probably right too.
This isn't to say Google isn't still a great employer...but yes, perks and comp declined.
returningfory2 · 6h ago
Perks have gotten better in some dimensions - for example, parental leave is much more generous than it was even 5 years ago. And that’s probably a more important perk than free backpacks tbh.
whiplash451 · 3h ago
Depends what profile you are trying to invest in.
AdrianB1 · 3h ago
Important or motivating? It is not the same thing. For older people that already have kids, parental leave is useless.
kortilla · 3h ago
It happened a decade ago. Google comp is comparable to every other boring tech company.
How are the free massages and dry cleaning treating you?
Maledictus · 12h ago
In nominal terms, yes, not inflation adjusted.
taormina · 7h ago
Inflation goes up, perk and comp stay the same, is the same as a % cut
nophunphil · 16h ago
Aren’t we talking about what appears to be a management decision/performance review?
What do the other engineers have to do with this? Why are they mediocre?
mosura · 5h ago
The meta question here is what is the Google of 2005 today? Is it really OpenAI? Does it exist at all?
The meta meta question is how long was Google ever really in the state that so many engineers remember as a golden age?
NotAnOtter · 5h ago
My take is the 2005 google does not and cannot exist again because it was born in an era where the underlying tech became so much more powerful. Any company that happened to invest creatively in tech during that era became unfathomably wealthy.
I joined google in 2022 (and have since left), even as a newcomer it was obvious that not only was the golden era over, but the era after the golden era was winding down too. The atmosphere wasn't "The reckless innovation is over but lets make the product as great as we can" - it was "Just don't break anything and squeeze out 1 or 2% improvements where possible"
monkeyelite · 4h ago
> Any company that happened to invest creatively in tech during that era became unfathomably wealthy.
Except countless companies did - many went out of business, and few became Googles.
The historical context is essential but there are so many factors that set them apart.
mmx1 · 4h ago
Indeed countless companies went under investing in tech, on various iterations of the exact things that later became enormously successful, e.g. iPhone. Success is only guaranteed in retrospect.
monkeyelite · 2h ago
It’s more than money - you need people making the right technology and product decisions. For smartphones that was clearly the case - not that apple just dumped in more money.
chuckadams · 3h ago
"The early bird gets the worm, but the second mouse gets the cheese."
gman83 · 3h ago
Isn't that a good thing? When millions of people are relying on those products day in and day out, I think we don't want them to be reckless. Leave that to others.
__turbobrew__ · 3h ago
I don’t believe it exists, google was a unique product of its time — much like Bell Labs which also does not have a contemporary.
gdiamos · 4h ago
It doesn’t exist.
There is an opportunity to build it.
I think the problem with this gen of companies isn’t tech, it’s culture.
Philip-J-Fry · 4h ago
As a spectator, the golden age has to have ended around 2013/2014.
Tech culture is so rampant with ruthless capitalism that it'll never happen again. You used to at least have the sense that there was a will to innovate and experiment. Now it's just oiling the machine.
dehrmann · 4m ago
2014 is interesting for tech because...
- College students just in it for the money hadn't taken over yet
- Low interest rates led to lots of investment
- Most people had broadband in developed countries
- Most people had cell LTE smart phones in developed countries
- Compute tech (CPUs, memory) was mature, adequate, and stable
conqrr · 5h ago
There isn't one yet / We can't see it. You're trying to predict an Industry (like the Tech Industry) that will grow beyond $1 Trillion and a company that provides a fundamental and ubiquitous tool (like Search).
ramoz · 4h ago
It's still Google.
taf2 · 4h ago
When you have core people from Google leaving the chrome and now golang project - it’s pretty evident the management is not doing so good
uaas · 3h ago
While there can be other signs of management not doing so good, let’s not forget that this person is leaving after 19 years.
justguesser · 14h ago
Not trying to create a conspiracy theory, but I wonder whether this has any relation to Ian Hickson's departure from Google/Flutter team [1], where he specifically called out some names:
> Much of these problems with Google today stem from a lack of visionary leadership from Sundar Pichai, and his clear lack of interest in maintaining the cultural norms of early Google. A symptom of this is the spreading contingent of inept middle management. Take Jeanine Banks, for example, who manages the department that somewhat arbitrarily contains (among other things) Flutter, Dart, Go, and Firebase. Her department nominally has a strategy, but I couldn't leak it if I wanted to; I literally could never figure out what any part of it meant, even after years of hearing her describe it. Her understanding of what her teams are doing is minimal at best; she frequently makes requests that are completely incoherent and inapplicable. She treats engineers as commodities in a way that is dehumanising, reassigning people against their will in ways that have no relationship to their skill set. She is completely unable to receive constructive feedback (as in, she literally doesn't even acknowledge it). I hear other teams (who have leaders more politically savvy than I) have learned how to "handle" her to keep her off their backs, feeding her just the right information at the right time. Having seen Google at its best, I find this new reality depressing.
> She treats engineers as commodities in a way that is dehumanising, reassigning people against their will in ways that have no relationship to their skill set
She's not alone.
Another exec fired the entire Python team (many of whom were core contributors to the language) to replace them with the lower salaried TypeScript team, which was then restaffed by a new team in an even lower salaried locale.
zipy124 · 4h ago
The lower salaried locale for the python team is Germany no? Which isn't exactly like your tradional outsourcing. I find it hard to believe we won't see more of it in the coming years with how much cheaper engineers are in Europe especially when they are english speaking and go to good universities like Cambridge/Oxford/EPFL/ETH etc...
UncleMeat · 40m ago
Yes. This was a weird case and I suspect that there was some internal politicking to enable Munich as the location to rebuild the team. I don't have any inside baseball on this, but pretty much every other case of "blow up the team and rebuild it elsewhere" I've seen in the past three years has been a move to a much lower cost region (India, Mexico, and Poland are big ones). The languages group has a bunch of people in Munich and several leaders there, which I suspect played a role in getting the team to be built in a mid cost region rather than a low cost region.
Still a mess and my understanding is that the AI portions of the company were none too happy given that the bulk of their development is done in python.
RainyDayTmrw · 3h ago
I heard about this, too. Sadly, we were not in the right place at the right time, so to speak, to be able to grab some of these candidates.
slantedview · 5h ago
This is shocking.
spacemadness · 5h ago
Why is it shocking? Big tech has thoroughly embraced layoffs and offshoring as a means to cut costs. Execs don’t care if it causes issues at the lower levels of the company. To them it’s just noise from the rabble. If it does cause an issue they’ll just call their buddies at the other Big Corp and work someplace else.
yard2010 · 3h ago
This is a symptom of seeing the whole world through the small narrow lens of "money is everything".
pjmlp · 5h ago
Welcome to big corp with Excel driven decisions, sorry, Google Sheets.
metaltyphoon · 3h ago
This is sickening
pjmlp · 3h ago
Exactly why one should be loyal to the team, not the employer.
The team members, we might bump into them in another situation.
The company, it is all about numbers and meeting projections.
klabb3 · 7h ago
> Her department nominally has a strategy, but I couldn't leak it if I wanted to; I literally could never figure out what any part of it meant, even after years of hearing her describe it.
This was my experience with upper-middle management to VP (sometimes SvP) level at Google. The way they communicate is incomprehensible, it says everything and nothing at the same time – announcements with simultaneous dramatic change and all remains the same – it’s very disorienting. My theory is that its not meant to set direction, or describe a vision, or even goals – rather it converges towards something intended to impress and socially posture against other managers. It’s used as fodder for taking credit during performance review.
One meme I remember is ”you might be a Googler if you cant answer which team you are on in 5 seconds”. The engineers are extremely good (impostor syndrome is widespread), but it feels like they are blindfolded, wandering in different directions. I certainly don’t know how to run a large company. But a good start would be to use plain descriptive language. Evidently, even the corp-speech-whisperers can’t establish a shared reality.
akudha · 2h ago
I don’t know about Google but many places I have worked had people who say a lot of things but those words don’t actually mean anything. You listen to them for half hour but you can’t summarize why they said in those 30 minutes, no matter how hard you try. Lots of buzzwords and word salads. It isn’t unique to Google. Reminds me of politicians
pphysch · 5h ago
> My theory is that its not meant to set direction, or describe a vision, or even goals – rather it converges towards something intended to impress and socially posture against other managers.
Yes, it's self-preservation behavior. It's a strong indicator that the manager knows they are in a position that provides little to no value, so they need to aggressively preserve it.
Why does a single, non-technical middle manager need authority over multiple PL development teams? It makes no sense. The bare minimum of that position must be to connect technical expertise of the ICs to strategic vision of the C-suite. That is a full-time job, and if it's not being done, there needs to be accountability.
nicce · 5h ago
Could it be possible, that overall impact of the decisions is clear to the upper management (but the language that is being used, masks the exploitative behavior/profit maximization). But that feels unlikely, if they just assign people to positions were they are not good fit.
nine_k · 7h ago
As they say, people join companies, but people but people leave (because of) their managers.
osigurdson · 7h ago
>> people leave (because of) their managers
I've often wondered, when people say this, do they mean their direct managers or the management hierarchy in general? If direct manager only, this only makes sense if they have a lot of leeway to run things how they want. For instance, if a company decides to cut 30% of the workforce and more people (naturally) leave afterward, is it really the direct manager that caused them to leave?
I think people leave "the situation" for all kinds of reasons. If you have a really horrible direct manager, that might be why you leave but it certainly isn't universal.
rincebrain · 6h ago
The intent of the statement, at least every time I heard it, was to reflect how the difference between a bad workplace and a good workplace can often be how effective your direct manager is - at shielding their reports from bullshit they shouldn't have to deal with, at not micromanaging while still consistently delivering results, so on and so forth.
Yes, people leave jobs for all sorts of reasons, but your direct manager is the one who can most influence your workplace experience while also having a fundamental power imbalance by definition, and so is often the thing people are fleeing if they leave.
osigurdson · 2h ago
I think this is true in some circumstances but I think people are usually leaving the "situation" (like 90% of the time in my experience). I don't think the statement should be used anymore for this reason.
glimshe · 11h ago
Thanks for sharing. One of my greatest fears for our industry is that we'll never have a company like early Google again. The company should have changed names when Pichai took the reins because it metamorphised into something unrecognizable. Most people you'll meet who worked for Google worked under his regime.
ralferoo · 6h ago
The company was restructured and become a subsidiary of the newly created Alphabet Inc. just after this, so the company did, in fact, change names at that point!
tbrownaw · 4h ago
> One of my greatest fears for our industry is that we'll never have a company like early Google again.
That was mostly an artifact of the free money that gets thrown off as tech advancements are integrated into society.
glimshe · 4h ago
Microsoft was an amazing place to work for 10-15 years (in the late 90s and early 2000s) despite higher interest rates. I was there so I know it.
armitron · 7h ago
Let's not pretend that Google pre Pichai was anything special, the rot was already instilled long before he came along. Other than very early days, Google has mostly been a force that corrupts, commoditizes and destroys. Sundar Pichai just made it explicit, a bagman-beancounter far removed from any engineering ethos.
grg0 · 6h ago
Ah, yes, assigning "resources".
AdrianB1 · 3h ago
Not at Google, but in a different American company of similar size (not capitalization): the quote about the strategy applies exactly the same, the criticism of middle management is the same. Internally we have an official name for the politics that brought us to that situation, but I cannot write it here because it would be immediately downvoted and flagged; in any case, it is an official policy not to have a strategy, not even to measure results of the projects and, lately, to eliminate the idea of roles and responsibilities and replacing it with "we all need to contribute and jump in as needed".
r0nan · 18h ago
I’m curious what he means by Google changing and the Go project changing
Russ didn't leave.
But this is also different, AFAIK.
In this case I expect it's more related to how the engineering ladder has changed at Google over time, and the effects of cost cutting placing pressure to conform to the ladder, even when the ladder doesn't reward what it necessarily should be rewarding.
That's about as unobtuse as i can be about it, for various reasons.
atombender · 10h ago
Russ Cox has not left. He's still on the Go team at Google, but he's stepped down from his position as tech lead.
nikolayasdf123 · 17h ago
yes, looks like related
cletus · 17h ago
Google has over the years tried to get several new languages off the ground. Go is by far the most successful.
What I find fascinating is that all of them that come to mind were conceived by people who didn't really understand the space they were operating in and/or had no clear idea of what problem the language solved.
There was Dart, which was originally intended to be shipped as a VM in Chrome until the Chrome team said no.
But Go was originally designed as a systems programming language. There's a lot of historical revisionism around this now but I guarantee you it was. And what's surprising about that is that having GC makes that an immediate non-starter. Yet it happened anyway.
The other big surprise for me was that Go launched without external dependencies as a first-class citizen of the Go ecosystem. For the longest time there were two methods of declaring them: either with URLs (usually Github) in the import statements or with badly supported manifests. Like just copy what Maven did for Java. Not the bloated XML of course.
But Go has done many things right like having a fairly simple (and thus fast to compile) syntax, shipping with gofmt from the start and favoring error return types over exceptions, even though it's kind of verbose (and Rust's matching is IMHO superior).
Channels were a nice idea but I've become convinced that cooperative async-await is a superior programming model.
Anyway, Go never became the C replacement the team set out to make. If anything, it's a better Python in many ways.
Good luck to Ian in whatever comes next. I certainly understand the issues he faced, which is essentially managing political infighting and fiefdoms.
Disclaimer: Xoogler.
pjmlp · 7h ago
Some of us believe GC[0] isn't an impediment for systems programming languages.
They haven't taken off as Xerox PARC, ETHZ, Dec Olivetti, Compaq, Microsoft desired more due to politics, external or internal (in MS's case), than technical impediments.
Hence why I like the way Swift and Java/Kotlin[1] are pushed on mobile OSes, to the point "my way or get out".
I might discuss about many of Go's decisions regarding minimalism language design, however I will gladly advocate for its suitability as systems language.
The kind of systems we used to program for a few decades ago, compilers, linkers, runtimes, drivers, OS services, bare metal deployments (see TamaGo),...
[0] - Any form of GC, as per computer science definition, not street knowledge.
[1] - The NDK is relatively constrained, and nowadays there is Kotlin Native as well.
eikenberry · 17h ago
> Channels were a nice idea but I've become convinced that cooperative async-await is a superior programming model.
Curious as to your reasoning around this? I've never heard this opinion before from someone not biased by their programming language preferences.
cletus · 17h ago
Sure. First you need to separate buffered and unbuffered channels.
Unbuffered channels basically operate like cooperate async/await but without the explictness. In cooperative multitasking, putting something on an unbuffered channel is essentially a yield().
An awful lot of day-to-day programming is servicing requests. That could be HTTP, an RPC (eg gRPC, Thrift) or otherwise. For this kind of model IMHO you almost never want to be dealing with thread primitives in application code. It's a recipe for disaster. It's so easy to make mistakes. Plus, you often need to make expensive calls of your own (eg reading from or writing to a data store of some kind) so there's no really a performance benefit.
That's what makes cooperative async/await so good for application code. The system should provide compatible APIs for doing network requests (etc). You never have to worry about out-of-order processing, mutexes, thread pool starvation or a million other issues.
Which brings me to the more complicated case of buffered channels. IME buffered channels are almost always a premature optimization that is often hiding concurrency issues. As in if that buffered channels fills up you may deadlock where you otherwise wouldn't if the buffer wasn't full. That can be hard to test for or find until it happens in production.
But let's revisit why you're optimizing this with a buffered channel. It's rare that you're CPU-bound. If the channel consumer talks to the network any perceived benefit of concurrency is automatically gone.
So async/await doesn't allow you to buffer and create bugs for little benefit and otherwise acts like unbuffered channels. That's why I think it's a superior programming model for most applications.
yubblegum · 7h ago
Buffers are there to deal with flow variances. What you are describing as the "ideal system" is a clockwork. Your async-awaits are meshed gears. For this approach to be "ideal" it needs to be able to uniformly handle the dynamic range of the load on the system. This means every part of the clockwork requires the same performance envelope. (a little wheel is spinning so fast that it causes metal fatigue; a flow hits the performance ceiling of an intermediary component). So it either fails or limits the system's cyclical rate. These 'speed bumps' are (because of the clockwork approach) felt throughout the flow. That is why we put buffers in between two active components. Now we have a greater dynamic range window of operation without speed bumps.
It shouldn't be too difficult to address testing of buffered systems at implementation time. Possibly pragma/compile-time capabilities allowing for injecting 'delay' in the sink side to trivially create "full buffer" conditions and test for it.
There are no golden hammers because the problem domain is not as simple as a nail. Tradeoffs and considerations. I don't think I will ever ditch either (shallow, preferred) buffers or channels. They have their use.
jpc0 · 14h ago
I agree with many of your points, including coroutines being a good abstraction.
The reality is though that you are directly fighting or reimplementing the OS scheduler.
I haven’t found an abstraction that does exactly what I want but unfortunately any sort of structured concurrency tends to end up with coloured functions.
Something like C++ stdexec seems interesting but there are still elements of function colouring in there if you need to deal with async. The advantage is that you can compose coroutines and synchronous code.
For me I want a solution where I don’t need to care whether a function is running on the async event loop, a separate thread, a coprocessor or even a different computer and the actor/CSP model tends to model that the best way. Coroutines are an implementation detail and shouldn’t be exposed in an API but that is a strong opinion.
skybrian · 7h ago
“Systems programming language” is an ambiguous term and for some definitions (like, a server process that handles lots of network requests) garbage collection can be ok, if latency is acceptable.
Google has lots of processes handling protobuf requests written in both Java and C++. (Or at least, it did at the time I was there. I don’t think Go ever got out of third place?)
kmeisthax · 6h ago
My working definition of "systems programming" is "programming software that controls the workings of other software". So kernels, hypervisors, emulators, interpreters, and compilers. "Meta" stuff. Any other software that "lives inside" a systems program will take on the performance characteristics of its host, so you need to provide predictable and low overhead.
GC[0] works for servers because network latency will dominate allocation latency; so you might as well use a heap scanner. But I wouldn't ever want to use GC in, say, audio workloads; where allocation latency is such a threat that even malloc/free has to be isolated into a separate thread so that it can't block sample generation. And that also means anything that audio code lives in has to not use GC. So your audio code needs to be written in a systems language, too; and nobody is going to want an OS kernel that locks up during near-OOM to go scrub many GBs of RAM.
[0] Specifically, heap-scanning deallocators, automatic refcount is a different animal.
pjmlp · 5h ago
So that fits, given that Go compiler, linker, assembler and related runtime are all written in Go itself.
You mean an OS kernel, like Java Real Time running bare metal, designed in a way that it can even tackle battleship weapons targeting systems?
I wouldn’t include compilers in that list. A traditional compiler is a batch process that needs to be fast enough, but isn’t particularly latency sensitive; garbage collection is fine. Compilers can and are written in high-level languages like Haskell.
Interpreters are a whole different thing. Go is pretty terrible for writing a fast interpreter since you can’t do low-level unsafe stuff like NaN boxing. It’s okay if performance isn’t critical.
kmeisthax · 4h ago
You don't (usually) inherit the performance characteristics of your compiler, but you do inherit the performance characteristics of the language your compiler implements.
pjmlp · 5h ago
Yes, you can via unsafe.
And if you consider K&R C a systems language, you would do it like back in the day, with a bit of hand written helper functions in Assembly.
nmz · 6h ago
From what I remember, Go started out because a C++ application took 30 minutes compiling even though they were using google infrastructure, you could say that they set out to create a systems programming language (they certainly thought so), but mostly I think the real goal was recreating C++ features without the compile time, and in that, they were successful.
pluto_modadic · 1h ago
is there a language that implements cooperative async-await patterns nicely?
zelphirkalt · 5h ago
I mean, they claimed that one didn't need generics in the language for some 12 years or so ...
firesteelrain · 6h ago
I don’t have much insight into internal Google politics but there seems to be a rash of articles and blog posts over the years about prominent folks seemingly and abruptly announcing their exit. What is behind this trend?
praptak · 5h ago
Google switched from exploration to exploitation.
At least this is what I found at the root of every particular inconvenience that used to wear me down at Google until I finally left in August.
AdrianB1 · 3h ago
Corporation rot. If you are successful when you are relatively small and hire the best and brightest, then you scale out in numbers, you go down as this model is not scalable. When you have tens of thousands of people, you bring "professional management" that are bozos (this is a quote from an interview with Steve Jobs), the organization first starts to decline as an average (cannot find tens of thousands of really bright people, there are not enough in the world) and second it starts to rot as the bozos have a huge negative impact. When the bozos change the culture for the worse, top people leave, average employee is declining even more. It is a race to the bottom, not in pricing but in employee quality.
yusina · 2h ago
I'd have liked to see more actual reasons for the departure beyond "not a good fit anymore". What does that mean? How have things changed?
Honest question, I'm not after dirty laundry. Just want to know more than "I'm leaving because reasons" which is kinda the tl;dr of that post.
chubot · 18h ago
I wonder what people use GCC Go for, in production? I tried it and it seems pretty cool, although the binaries start slower for some reason (I think it was more than a second even?)
pjmlp · 7h ago
It used to be for better performance, however it was never updated after Go got generics, so I suspect eventually it will join gjc at the compilers retirement pub.
RainyDayTmrw · 18h ago
If you're targeting a system (hardware architecture and operating system combination) that GCC already supports, but the native Go toolchain doesn't, this may be an easier bootstrap path.
vips7L · 18h ago
Probably boutique architectures or operating systems the official compiler doesn't support.
nikolayasdf123 · 17h ago
so what is the reason why he is leaving? layoffs? burnout? up-or-out without up? internal politics pushed him out? seems like he wants to work. so what happened?
philosopher1234 · 17h ago
This is so sad! It seems Go is fast becoming rudderless, i worry the wualities that have made it great wont survive the tides at google this way. But i hope to be wrong.
surajrmal · 5h ago
Go still has strong leadership. They are just not as prominently known externally.
nikolayasdf123 · 17h ago
same. Go is so powerful because of its core. without core, ecosystem will fall apart
What are the good use cases for Go today? It looks like the hype has gone.
devjab · 17h ago
We've moved from .NET and C# to Go, and I'd argue that it's very competetive with general purpose languages like C#, Java and similar for a different philosophical approach to enterprise tech. It's been a great technical fit for us in both finance and energy, but the main purpose for our adoption is because it's opnionated approachs are a much better fit for us than traditional OOP languages. There is no "magic", everything is explicit, the standard library is incredible and it's a relatively easy langauge to write and read.
In a world where 4chan can serve 4 million visitors on some dated apache server version running a 10k line PHP script which hasn't been updated since 2015 it's important to remember, that for 95% of all software (if not more), any, general purpose language will be just fine technically speaking and it's in the development processes (the people) the actualy differences are found. Go is productive and maintainable (cost-efficient and rapid changes) for teams that work better without implicit magic and third party depedencies.
The hype may be gone, but the Jobs aren't. In my area of the world Go is the only noticeably growing programming language in regards to job offerings.
bqmjjx0kac · 17h ago
Go has surprisingly good "UX", which I don't hear people talk about much. It compiles very quickly and gets out of your way. I've found it useful for a few reasons:
1. The standard library has a real HTTP/2 implementation (unlike Python).
2. The Go compiler creates statically-linked binaries and cross-compiling is painless.
3. Channels and goroutines make it relatively easy to write parallel code. There are certainly sharp edges, like every language.
kevindamm · 17h ago
It is also conveniently easy to compile everything into a single file, using embed, and this helps with deployment in a few ways.
prisenco · 16h ago
I love how readable it is, even by people who don't know Go.
haiku2077 · 17h ago
- Fast compiler with easy cross compilation (super handy e.g. for developing Linux network services on a Mac)
- Pretty decent concurrency built in
- Small language spec that is very easy to read and learn
- A very good and well thought out toolchain and tool ecosystem. This is hard to list as a selling point or quickly summarize but it makes Go code pleasant to work on. Things that other languages have ti have complex third party tooling for are simple and boring in Go.
- If you are writing code that interfaces with Kubernetes or a popular container runtime like Docker or Podman, it is a natural choice.
- Pretty good performance as far as garbage collected runtimes go. Not the best, but really good.
root_axis · 17h ago
Go shines for network services. The standard library has everything you need for networking and the web with very accessible concurrency primitives. It's also a pretty lightweight language that's easy for people to pick up.
Animats · 17h ago
> Go shines for network services.
Right. Go is a great language for the server side of web client/server things.
It's more reliable than C++, easier than Rust, and is hard-compiled to a read-only executable, which is good for security. Goroutines, which are cheap but can block, get rid of the async/sync distinction.
The important libraries are maintained by Google people and used internally, so even the unusual cases are well-exercised.
What more do you want?
nikolayasdf123 · 17h ago
native GPU (CUDA, BLAS and friends) support would be nice. haha
echelon · 17h ago
I've used Go and Rust for network services, and they honestly feel completely on par with one another from a DX and ergonomics perspective. I wouldn't be surprised if Rust starts eating into Go marketshare for microservices.
There are some Googlers angling for this.
root_axis · 13h ago
I love Rust, but Go is a much much simpler language, especially for network services. For example, the experience of goroutines vs rust async is night and day in terms of complexity. Also, the borrow-checker introduces a lot more ceremony when managing network peer entities, particularly structuring relationships between entities - a very common requirement in network applications.
Not that I'm against Rust for network services, but with Rust you're accepting increased complexity for increased safety - a worthwhile tradeoff depending on the project.
prisenco · 16h ago
I can't agree they're on par based on function coloring and slow compile times alone.
90s_dev · 17h ago
Are these not also true for Node.js? Add the familiarity of JavaScript, the ecosystem of NPM, and the good-enough speed of V8, and I'm not sure why choose Go.
tuckerman · 7h ago
The convenience of shipping a single compiled binary is one.
I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
90s_dev · 7h ago
1. Node.js now has SEA
2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.
tuckerman · 4h ago
Very cool about the SEA feature, I haven't seen that before. Thanks for sharing that
This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison.
For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sumhttps://github.com/gorilla/mux/blob/main/go.mod
If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps).
I actually agree, and my own Node.js web server doesn't use express.js or anything except for 'mime-types', and only because it's not built in even though it really should be. I never liked express.js's design, and pretty much every useful feature of it is now either built-in or 5 lines of code. Plus, when I dug into its source code and dependencies, I found so much outdated and unnecessary cruft. So yeah I don't disagree. But it still doesn't really push me towards Go. Plus, Go's own http route mounting concept also seems kind of overdone. So even though I can just avoid using it, it still becomes part of that 1.5 MiB that I didn't really need but am forced to bundle, even if it is smaller than the 109 MiB. So in principle it doesn't seem a huge win, just a small one. Compare that to the many TypeScript features and JavaScript features I'd have to give up, and it just doesn't seem worth it.
scripturial · 17h ago
Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized.
Go is very much faster, you save time and money on computing resources.
Go has built in testing and type support, making it easier
To write more reliable and more bug free code.
But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.
90s_dev · 16h ago
> But let’s not debate it, learn go for yourself and try it on a small little project
I wrote a lot of Go from like 2010 to 2013 or so.
A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go.
I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
> I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed.
If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.
cratermoon · 7h ago
If you haven't touched Go since 2013,
give it another try.
Quite a lot of the developer QOL has improved.
90s_dev · 7h ago
When typescript-go was announced, I almost wanted to give it a serious try. But that article I referred to convinced me that it still has serious QOL issues.
90s_dev · 17h ago
> Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized.
I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close).
But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets.
gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.
Having a standard is fine. But software is not just technical, it's an art too.
haiku2077 · 15h ago
> This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.
Interesting site, I bet it won't last more than 20 more years.
I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)
pjmlp · 4h ago
Additionally, if more performance is needed we can always write a native module.
However, I would use Go instead when deploying in cloud providers like Vercel and Netlify, as explained in a sibling comment.
It is easier to just go with the less friction option, and deploying such modules requires not only knowing how to write them, also mastering the whole deployment process, thus not something I would advise in teams with mixed skill levels.
kweingar · 17h ago
Go's performance is in a totally different class than node.
pjmlp · 4h ago
Depends if nodejs C++ AddOns are part of the picture or not.
nikolayasdf123 · 17h ago
minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.
pjmlp · 5h ago
When you want to have native code in clouds like Vercel and Netlify, unless you rather go via nodejs native modules.
They build on top of AWS Lambda, but do not expose the full capabilities, so Go it is.
Working on DevOps space, most tools related to Docker and Kubernetes are written in Go, as this is its reason to fame. Although Rust is starting to show up as well.
packetlost · 18h ago
I put it in the same category as Clojure and where I hope Rust eventually ends up: stable, boring, and capable with healthy ecosystems
melodyogonna · 13h ago
Almost every tool in the cloud ecosystem is written in Go.
I did not know Go is so massively used until I started working with Kubernetes
eikenberry · 17h ago
The hype has gone as it is now just another programming language in common use. The use cases are the same as they've always been. Networked and distributed systems.
dboreham · 17h ago
Where you want to just cut code without drama (and dramatic people).
whobre · 7h ago
Kubernetes custom operators
mlrtime · 9h ago
service to service communication. GRPC + Protobufs + Go allow ease of development and resuse.
neonsunset · 7h ago
Using gRPC in Go is really inconvenient in comparison to some other languages.
tayo42 · 17h ago
It's like a more robust python. Compiled so you don't deal with the annoyances of using a scripting language to build, deploy and run applications. But also way simpler then something like c++ or rust. Though I do wish it had some more nice syntax and features.
90s_dev · 17h ago
Theoretically, it's basically a faster Node.js. Case in point, TypeScript is moving from Node.js to Go for a 10x speed increase.
But in reality, TypeScript is probably its only legitimate use-case, and only because it already had very stringent requirements.
Most projects either stick to Node.js, or if they need more efficiency, they get rewritten in C++ or Rust, instead of ported to Go.
zaphirplane · 17h ago
With all due respect, I am fairly confident that the view you have is formed in a bubble .
nikolayasdf123 · 17h ago
> Theoretically, it's basically a faster XYZ
well, that's the point. it is excellent language for server programming. and not just faster, it is more stable, scales complexity better, stronger security
90s_dev · 18h ago
> That is far beyond what any of us expected in the early days, when our best hope was that Go might serve as an example for useful ideas that other languages and programming environments could adopt.
Am I understanding you correctly? The Go authors basically expected Go to be just a good starting point or source of ideas for real languages to stand on?
nine_k · 18h ago
Google has a bunch of internal languages that are only used within it, don't enjoy a wider adoption, and get deprecated.
Facebook created Hack, a version of PHP with a quite nice static type system, which is virtually not used outside it. They also had an early statically typed version of JavaScript, called Flow, which enjoyed a limited success, but was supplanted by Typescript.
Haskell, OCaml, Erlang, Smalltalk, etc all enjoyed some success in specific narrow domains, while influencing heavily such mainstream languages as Python, Java, Typescript, Rust, and, well, Go.
Compared to this, Go is unreasonably, blindingly successful; it's now all over the place, but that was hard to predict back in the early days of the project.
scripturial · 17h ago
Early on it was risky to choose go, as it really wasn’t clear if go could achieve mainstream adoption. That said, in hindsight, it really should have been obvious. If I myself saw its benefits over the incumbents, I should have realized I wasn’t the only one. That said, go is old enough that google still had a lot of its older more positive “high skilled elite cool programmer” image, so perhaps that really helped the language along. I’m not sure. Today I’d be much more hesitant to pick up a google language.
throw-the-towel · 13h ago
At a previous job we decided against Go because it's made by Google, and Google has a habit of killing products.
xiphias2 · 11h ago
Sure, as they say in Google, for technologies you always have two options: the new which is experimental and not yet supported and the old that is depreciated because there will be a new coming anyways.
darthwalsh · 4h ago
When I was there the saying was that "V2 isn't ready yet and V1 n't as deprecated"
It's impressive the go team managed to buck the trend and only got to V2 after so many years.
nick__m · 17h ago
hack was created at meta for meta...
nine_k · 17h ago
Still Hack and HVVM are open source and anyone who cares can use them.
Go was also created at Google and for Google first and foremost, but ended up wildly popular in general.
(React was also created at Meta and for Meta. Same with Pytorch.)
nikolayasdf123 · 17h ago
cmon. nobody in their right mind is using hack outside of Meta
at least single example in open source or in enterprise who is running Hack? haven't seen even one in 8 years
And maybe I'm shallow, but it was a thrill to see his initials show up on my code reviews. Thanks for all your work on golang.
Had a great experience contributing to the project, and Ian was a big part of that. Which for a big project like Go says a lot.
I tried to push back on one of his comments as well.
Imo it just feels kinda cool that someone who really really knows what they are doing gave you a stamp of approval on something.
I did Python readability at Google and "take this one massive CL and if they make it good by the end of the process they're done" never felt quite as useful as Go's process. I'm glad they made their own rules; it benefited me. (Even if during the process I was thinking "I JUST NEED TO CHECK IN THIS CODE SO I CAN GO BACK TO BED" when getting paged in the middle of the night ;)
I’ve had the pleasure of trading emails with Ian several times over the years. He’s been a real inspiration to me. Amidst whatever his responsibilities and priorities were at Google he always found time to respond to my emails and review my patches, and always with insightful feedback.
I have complicated feelings about the language that is Go, but I feel confident in saying the language will be worse off without Ian involved. The original Go team had strong Bell Labs vibes—a few folks who understood computers inside and out who did it all: as assembler, linker, two compilers, a language spec, a documentation generator, a build system, and a vast standard library. It has blander, corporate vibes now, as the language has become increasingly important to Google, and standard practices for scaling software projects have kicked in. Such is the natural course of things, I suppose. I suspect this cultural shift is what Ian alluded to in his message, though I am curious about the specific tipping point that led to his decision to leave.
Ian, I hope you take a well-deserved break, and I look forward to following whatever projects you pursue next.
[0]: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS
I wish I had more elaboration on this paragraph. It seems like a real change happened of which Ian took notice.
"Please add Gemini to the go compiler errors, or take a hike."
I don't think it's wrong per se to suggest that Google should not be in the business of "Go" e.g. but presumably there are many other areas where similar technical expertise can be used in this size of company.
That said I've seen good people get stuck in large companies. They are put in a certain bucket and find it very hard to change. Sometimes leaving is the correct answer.
As someone who switched to Go in its early days (from C++) and had some interaction with the community (bugs, conventions etc.) it's a little sad but I think also just the way things go.
I've seen things with more impressive results, but then interlaced with garbage results. Far less reliable is the outcome.
Whether it's the now horrible pixel camera app, search results, or really anything else, it's all garbage
Meanwhile, yay!, let's use a billion times the compute.
That's kinda surprising to hear. I wonder what happened. It would have been easy to leave out these 3 sentences or replace them with fluff. The author choosing to write this out suggests that there is some weight here.
Prior to 2023 I pretty much only ever saw the L7s and L8s that I work with leave Google because there was an exciting new opportunity or because they were retiring. Now most of the people I see leave at this level are leaving because they are fed up with Google. It's a mess.
I joined in 2021. I feel like I caught the tail end of old Google. Any decent idea was greenlit.
Now, it is a lot harder to find resources to do things. (This is of course relative. It is still far easier than any other place I've worked at).
The company has transitioned into something a little more traditional.
IC's natural way of growth is to produce larger impact by solving harder problems, there are always hard unsolved problems which hold some business opportunities.
Most of the actual groundwork has already been laid by passionate, actual engineers.
Today big tech is just a place people go to make money, and they don’t necessarily care about long term vision.
Mostly filled with the most uninspiring, forced-to-do-kumon types who have little “passion” for engineering or computers. Zero imagination and outside the box thinking. Just rote memorization to get in and then getting PIP’d or laid off to go do the same at the other big corps. TC or GTFO types.
Better luck at startups that are the Google’s of yesteryear.
But really, Google was cool. Google was hip. So was Apple. Lots of cool things were coming from those companies between 2000 and 2012 or so. My interest in Meta was similar - the reality labs projects seemed really cool when I looked into them back before all the giant cuts lol.
In addition to those things, these were all seen as companies run by engineers, where the software and the tech was seen as the big core thing the company cared about. People thought programmers at google weren't treated as "cost centers" like they often are at companies where software is just a piece of the puzzle.
But yea, times change. In a way a lot of it was just infatuation and dreams that may not have had a basis in reality.
I believe there is a lot of reality. As well as they gave a lot of brilliant co-workers which seems to have made it a great place to spin ideas. Also from stories too leader ship was at least open to listen to criticism in "thanks God it's Friday" meetings.
While from observing some friends the promotion play was always tough as well. If you wanted to be promoted you always had to use your 20% time "wisely" which for some meant to still work on the main project. For other to strategically work on a side project they could use for the promotion panel.
Today's Google seem to be fully focused on numbers, where a lot of the spirit is gone. Back in the days when I visited some friends working for Google we went to Google for breakfast or met at Google for dinner as it was just a good place to hangout. (Which motivated people to stay at Google for more than their regular hours) Nowadays it seem to be more of a workplace.
God forbid
The web is way more mature right now than 20 or even 10 years ago. There's way lass untouched niches waiting to be filled by the new killer product. And Google already owns the search market, the ads market, the smartphone market, the email market, the browser market, the maps market, and soon maybe AI market, etc. What new untapped multi billion market is left for them to conquer? The pond is already fished out at this point. So of course most Googlers are gonna have to be factory workers keeping the factory running instead of dicking around creating new useless things that bring in maybe no significant revenue. The days of Google & Co. spending billions on pipe dreams is over for now.
Innovation is at start-ups which Google then buys because it has ad revenue. People go to work at Google because it pays well and less headaches than working at startups, not because they're gonna invent something new.
Google is proof that yes, it does create innovation. How many products and tools came out of people dicking around?
What new product has Google launched recently that it didn't cancel? Google's main money makers are all still products from 15-20 years ago.
Given all this it's proof that no, paying people to dick around doesn't generate more creativity once you peaked.
Now you go for big tech (and startups). The cliche of the young "banker" personality type is now the "tech" personality type, and is coming soon to an Ai startup near you.
There was a mad rush between mid-1997 and mid-2001 to get into tech, then the dot-com bust happened, but that only lasted about 2 years before things ramped up again. That was 20 years ago.
Suggesting that the first decade of the web didn't flip the bit from finance to tech is ahistorical.
The big tech firms finally started doing RSU's insteda of stock options in the early 2000's, though most startups still were (and are) lagging way behind.
People see their cousin's uncle's neighbor's roommate making $400K at Meta and just assume every single employee there makes that much. Or they point to those salary sharing sites where people self-report their best salary + highest possible bonus + equity as if every year was 2021, and think of them as representative.
Every single employee, no. But the average L5 really does make over $300k in total compensation. Yes some of that is stock, but the companies are now stable enough so that doesn't cause a ton of variation.
I think it's true both ways:
A lot of people assume it's like finance money, but it's not.
And on the flip side there's a lot of people coming from normal company or startup land, and assume that the $400k + average performing L5 is a myth, when that's pretty typical for big tech.
And I definitely agree with sibling here: $300k or $400k is good money, but in a place where the median house costs $1.5 million or something insane like the parts of the bay area that have a <45 minute commute, it doesn't go as far as you'd think. And it's incredibly risky, because now you're tied to always getting that level of comp for decades or you'll get evicted. (And while $400k + L5 Meta comp may be typical at Meta, it's not exactly trivial to maintain, or nearly as relaxing as a software gig you can do at other companies)
Household. A married couple both making that are 98th percentile.
In what percentile of your social class do you sit with $300k? Probably not very high.
We had a brief window in the mid 2010s when folks started to throw rocks at the tech buses where I thought people were starting to realize it. Around Bernie's presidential run - which makes sense because he preached wealth inequality. But somehow during COVID tech slithered back into everybody's good graces.
* I don't condone people throwing rocks at the buses for both the humanitarian reasons and the fact that few if any executive or social changes could result from that behavior. But it struck me as a microcosm of the prevailing sentiment towards technology workers.
Is that inherent to the technology, or is that just inherent to the way we've chosen to organize society? Really, any technological paradigm shift going back to the industrial revolution has mainly served to enrich a small few people and families, but that's not some immutable property of technology. Like you say, it's a tool. We've chosen (or allowed) it to be wielded toward one end rather than another. I can smash my neighbor's head in with a hammer, or I can build a home with it.
At one point in the United States, there was political will to update our social structures so that the fruits of technological and economic progress did not go disproportionately to one class of society (think early 20th century trust busting, or the New Deal coming out of the Great Depression). I'm afraid we find ourselves with a similar set of problems, yet the political will to create some other reality beyond further wealth concentration seems to be limited.
Refreshing to hear that stated so clearly.
On your general point, I don't know if I feel the same optimism at this stage, much as I'd love to be proven wrong. Populations seem to never tire of jumping from one tech fairy tale to the next.
Developers seem to never tire of burying their head in the sand either, and I sometimes wonder if the two are correlated.
Why do you think this recent AI push will be the straw that breaks the camel's back? What if the camel just keeps plodding along?
in 1992?
It's powerful to a point. If it tries to flex its power too much, and international military coalition rolls over Saudi Arabia.
You wrote me original message with less words
But they probably haven't for many years.
So their reasons for choosing now to leave are probably a bit more interesting not wanting to show up if they don't need the money.
Edit: seems like he wrote about this before:
> Much of these problems with Google today stem from a lack of visionary leadership from Sundar Pichai, and his clear lack of interest in maintaining the cultural norms of early Google
[1]: https://nerdy.dev/ex-googler
He did sound relatively defeated when he accused himself of not accurately predicting the future needs of Go users, as if it were even possible!
Maybe management has just been unjustly critical of his performance, and he's taking it too much to heart? Hard to tell, but I just get that feeling.
This severe decline of the median engineer means comp gets cut back, perks get cut back, and most importantly, autonomy gets cut back. Oppressive process and political gamesmanship reign supreme.
Even when I left nearly a decade ago, the idea that something like Gmail could be made in 20% time was a joke. 20% time itself was being snuffed out and dipshit PMs in turf wars would kill anything that did manage to emerge because it wasn’t “polished enough”.
At this point Google is far beyond recovery because it is inundated with B, C and now D players. It’s following the same trajectory of Intel, Cisco, and IBM.
Pockets of brilliance drowning in mediocrity
https://time.com/43263/gmail-10th-anniversary/#:~:text=Gmail...
That hasn’t really been happening - perks and comp have been pretty stable for the past 3+ years at least, so…
I actually attribute it to Ruth more than Sundar, but who really knows? All I know is I saw a major decline...and people were already saying similar things when I joined, and they were probably right too.
This isn't to say Google isn't still a great employer...but yes, perks and comp declined.
How are the free massages and dry cleaning treating you?
What do the other engineers have to do with this? Why are they mediocre?
The meta meta question is how long was Google ever really in the state that so many engineers remember as a golden age?
I joined google in 2022 (and have since left), even as a newcomer it was obvious that not only was the golden era over, but the era after the golden era was winding down too. The atmosphere wasn't "The reckless innovation is over but lets make the product as great as we can" - it was "Just don't break anything and squeeze out 1 or 2% improvements where possible"
Except countless companies did - many went out of business, and few became Googles.
The historical context is essential but there are so many factors that set them apart.
There is an opportunity to build it.
I think the problem with this gen of companies isn’t tech, it’s culture.
Tech culture is so rampant with ruthless capitalism that it'll never happen again. You used to at least have the sense that there was a will to innovate and experiment. Now it's just oiling the machine.
- College students just in it for the money hadn't taken over yet
- Low interest rates led to lots of investment
- Most people had broadband in developed countries
- Most people had cell LTE smart phones in developed countries
- Compute tech (CPUs, memory) was mature, adequate, and stable
> Much of these problems with Google today stem from a lack of visionary leadership from Sundar Pichai, and his clear lack of interest in maintaining the cultural norms of early Google. A symptom of this is the spreading contingent of inept middle management. Take Jeanine Banks, for example, who manages the department that somewhat arbitrarily contains (among other things) Flutter, Dart, Go, and Firebase. Her department nominally has a strategy, but I couldn't leak it if I wanted to; I literally could never figure out what any part of it meant, even after years of hearing her describe it. Her understanding of what her teams are doing is minimal at best; she frequently makes requests that are completely incoherent and inapplicable. She treats engineers as commodities in a way that is dehumanising, reassigning people against their will in ways that have no relationship to their skill set. She is completely unable to receive constructive feedback (as in, she literally doesn't even acknowledge it). I hear other teams (who have leaders more politically savvy than I) have learned how to "handle" her to keep her off their backs, feeding her just the right information at the right time. Having seen Google at its best, I find this new reality depressing.
[1]: https://ln.hixie.ch/?start=1700627373
She's not alone.
Another exec fired the entire Python team (many of whom were core contributors to the language) to replace them with the lower salaried TypeScript team, which was then restaffed by a new team in an even lower salaried locale.
Still a mess and my understanding is that the AI portions of the company were none too happy given that the bulk of their development is done in python.
The team members, we might bump into them in another situation.
The company, it is all about numbers and meeting projections.
This was my experience with upper-middle management to VP (sometimes SvP) level at Google. The way they communicate is incomprehensible, it says everything and nothing at the same time – announcements with simultaneous dramatic change and all remains the same – it’s very disorienting. My theory is that its not meant to set direction, or describe a vision, or even goals – rather it converges towards something intended to impress and socially posture against other managers. It’s used as fodder for taking credit during performance review.
One meme I remember is ”you might be a Googler if you cant answer which team you are on in 5 seconds”. The engineers are extremely good (impostor syndrome is widespread), but it feels like they are blindfolded, wandering in different directions. I certainly don’t know how to run a large company. But a good start would be to use plain descriptive language. Evidently, even the corp-speech-whisperers can’t establish a shared reality.
Yes, it's self-preservation behavior. It's a strong indicator that the manager knows they are in a position that provides little to no value, so they need to aggressively preserve it.
Why does a single, non-technical middle manager need authority over multiple PL development teams? It makes no sense. The bare minimum of that position must be to connect technical expertise of the ICs to strategic vision of the C-suite. That is a full-time job, and if it's not being done, there needs to be accountability.
I've often wondered, when people say this, do they mean their direct managers or the management hierarchy in general? If direct manager only, this only makes sense if they have a lot of leeway to run things how they want. For instance, if a company decides to cut 30% of the workforce and more people (naturally) leave afterward, is it really the direct manager that caused them to leave?
I think people leave "the situation" for all kinds of reasons. If you have a really horrible direct manager, that might be why you leave but it certainly isn't universal.
Yes, people leave jobs for all sorts of reasons, but your direct manager is the one who can most influence your workplace experience while also having a fundamental power imbalance by definition, and so is often the thing people are fleeing if they leave.
That was mostly an artifact of the free money that gets thrown off as tech advancements are integrated into society.
In this case I expect it's more related to how the engineering ladder has changed at Google over time, and the effects of cost cutting placing pressure to conform to the ladder, even when the ladder doesn't reward what it necessarily should be rewarding.
That's about as unobtuse as i can be about it, for various reasons.
What I find fascinating is that all of them that come to mind were conceived by people who didn't really understand the space they were operating in and/or had no clear idea of what problem the language solved.
There was Dart, which was originally intended to be shipped as a VM in Chrome until the Chrome team said no.
But Go was originally designed as a systems programming language. There's a lot of historical revisionism around this now but I guarantee you it was. And what's surprising about that is that having GC makes that an immediate non-starter. Yet it happened anyway.
The other big surprise for me was that Go launched without external dependencies as a first-class citizen of the Go ecosystem. For the longest time there were two methods of declaring them: either with URLs (usually Github) in the import statements or with badly supported manifests. Like just copy what Maven did for Java. Not the bloated XML of course.
But Go has done many things right like having a fairly simple (and thus fast to compile) syntax, shipping with gofmt from the start and favoring error return types over exceptions, even though it's kind of verbose (and Rust's matching is IMHO superior).
Channels were a nice idea but I've become convinced that cooperative async-await is a superior programming model.
Anyway, Go never became the C replacement the team set out to make. If anything, it's a better Python in many ways.
Good luck to Ian in whatever comes next. I certainly understand the issues he faced, which is essentially managing political infighting and fiefdoms.
Disclaimer: Xoogler.
They haven't taken off as Xerox PARC, ETHZ, Dec Olivetti, Compaq, Microsoft desired more due to politics, external or internal (in MS's case), than technical impediments.
Hence why I like the way Swift and Java/Kotlin[1] are pushed on mobile OSes, to the point "my way or get out".
I might discuss about many of Go's decisions regarding minimalism language design, however I will gladly advocate for its suitability as systems language.
The kind of systems we used to program for a few decades ago, compilers, linkers, runtimes, drivers, OS services, bare metal deployments (see TamaGo),...
[0] - Any form of GC, as per computer science definition, not street knowledge.
[1] - The NDK is relatively constrained, and nowadays there is Kotlin Native as well.
Curious as to your reasoning around this? I've never heard this opinion before from someone not biased by their programming language preferences.
Unbuffered channels basically operate like cooperate async/await but without the explictness. In cooperative multitasking, putting something on an unbuffered channel is essentially a yield().
An awful lot of day-to-day programming is servicing requests. That could be HTTP, an RPC (eg gRPC, Thrift) or otherwise. For this kind of model IMHO you almost never want to be dealing with thread primitives in application code. It's a recipe for disaster. It's so easy to make mistakes. Plus, you often need to make expensive calls of your own (eg reading from or writing to a data store of some kind) so there's no really a performance benefit.
That's what makes cooperative async/await so good for application code. The system should provide compatible APIs for doing network requests (etc). You never have to worry about out-of-order processing, mutexes, thread pool starvation or a million other issues.
Which brings me to the more complicated case of buffered channels. IME buffered channels are almost always a premature optimization that is often hiding concurrency issues. As in if that buffered channels fills up you may deadlock where you otherwise wouldn't if the buffer wasn't full. That can be hard to test for or find until it happens in production.
But let's revisit why you're optimizing this with a buffered channel. It's rare that you're CPU-bound. If the channel consumer talks to the network any perceived benefit of concurrency is automatically gone.
So async/await doesn't allow you to buffer and create bugs for little benefit and otherwise acts like unbuffered channels. That's why I think it's a superior programming model for most applications.
It shouldn't be too difficult to address testing of buffered systems at implementation time. Possibly pragma/compile-time capabilities allowing for injecting 'delay' in the sink side to trivially create "full buffer" conditions and test for it.
There are no golden hammers because the problem domain is not as simple as a nail. Tradeoffs and considerations. I don't think I will ever ditch either (shallow, preferred) buffers or channels. They have their use.
The reality is though that you are directly fighting or reimplementing the OS scheduler.
I haven’t found an abstraction that does exactly what I want but unfortunately any sort of structured concurrency tends to end up with coloured functions.
Something like C++ stdexec seems interesting but there are still elements of function colouring in there if you need to deal with async. The advantage is that you can compose coroutines and synchronous code.
For me I want a solution where I don’t need to care whether a function is running on the async event loop, a separate thread, a coprocessor or even a different computer and the actor/CSP model tends to model that the best way. Coroutines are an implementation detail and shouldn’t be exposed in an API but that is a strong opinion.
Google has lots of processes handling protobuf requests written in both Java and C++. (Or at least, it did at the time I was there. I don’t think Go ever got out of third place?)
GC[0] works for servers because network latency will dominate allocation latency; so you might as well use a heap scanner. But I wouldn't ever want to use GC in, say, audio workloads; where allocation latency is such a threat that even malloc/free has to be isolated into a separate thread so that it can't block sample generation. And that also means anything that audio code lives in has to not use GC. So your audio code needs to be written in a systems language, too; and nobody is going to want an OS kernel that locks up during near-OOM to go scrub many GBs of RAM.
[0] Specifically, heap-scanning deallocators, automatic refcount is a different animal.
You mean an OS kernel, like Java Real Time running bare metal, designed in a way that it can even tackle battleship weapons targeting systems?
https://www.ptc.com/en/products/developer-tools/perc
Interpreters are a whole different thing. Go is pretty terrible for writing a fast interpreter since you can’t do low-level unsafe stuff like NaN boxing. It’s okay if performance isn’t critical.
And if you consider K&R C a systems language, you would do it like back in the day, with a bit of hand written helper functions in Assembly.
At least this is what I found at the root of every particular inconvenience that used to wear me down at Google until I finally left in August.
Honest question, I'm not after dirty laundry. Just want to know more than "I'm leaving because reasons" which is kinda the tl;dr of that post.
In a world where 4chan can serve 4 million visitors on some dated apache server version running a 10k line PHP script which hasn't been updated since 2015 it's important to remember, that for 95% of all software (if not more), any, general purpose language will be just fine technically speaking and it's in the development processes (the people) the actualy differences are found. Go is productive and maintainable (cost-efficient and rapid changes) for teams that work better without implicit magic and third party depedencies.
The hype may be gone, but the Jobs aren't. In my area of the world Go is the only noticeably growing programming language in regards to job offerings.
1. The standard library has a real HTTP/2 implementation (unlike Python).
2. The Go compiler creates statically-linked binaries and cross-compiling is painless.
3. Channels and goroutines make it relatively easy to write parallel code. There are certainly sharp edges, like every language.
- Pretty decent concurrency built in
- Small language spec that is very easy to read and learn
- A very good and well thought out toolchain and tool ecosystem. This is hard to list as a selling point or quickly summarize but it makes Go code pleasant to work on. Things that other languages have ti have complex third party tooling for are simple and boring in Go.
- If you are writing code that interfaces with Kubernetes or a popular container runtime like Docker or Podman, it is a natural choice.
- Pretty good performance as far as garbage collected runtimes go. Not the best, but really good.
Right. Go is a great language for the server side of web client/server things. It's more reliable than C++, easier than Rust, and is hard-compiled to a read-only executable, which is good for security. Goroutines, which are cheap but can block, get rid of the async/sync distinction. The important libraries are maintained by Google people and used internally, so even the unusual cases are well-exercised.
What more do you want?
There are some Googlers angling for this.
Not that I'm against Rust for network services, but with Rust you're accepting increased complexity for increased safety - a worthwhile tradeoff depending on the project.
I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.
This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison.
For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sum https://github.com/gorilla/mux/blob/main/go.mod
If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps).
I don't think it's bad per se to have deps, just a different culture. https://news.ycombinator.com/item?id=43935067 kinda beat that horse already though
Go is very much faster, you save time and money on computing resources.
Go has built in testing and type support, making it easier To write more reliable and more bug free code.
But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.
I wrote a lot of Go from like 2010 to 2013 or so.
A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go.
I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
No comments yet
I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed.
If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.
I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close).
But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets.
gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.
Having a standard is fine. But software is not just technical, it's an art too.
Would you be willing to make a Long Bet about it? https://longbets.org
I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)
However, I would use Go instead when deploying in cloud providers like Vercel and Netlify, as explained in a sibling comment.
It is easier to just go with the less friction option, and deploying such modules requires not only knowing how to write them, also mastering the whole deployment process, thus not something I would advise in teams with mixed skill levels.
They build on top of AWS Lambda, but do not expose the full capabilities, so Go it is.
Working on DevOps space, most tools related to Docker and Kubernetes are written in Go, as this is its reason to fame. Although Rust is starting to show up as well.
But in reality, TypeScript is probably its only legitimate use-case, and only because it already had very stringent requirements.
Most projects either stick to Node.js, or if they need more efficiency, they get rewritten in C++ or Rust, instead of ported to Go.
well, that's the point. it is excellent language for server programming. and not just faster, it is more stable, scales complexity better, stronger security
Am I understanding you correctly? The Go authors basically expected Go to be just a good starting point or source of ideas for real languages to stand on?
Facebook created Hack, a version of PHP with a quite nice static type system, which is virtually not used outside it. They also had an early statically typed version of JavaScript, called Flow, which enjoyed a limited success, but was supplanted by Typescript.
Haskell, OCaml, Erlang, Smalltalk, etc all enjoyed some success in specific narrow domains, while influencing heavily such mainstream languages as Python, Java, Typescript, Rust, and, well, Go.
Compared to this, Go is unreasonably, blindingly successful; it's now all over the place, but that was hard to predict back in the early days of the project.
It's impressive the go team managed to buck the trend and only got to V2 after so many years.
Go was also created at Google and for Google first and foremost, but ended up wildly popular in general.
(React was also created at Meta and for Meta. Same with Pytorch.)
at least single example in open source or in enterprise who is running Hack? haven't seen even one in 8 years
I shouldn't be surprised, that's like the ideal scenario for PHP. So of course they added strong typing to it.
You’re probably reading what you want to read