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 ?
> GCC Go does not support generics, so it's currently not very useful.
I don't think a single one of the Go programs I use (or have written) use generics. If generics is the only sticking point, then that doesn't seem to be much of a problem at all.
I just used them today to sort a list of browser releases by their publication date. They're not universal hammers but sometimes you do encounter something nail shaped that they're great at.
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.
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.
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.
I personally prefer to be given brutal honesty. Overly polite people often annoy me because they hide information or they can't get to the point or their point is hidden within layers of wishy-washy mush that I need to correctly parse and then respond correctly to.
Politeness is absolutely necessary, and I hate seeing callous impoliteness in wider society (e.g. towards service workers).
I suspect I would severely struggle in a deeply polite society (stereo-typically Asian?). I can relax the most around very direct people (Dutch?).
I am continually stressed when dealing with anyone that absolutely needs politeness. Example 1: a very close friend who can be triggered by anything reminding them of their abusive ex. Example 2: a self-centred acquaintance that needs pandering (however isn't polite in return).
There's a balance - but it's hard to find. Perhaps I'm confusing two different dimensions, politeness and honesty?
Edit: This is a wishy-washy comment. Difficult topic, straight-jacketed conflict, interpersonal stuff that is hard to understand and talk about.
> I think that "polite" and "honest" and "direct" are orthogonal.
They are certainly correlated so not orthogonal, its much harder to not be rude when you communicate a complaint than with praise.
You need to put much more effort in when you complain about something to not be seen as rude, that means they are not orthogonal. It also means many will just not do it since its too much work.
Or it means you haven’t practiced and some parts of the space are more difficult for you to traverse individually but still orthogonal objectively. I would say that something isn’t orthogonal if it is impossible to be both. It is clearly possible, just not practiced or easy.
I could grant there is also an objective friction surface, a fourth scalar describing how difficult it is to be direct, honest, and polite at once.
I feel similarly about overly-agreeable people, or people who bend over backwards to do everything in their power to make sure everyone around them likes them.
For me, it stems from seeing when someone changes their behavior or words in a way that's no longer authentic to themselves. I like when people are real with me.
But being real or authentic also isn't an excuse to be a jerk.
I don't have time for the overly polite fluff talk to the expense of practical and real communication. It is hard to be caring and direct. Being triggered by anything can be ptsd, and/or a self defense mechanism for incompetence, so it's important to work out what is going on in these cases. But yes, it is absolutely possible to be caring and gracious while still being direct when you exclude the people who will over react as a self defense mechanism as a result of valid or invalid reasons.
If you see someone do it well (the word ‘genteel’ comes to mind) you can find that verbos it and awkwardness will detract from both the directness and honesty.
‘Traditional’ etiquette books are actually pretty good at this stuff: one definition of etiquette is to never out another ill at ease or uncomfortable. Discomfort is contagious especially through body language, so the first thing you must do is be comfortable yourself with the feedback you’re giving.
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.
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 ;)
I'm glad you had that experience with Go readability, because mine was far from that. Java readability taught me loads. Go readability taught me almost nothing and took far longer. In the end I was given it when I emailed the admins to say "either give me some feedback or give me readability". I'm fully behind the readability concept, but it's hard to scale and keep the quality high.
> 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.
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.
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).
> 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.
This is almost a myth. Think of it this way: you can either manage 5 people that solve a problem or you can solve a problem yourself that it would've taken 5 people to solve. At the end of the day, it's the scale of the problem that matters (not the technical "hardness"). Are there sometimes problems that one domain expert can solve, effectively and fully, that it would've taken 5 generalists to solve otherwise? Sure. Is it common? Not in "big tech".
> Think of it this way: you can either manage 5 people that solve a problem
there are levels of problem you will struggle to find 5 people to solve it on avg senior dev salary
> Not in "big tech".
especially in big tech, where there is constant arm race in building systems handling millions QPS over petabytes of data and with all recent advanced AI.
> there are levels of problem you will struggle to find 5 people to solve it on avg senior dev salary
You're agreeing with me even though you think you're disagreeing. Yes it is hard for one person (one senior dev salary) to solve large problems most of the time.
> where there is constant arm race in building systems handling millions QPS over petabytes of data and with all recent advanced AI.
Yes I'm saying that at that scale it's very hard to solve the problem by yourself.
My point is that in certain domains your regular devs can't solve problem, there are some 10x experts who can solve it.
For some problems, one 10x expert could be enough, for others you need some team (small), and they will be able to achieve results where NNN randomly hired senior devs from the market won't produce useful product.
So, the goal of IC is to become such 10x expert if he wants to grow as engineer and not as manager.
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.
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.
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.
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.
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.
> 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?
I lament the "more wood, fewer arrows" tgif, the weird Android guy (Rubin) having too much power, and the Emerald Sea (Gundotra) project for shifting Google to what it has become today
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.
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.
I still think it was different in the early 2000s, even after the dot com bubble.
"Big Tech" had not been assembled yet. Microsoft was the only tech megacorp in town, and they were _hated_ back then. Apple was still recovering from shambles. Google was a startup nobody heard of. Facebook wasn't a thing yet.
Tech investment money wasn't on the same scale as today. Money was measured in millions instead of the billions today. Most of the money I think was still towards finance at the time. If you look at the public companies with largest market cap before 2010 ( https://en.wikipedia.org/wiki/List_of_public_corporations_by... ), you'll see there's quite a couple banks on the list.
You're absolutely correct though that this trend was foreseeable in the 1990s. Which is kinda why the dot-com boom/bust happened -- everyone knew it was the future, I guess people were just a bit too excited for the future, and the companies who'd actually create that future weren't even founded yet, leading to all the mis-investment and subsequent bust.
Tech only started attracting real attention starting in 2008 when finance imploded. I remember very well that nerds/geeks were still considered weird outcasts back then. After the financial meltdown, tech really exploded and offered a much better lifestyle than finance, and thus became more accepted in American society.
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.
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.
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.
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)
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.
I was not at FAANG, but a unicorn startup back in mid to late 2010s, and I was making 150-180k in that time, but not in SF.
Rent back then for a 2br was like $2400.. Today, that same apartment goes for $4900.
I am pretty sure the base for the same level today is probably more like 170-200k, but literally everything has also become doubly expensive.
Also if you're in SF you either need to allocate another 300-400 a month for parking, or sell your car. I was paying 130 per month for my garage parking spot (again, not in SF), and when I moved to SF some time ago I sold my car because it was going to cost me a lot to use my car.
And unlike FANG, where you can either hold and double every 3-4 years if lucky, or sell immediately with taxes, I walked away with 10x or more..
Rent was (and is) around $4000 for 3br, shared between 2 people. (And this was not an unusual price to see during our apartment hunt a few years ago.) If you're paying $4900 for 2br in the city, my impression is that it's either a brand new development or in a posh area like Pac Heights.
I don't have a car, but I feel like that's one of the biggest privileges of living in the city. Maybe the calculus changes if you have kids, though.
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.
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.
> 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.
Fundamentally and writ large, tech makes us more efficient. Efficient means doing more with less labor. Which is good because it is deflationary: things get cheaper over time from tech advances, and without any tech we would all be subsistence farmers.
But it also means that yes, tech intrinsically enables capital to do more with less labor, thereby shifting the balance of power towards capital and empowering those with more capital.
What ‘we decide’ to do with that is another largely unrelated matter.
> 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?
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.
> Mostly filled with the most uninspiring, forced-to-do-kumon types
What a strange thing to say. You’re describing the elite pedigreed type with this, but then allude to the types of people that PIPed. I really don’t think elite pedigreed types get PIPed outside of rare situations.
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."
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.
> How much of their salary went straight in to their landlord's pockets? Towards student loan interest?
I don’t think comments like these really understand the incredible value of FAANG comp over the past 20 years. People who got and kept these jobs had a true golden ticket.
Paying rent and student loan interest are a rounding error.
These were not normal jobs in normal circumstances.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
I'd be interested in utilization. When I was there and had my kids, it was 12 weeks, and I never took the full 12 weeks because it was too long for me. (I took 6, the 7, then 4-5 IIRC.)
That's bullshit. Inflation-adjusted compensation has been on a decline (nevermind the decision to reschedule the bonus/promotion cycle from January to April).
At least half of the micro-kitchens and cafes have been shutdown. On-site tech support has been dropped. Medical benefits support was changed from Anthem premium to some third-party that is worse than useless. Medical plan costs are up and covered benefits down. Hardware refreshes (even for engineers) has been cancelled, so everyone is working with pre-pandemic hardware.
Ian is a multi millionaire that went to Yale that probably thinks the rest of us outside of the Google/elite bubble are subhuman, why is this assumption when it’s more likely that he just hit his fatFIRE target?
just a quick response, i have asked a few Go questions that he (ILT) has answered on public forums. i don't work at google and never have. but he was clear and thoughtful with me. most of all, he was helpful.
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.
> ... 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.
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.
He's at a level where he's part of that technical buffer layer.
And that's likely the problem. (Note: my speculation. I haven't read his internal goodbye and wouldn't make it public if I had). An L6 with a good L8 for air cover can kinda hide behind the SI rating, and because they never have direct contact with VPs, they can continue doing the necessary-but-not-glamorous part of keeping Google going. An L8/L9 has that direct contact with VPs, so there's nowhere to hide.
Go particularly is a sort of fixed ceiling project.
Ian recently had a really pleasant error handling proposal that nonetheless wasn’t going to change the core philosophy of error handling, or memory arenas are another area where the current tradeoffs are fine and not worth reengineering, etc.
IMHO Go is in excellent shape as far as hitting needs when it’s a good technical fit - it’s supposed to be a really stable language - and paradoxically this also may mean not everyone who’s been involved would have the same job description in the future.
That’s fine. A lot of really excellent Go team members have come and gone over the years. Russ and Ian may be some of the late leavers in a sense, so I really, really appreciate their dedication and followthrough. The culture they stewarded has payed off for the community and the kinds of upcoming things that look promising are less about the core language, more about improving and maintaining the standard library.
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.
What’s there to elaborate? It’s well documented in public.
Anti-trust trouble.
Poor leadership selling out the company for short term gains.
Palpable shift from a technology company that was unrivaled for a long time to yet another Microsoft/IBM clone.
No longer a leader in the industry and simply following trends and riding the waves (the AI trend…)
Bending the knee to governments with questionable history and supporting projects with implication of death of citizens.
"Do no evil", my ass.
Bro was fed up with the constant smoke that was blown up his ass. And lies pushed down his throat. Probably timed this exit with vesting/options maturity.
> No longer a leader in the industry and simply following trends and riding the waves (the AI trend…)
While they missed out on the first major commercialization of LLMs, they invented transformers and now have the leading LLM for coding and second best or potentially best training hardware in the world, designed in house, which they started working on before the current boom and kept improving.
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"
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.
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.
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.
Well, it’s a more nuanced answer. Over time, regularly squeezing 1-2% out of search results in an vastly inferior product which flips from primarily serving its users to serving its payers. Eventually, that will mean certain death as others are willing to take on bigger bolder risks. We have pretty good evidence from other long established companies that this constant pressure to extract money from products is a failing strategy.
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.
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).
As a fellow Go developer, I want to express my deep gratitude for your immense contributions to the language and its community. Your work has not only shaped Go into the productive and enjoyable language it is today, but has also inspired countless engineers—including myself—to build better software. Thank you for your dedication and for paving the way for the next generation of Go developers. Wishing you all the best in your future endeavors!
Interestingly, the blog has very few posts. What I would really like to read is a follow up to https://www.airs.com/blog/archives/552 (“The 2016 Election”)
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.
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...
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.
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.
> 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.
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
People sometimes know where they want to get, often that place can be described with buzzwords. They don't always know how to get there. Clueless managers often don't know how to get there, they might only have an inkling as to what are some of the properties of their desired state.
They will talk about that subset of things, they cannot do anything else for they are not aware of the how, much less the whole picture. Once the teams deliver a state with the desired and the unspecified and undesired properties, the team and the manager get angry.
> 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.
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.
I don’t understand why this aphorism appeals to people.
I’ve most definitely left bad companies where I’ve had good managers and I know my experience is not unique.
When it gets to the point where people are pointing at executives as the “managers” that they’re leaving, do people just not realize that companies are run by high-level managers?
It’s a vacuous statement that holds some strange appeal for some people, but it’s not particularly insightful nor accurate.
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.
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.
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.
People are, indeed, almost always leaving the situation.
But at least in my experience, it's still the case in the past few years that every time someone has told me they were "quitting this job", versus "excited about this new job", it was specifically about their direct manager's effects on the situation.
(Sample sizes for any individual small, of course.)
Either way, I still think the saying is useful for intentionally reminding people of how much influence your direct manager can have on your work experience, because I've found a lot of people, particularly new hires, don't appreciate how much your experience can vary across managers.
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.
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!
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.
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".
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?
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.
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.
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.
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.
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.
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.
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.
“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?)
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.
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.
You don't (usually) inherit the performance characteristics of your compiler, but you do inherit the performance characteristics of the language your compiler implements.
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.
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?)
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.
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.
Google should spin Go out into a non-profit foundation and give it $1 billion and send it on its way. They should beg Russ Cox run it as benevolent dictator for life, and hope he can hire Ian Lance Taylor back.
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?
Why do people think they are so important to announce their departures instead of stating plainly that they hit their retirement number? Or just not state anything at all?
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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
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.
> 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.
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.
> 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.
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.
minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.
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.
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.
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.
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
> 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?
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.
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.
This is exactly what I was thinking about. Back then there wasn’t an anti google sentiment (or if so, it wasn’t strong) But now this sentiment would hinder a new language. Thankfully go has launched well enough that I think it can live on and shed itself of any potential negative associations some people might have.
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.
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.
[0]: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS
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 ?
GCC Go does not support generics, so it's currently not very useful.
> GCC Go does not support generics, so it's currently not very useful.
I don't think a single one of the Go programs I use (or have written) use generics. If generics is the only sticking point, then that doesn't seem to be much of a problem at all.
I just used them today to sort a list of browser releases by their publication date. They're not universal hammers but sometimes you do encounter something nail shaped that they're great at.
You’re also at the mercy of the libraries you use, no? Which likely makes this an increasingly niche case?
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.
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.
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.
I personally prefer to be given brutal honesty. Overly polite people often annoy me because they hide information or they can't get to the point or their point is hidden within layers of wishy-washy mush that I need to correctly parse and then respond correctly to.
Politeness is absolutely necessary, and I hate seeing callous impoliteness in wider society (e.g. towards service workers).
I suspect I would severely struggle in a deeply polite society (stereo-typically Asian?). I can relax the most around very direct people (Dutch?).
I am continually stressed when dealing with anyone that absolutely needs politeness. Example 1: a very close friend who can be triggered by anything reminding them of their abusive ex. Example 2: a self-centred acquaintance that needs pandering (however isn't polite in return).
There's a balance - but it's hard to find. Perhaps I'm confusing two different dimensions, politeness and honesty?
Edit: This is a wishy-washy comment. Difficult topic, straight-jacketed conflict, interpersonal stuff that is hard to understand and talk about.
I think that "polite" and "honest" and "direct" are orthogonal.
It is possible to be direct, honest, and polite.
You should consider the possibility that you're mistaken in linking "rude" with "direct"
> I think that "polite" and "honest" and "direct" are orthogonal.
They are certainly correlated so not orthogonal, its much harder to not be rude when you communicate a complaint than with praise.
You need to put much more effort in when you complain about something to not be seen as rude, that means they are not orthogonal. It also means many will just not do it since its too much work.
Or it means you haven’t practiced and some parts of the space are more difficult for you to traverse individually but still orthogonal objectively. I would say that something isn’t orthogonal if it is impossible to be both. It is clearly possible, just not practiced or easy.
I could grant there is also an objective friction surface, a fourth scalar describing how difficult it is to be direct, honest, and polite at once.
I feel similarly about overly-agreeable people, or people who bend over backwards to do everything in their power to make sure everyone around them likes them.
For me, it stems from seeing when someone changes their behavior or words in a way that's no longer authentic to themselves. I like when people are real with me.
But being real or authentic also isn't an excuse to be a jerk.
Being polite and being direct simultaneously can be tricky to realize but not impossible. The best communicators manage to achieve both.
I don't have time for the overly polite fluff talk to the expense of practical and real communication. It is hard to be caring and direct. Being triggered by anything can be ptsd, and/or a self defense mechanism for incompetence, so it's important to work out what is going on in these cases. But yes, it is absolutely possible to be caring and gracious while still being direct when you exclude the people who will over react as a self defense mechanism as a result of valid or invalid reasons.
I think you can be polite and direct, but at the cost of being verbose and awkward.
If you see someone do it well (the word ‘genteel’ comes to mind) you can find that verbos it and awkwardness will detract from both the directness and honesty.
‘Traditional’ etiquette books are actually pretty good at this stuff: one definition of etiquette is to never out another ill at ease or uncomfortable. Discomfort is contagious especially through body language, so the first thing you must do is be comfortable yourself with the feedback you’re giving.
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.
Same!
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 ;)
I'm glad you had that experience with Go readability, because mine was far from that. Java readability taught me loads. Go readability taught me almost nothing and took far longer. In the end I was given it when I emailed the admins to say "either give me some feedback or give me readability". I'm fully behind the readability concept, but it's hard to scale and keep the quality high.
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.
> 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.
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.
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.
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).
> 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.
This is almost a myth. Think of it this way: you can either manage 5 people that solve a problem or you can solve a problem yourself that it would've taken 5 people to solve. At the end of the day, it's the scale of the problem that matters (not the technical "hardness"). Are there sometimes problems that one domain expert can solve, effectively and fully, that it would've taken 5 generalists to solve otherwise? Sure. Is it common? Not in "big tech".
> Think of it this way: you can either manage 5 people that solve a problem
there are levels of problem you will struggle to find 5 people to solve it on avg senior dev salary
> Not in "big tech".
especially in big tech, where there is constant arm race in building systems handling millions QPS over petabytes of data and with all recent advanced AI.
> there are levels of problem you will struggle to find 5 people to solve it on avg senior dev salary
You're agreeing with me even though you think you're disagreeing. Yes it is hard for one person (one senior dev salary) to solve large problems most of the time.
> where there is constant arm race in building systems handling millions QPS over petabytes of data and with all recent advanced AI.
Yes I'm saying that at that scale it's very hard to solve the problem by yourself.
My point is that in certain domains your regular devs can't solve problem, there are some 10x experts who can solve it.
For some problems, one 10x expert could be enough, for others you need some team (small), and they will be able to achieve results where NNN randomly hired senior devs from the market won't produce useful product.
So, the goal of IC is to become such 10x expert if he wants to grow as engineer and not as manager.
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.
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.
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.
> 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.
[flagged]
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.
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.
Some of my best work is done when I’m just dicking around.
Can you share any examples? We're you dicking around and created a new database?
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.
Feynman has an excellent write-up on this very point.
TL;DR - some of his Nobel-winning work began as dicking around.
> 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?
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.
Two people affiliated with Google won Nobel prize last year.
I lament the "more wood, fewer arrows" tgif, the weird Android guy (Rubin) having too much power, and the Emerald Sea (Gundotra) project for shifting Google to what it has become today
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.
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.
I still think it was different in the early 2000s, even after the dot com bubble.
"Big Tech" had not been assembled yet. Microsoft was the only tech megacorp in town, and they were _hated_ back then. Apple was still recovering from shambles. Google was a startup nobody heard of. Facebook wasn't a thing yet.
Tech investment money wasn't on the same scale as today. Money was measured in millions instead of the billions today. Most of the money I think was still towards finance at the time. If you look at the public companies with largest market cap before 2010 ( https://en.wikipedia.org/wiki/List_of_public_corporations_by... ), you'll see there's quite a couple banks on the list.
You're absolutely correct though that this trend was foreseeable in the 1990s. Which is kinda why the dot-com boom/bust happened -- everyone knew it was the future, I guess people were just a bit too excited for the future, and the companies who'd actually create that future weren't even founded yet, leading to all the mis-investment and subsequent bust.
Tech only started attracting real attention starting in 2008 when finance imploded. I remember very well that nerds/geeks were still considered weird outcasts back then. After the financial meltdown, tech really exploded and offered a much better lifestyle than finance, and thus became more accepted in American society.
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.
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.
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.
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.
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)
That's the avg initial comp package but the stock had a pretty nice run so a lot of people are making 600k++.
I’ll be that guy, but $300k pre-tax at current cost of life is not an insane number at all.
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.
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.
Said like a 1990's banker / a 2020's tech worker.
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.
What was your rent though?
I was not at FAANG, but a unicorn startup back in mid to late 2010s, and I was making 150-180k in that time, but not in SF.
Rent back then for a 2br was like $2400.. Today, that same apartment goes for $4900.
I am pretty sure the base for the same level today is probably more like 170-200k, but literally everything has also become doubly expensive.
Also if you're in SF you either need to allocate another 300-400 a month for parking, or sell your car. I was paying 130 per month for my garage parking spot (again, not in SF), and when I moved to SF some time ago I sold my car because it was going to cost me a lot to use my car.
And unlike FANG, where you can either hold and double every 3-4 years if lucky, or sell immediately with taxes, I walked away with 10x or more..
Rent was (and is) around $4000 for 3br, shared between 2 people. (And this was not an unusual price to see during our apartment hunt a few years ago.) If you're paying $4900 for 2br in the city, my impression is that it's either a brand new development or in a posh area like Pac Heights.
I don't have a car, but I feel like that's one of the biggest privileges of living in the city. Maybe the calculus changes if you have kids, though.
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
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.
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.
> 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.
Fundamentally and writ large, tech makes us more efficient. Efficient means doing more with less labor. Which is good because it is deflationary: things get cheaper over time from tech advances, and without any tech we would all be subsistence farmers.
But it also means that yes, tech intrinsically enables capital to do more with less labor, thereby shifting the balance of power towards capital and empowering those with more capital.
What ‘we decide’ to do with that is another largely unrelated matter.
> 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?
What should individual developers do?
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.
Because that’s what tech companies want today. They don’t want hackers and shit, they want corporate automatons who will code for scraps.
> Mostly filled with the most uninspiring, forced-to-do-kumon types
What a strange thing to say. You’re describing the elite pedigreed type with this, but then allude to the types of people that PIPed. I really don’t think elite pedigreed types get PIPed outside of rare situations.
What if I told you that ...
in 1992?
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."
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.
> You can't just assume someone has F-you money just because they worked for 20 years.
At Google? You can. Or they spent it all, in which case the point still applies.
> How much of their salary went straight in to their landlord's pockets? Towards student loan interest?
I don’t think comments like these really understand the incredible value of FAANG comp over the past 20 years. People who got and kept these jobs had a true golden ticket.
Paying rent and student loan interest are a rounding error.
These were not normal jobs in normal circumstances.
For the most part, yes, yes you can.
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
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.
It only takes a spouse with a personality disorder and a divorce to change the calculus.
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.
That's not what Ian said, and he always says what he means.
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.
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.
You’re forgetting that they also want the adulation that comes with leaving and everyone singing their praises.
My dad and before him my uncle “retired” from tech at ~61 too, neither didn’t wrote a blog post
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.
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.
As someone that mostly enjoys the Microsoft ecosystem, that isn't necessarly a good goal.
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.
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.
I wouldn't call Google the world's most powerful company. Saudi Aramco, for example, has more power.
> 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.
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
Wrong Ian -- Ian Hickson wrote about that in a blogpost, this post is about Ian Lance Taylor
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.
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.
I think management started turning the screws. They're doing that everywhere. Management isn't technical anymore.
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.
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.
[1]: https://nerdy.dev/ex-googler
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.
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.
It is almost the same, Anders Hejlsberg still colaborates with the .NET / C# teams, however others now drive where it goes.
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.
> 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.
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.
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)
Not to mention the current push to "grow" in low cost locations. Google is laying off people in the US but rapidly hiring in India and Poland.
Management is more technical fallacied than it's ever been: HR believe they are fine tunng for good.
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.
Pockets of brilliance drowning in mediocrity
Gmail wasn't created with 20% time.
https://time.com/43263/gmail-10th-anniversary/#:~:text=Gmail...
I think the main point remains (skunk work is now impossible)
The purpose of 20% time was to allow things like gmail to be created
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.
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?
> 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…
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.
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.
I'd be interested in utilization. When I was there and had my kids, it was 12 weeks, and I never took the full 12 weeks because it was too long for me. (I took 6, the 7, then 4-5 IIRC.)
Depends what profile you are trying to invest in.
Important or motivating? It is not the same thing. For older people that already have kids, parental leave is useless.
Inflation goes up, perk and comp stay the same, is the same as a % cut
That's bullshit. Inflation-adjusted compensation has been on a decline (nevermind the decision to reschedule the bonus/promotion cycle from January to April).
At least half of the micro-kitchens and cafes have been shutdown. On-site tech support has been dropped. Medical benefits support was changed from Anthem premium to some third-party that is worse than useless. Medical plan costs are up and covered benefits down. Hardware refreshes (even for engineers) has been cancelled, so everyone is working with pre-pandemic hardware.
In nominal terms, yes, not inflation adjusted.
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?
They don't have that anymore
Ian is a multi millionaire that went to Yale that probably thinks the rest of us outside of the Google/elite bubble are subhuman, why is this assumption when it’s more likely that he just hit his fatFIRE target?
> probably thinks the rest of us outside of the Google/elite bubble are subhuman
If you're wondering why your message got flagged, it's a lot of reasons, but mostly this part.
just a quick response, i have asked a few Go questions that he (ILT) has answered on public forums. i don't work at google and never have. but he was clear and thoughtful with me. most of all, he was helpful.
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.
> ... 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.
Probably asked to make it more AI or something.
"Please add Gemini to the go compiler errors, or take a hike."
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".
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.
He's at a level where he's part of that technical buffer layer.
And that's likely the problem. (Note: my speculation. I haven't read his internal goodbye and wouldn't make it public if I had). An L6 with a good L8 for air cover can kinda hide behind the SI rating, and because they never have direct contact with VPs, they can continue doing the necessary-but-not-glamorous part of keeping Google going. An L8/L9 has that direct contact with VPs, so there's nowhere to hide.
Go particularly is a sort of fixed ceiling project.
Ian recently had a really pleasant error handling proposal that nonetheless wasn’t going to change the core philosophy of error handling, or memory arenas are another area where the current tradeoffs are fine and not worth reengineering, etc.
IMHO Go is in excellent shape as far as hitting needs when it’s a good technical fit - it’s supposed to be a really stable language - and paradoxically this also may mean not everyone who’s been involved would have the same job description in the future.
That’s fine. A lot of really excellent Go team members have come and gone over the years. Russ and Ian may be some of the late leavers in a sense, so I really, really appreciate their dedication and followthrough. The culture they stewarded has payed off for the community and the kinds of upcoming things that look promising are less about the core language, more about improving and maintaining the standard library.
Sundar has to go before he drives Google completely into the ground. What an absolute waste.
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.
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.
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.
Without going into the aforementioned detail, would you say he burned his bridges on the way out?
No.
It’s a big club and we aren’t in it
What’s there to elaborate? It’s well documented in public.
Anti-trust trouble.
Poor leadership selling out the company for short term gains.
Palpable shift from a technology company that was unrivaled for a long time to yet another Microsoft/IBM clone.
No longer a leader in the industry and simply following trends and riding the waves (the AI trend…)
Bending the knee to governments with questionable history and supporting projects with implication of death of citizens.
"Do no evil", my ass.
Bro was fed up with the constant smoke that was blown up his ass. And lies pushed down his throat. Probably timed this exit with vesting/options maturity.
> No longer a leader in the industry and simply following trends and riding the waves (the AI trend…)
While they missed out on the first major commercialization of LLMs, they invented transformers and now have the leading LLM for coding and second best or potentially best training hardware in the world, designed in house, which they started working on before the current boom and kept improving.
they are leading LLM for coding like I am leading candidate for President in 2029
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?
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"
> 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.
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.
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.
"The early bird gets the worm, but the second mouse gets the cheese."
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.
Well, it’s a more nuanced answer. Over time, regularly squeezing 1-2% out of search results in an vastly inferior product which flips from primarily serving its users to serving its payers. Eventually, that will mean certain death as others are willing to take on bigger bolder risks. We have pretty good evidence from other long established companies that this constant pressure to extract money from products is a failing strategy.
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.
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.
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.
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
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).
It's still Google.
As a fellow Go developer, I want to express my deep gratitude for your immense contributions to the language and its community. Your work has not only shaped Go into the productive and enjoyable language it is today, but has also inspired countless engineers—including myself—to build better software. Thank you for your dedication and for paving the way for the next generation of Go developers. Wishing you all the best in your future endeavors!
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
While there can be other signs of management not doing so good, let’s not forget that this person is leaving after 19 years.
They are putting all their cards in AI, they see it as an existential battle. They are probably right
Interestingly, the blog has very few posts. What I would really like to read is a follow up to https://www.airs.com/blog/archives/552 (“The 2016 Election”)
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.
[1]: https://ln.hixie.ch/?start=1700627373
> 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.
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...
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.
The TypeScript team was in Munich, and then became the Python team. The new TypeScript team is in Mexico.
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.
This is shocking.
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.
This is a symptom of seeing the whole world through the small narrow lens of "money is everything".
Welcome to big corp with Excel driven decisions, sorry, Google Sheets.
This is sickening
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.
> 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.
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
People sometimes know where they want to get, often that place can be described with buzzwords. They don't always know how to get there. Clueless managers often don't know how to get there, they might only have an inkling as to what are some of the properties of their desired state.
They will talk about that subset of things, they cannot do anything else for they are not aware of the how, much less the whole picture. Once the teams deliver a state with the desired and the unspecified and undesired properties, the team and the manager get angry.
> 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.
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.
As they say, people join companies, but people but people leave (because of) their managers.
I don’t understand why this aphorism appeals to people.
I’ve most definitely left bad companies where I’ve had good managers and I know my experience is not unique.
When it gets to the point where people are pointing at executives as the “managers” that they’re leaving, do people just not realize that companies are run by high-level managers?
It’s a vacuous statement that holds some strange appeal for some people, but it’s not particularly insightful nor accurate.
>> 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.
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.
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.
People are, indeed, almost always leaving the situation.
But at least in my experience, it's still the case in the past few years that every time someone has told me they were "quitting this job", versus "excited about this new job", it was specifically about their direct manager's effects on the situation.
(Sample sizes for any individual small, of course.)
Either way, I still think the saying is useful for intentionally reminding people of how much influence your direct manager can have on your work experience, because I've found a lot of people, particularly new hires, don't appreciate how much your experience can vary across managers.
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.
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!
> 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.
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.
The other kind of free money, that goes to people of the fun side of the unevenly-distributed future by nature of their having a tech advantage.
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.
Ah, yes, assigning "resources".
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".
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?
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.
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.
I’m curious what he means by Google changing and the Go project changing
re: Go, I did wonder if there was any connection to Russ leaving (https://news.ycombinator.com/item?id=41132669)
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.
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.
yes, looks like related
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.
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.
> 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.
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.
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.
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.
“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?)
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.
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?
https://www.ptc.com/en/products/developer-tools/perc
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.
You don't (usually) inherit the performance characteristics of your compiler, but you do inherit the performance characteristics of the language your compiler implements.
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.
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.
is there a language that implements cooperative async-await patterns nicely?
I mean, they claimed that one didn't need generics in the language for some 12 years or so ...
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?)
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.
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.
Probably boutique architectures or operating systems the official compiler doesn't support.
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.
Google should spin Go out into a non-profit foundation and give it $1 billion and send it on its way. They should beg Russ Cox run it as benevolent dictator for life, and hope he can hire Ian Lance Taylor back.
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?
Why do people think they are so important to announce their departures instead of stating plainly that they hit their retirement number? Or just not state anything at all?
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.
Go still has strong leadership. They are just not as prominently known externally.
same. Go is so powerful because of its core. without core, ecosystem will fall apart
Hugged to death, so https://archive.is/RbkzW
Posts like this really show how resilient C has been over the past few *decades•. Who will invest in Go now that Google doesn’t care about anything ?
[flagged]
19 years! Congratulations for making it out!!
What are the good use cases for Go today? It looks like the hype has gone.
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.
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.
It is also conveniently easy to compile everything into a single file, using embed, and this helps with deployment in a few ways.
I love how readable it is, even by people who don't know Go.
- 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.
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.
> 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?
native GPU (CUDA, BLAS and friends) support would be nice. haha
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.
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.
I can't agree they're on par based on function coloring and slow compile times alone.
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.
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
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.
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.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
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.
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.
> 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.
Was it this article?
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
If you haven't touched Go since 2013, give it another try. Quite a lot of the developer QOL has improved.
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.
> 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.
> This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.
Would you be willing to make a Long Bet about it? https://longbets.org
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.)
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.
Go's performance is in a totally different class than node.
Depends if nodejs C++ AddOns are part of the picture or not.
minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.
I put it in the same category as Clojure and where I hope Rust eventually ends up: stable, boring, and capable with healthy ecosystems
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.
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
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.
Where you want to just cut code without drama (and dramatic people).
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.
service to service communication. GRPC + Protobufs + Go allow ease of development and resuse.
Using gRPC in Go is really inconvenient in comparison to some other languages.
Kubernetes custom operators
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.
With all due respect, I am fairly confident that the view you have is formed in a bubble .
> 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
> 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?
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.
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.
At a previous job we decided against Go because it's made by Google, and Google has a habit of killing products.
This is exactly what I was thinking about. Back then there wasn’t an anti google sentiment (or if so, it wasn’t strong) But now this sentiment would hinder a new language. Thankfully go has launched well enough that I think it can live on and shed itself of any potential negative associations some people might have.
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.
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.
hack was created at meta for meta...
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.)
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
https://slack.engineering/streamlining-your-workflow-debuggi...
> which is especially useful when writing strongly-typed code to support variable payload structures in API calls.
I shouldn't be surprised, that's like the ideal scenario for PHP. So of course they added strong typing to it.
wow. no way... slack is on hack! is this toy project for them or some sub-system? hard to believe. interesting if this is true!
My point exactly.
I read it as simple humbleness, which is not too surprising given the careful management of the project and the tone of the piece.
No, you editorialized it by adding the word “real”
You’re probably reading what you want to read
no, they expected to have good ideas others can follow.
[dead]