I assume it will follow gjc footsteps if no one steps up for maintenance.

GCC has a high bar for having frontends added into the standar distribution, and if there isn't a viable reason why they should be kept around, they get eventually removed.

What kept gcj around for so many years, after being almost left for dead, was that it was the only frontend project that had unit tests for specific compilation scenarios.

Eventually someone took the effort to migrate those tests, and remove gcj.

It has it's niche uses, such as compiling Go for lesser used architectures. It's a bit awkward to not have full language capabilities, but it still feels nicer than writing C/C++.

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

The predictability of the process was not particularly amazing. I just didn't set my expectations very high; with Python and Java... getting readability was on my first quarter OKRs and I accomplished those (my Java readability reviewer was on my team so it was pretty easy). Go... took a while.

I have never been quite sure that that's exactly where you want to draw the line. I've been in the position of having a team that's relatively new to Go, and despite being a straightforward language, there's a lot of things you can do, if you know to do them, that makes the code significantly more reliable. I couldn't review every PR on my team, so sometimes stuff slipped through that caused An Incident and it bugged me because a simple "do this instead of that" would have prevented The Incident.

I asked some other senior folks that had worked at Google "should we do something like Readability" and the answer was a unanimous "absolutely not, no, never" so clearly other people fell more towards your views than mine. People do just want to get their stuff checked in and go home, which I respect. Someone else is then going to have to go to a bunch of calls with customers when it breaks, though. Guess who that was and where her views are on the matter ;)

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.

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

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

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

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.

Or to rephrase, they want reliable, stable developers to actually keep things running instead of impatient people always chasing the next cool thing.

Wasn’t that my point? Innovation is mostly dead there, and it makes sense why people who want to build feel like they need to leave.

Innovation is alive and thriving outside of FANG. And honestly after my experience I don’t get why anyone would work there.

Join a series A-C unicorn track startup and stay like 5 years til IPO. Your vested shares will 10-30x and gg.

I have a lot of friends who went to elite schools (top 5-10 in the world) for CS and some of them have gotten PIP’d or laid off.

It’s not that hard to do well academically. Especially for kumon types.

There’s builder types (rare af) and there’s worker types (plenty aka literally everyone else).

And getting into tech isn’t hard. A principal staff or something like that? Impressive. Senior or staff is not that impressive anymore. Personally I prefer to work with people way, way smarter than me.

I’ve worked with ex-FANG people and they’re robots. They came in after IPO and made me quit lol.

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

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

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's possible for Ian to mean what he says, while also missing additional context (high net worth) that changes the perspective of the reader.

The main reason I’ll quit Google one day is the feeling people have that code reviews can sit and wait for many days. I grind to a halt.

So what you wrote is the most shining endorsement in this whole discussion.

As someone that mostly enjoys the Microsoft ecosystem, that isn't necessarly a good goal.

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.

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

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.

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.

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.

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

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.

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.

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?

In nominal terms, yes, not inflation adjusted.

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.

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.

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.

they are leading LLM for coding like I am leading candidate for President in 2029

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.

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.

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.

Welcome to big corp with Excel driven decisions, sorry, Google Sheets.

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.

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.

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

We used to be a bit bigger than that, with contractors included probably more than double that number.

Officially, I have left the Go team too; I started on a new team at Google a few weeks ago. I still use Go quite a bit, I still talk to people on the Go team regularly, and you will still see the occasional code change, code review, or blog post from me. Most importantly, I have high confidence that the team we built will do an excellent job continuing the work.

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.

As you probably know, Rust ended up with async/await. This video goes deep into that and the alternatives, and it changed my opinions a bit: https://www.youtube.com/watch?v=lJ3NC-R3gSI

Golang differs from Rust by having a runtime underneath. If you're already paying for that, it's probably better to do greenthreading than async/await, which is what Go did. I still find the Go syntax for this more bothersome and error-prone, as you said, but there are other solutions to that.

I can see the appeal for simplicity of concept and not requiring any runtime, but it has some hard tradeoffs. In particular the ones around colored functions and how that makes it feel like concurrency was sort of tacked onto the languages that use it. Being cooperative adds a performance cost as well which I'm not sure I'd be on board with.

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.

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

native GPU (CUDA, BLAS and friends) support would be nice. haha

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.

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

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.

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.

minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.

At a previous job we decided against Go because it's made by Google, and Google has a habit of killing products.

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.

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