Leaving Google
airs.com
airs.com
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
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.
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.
To a certain extent. No one says you must use the, presumably newer, version of a library using generics or even use libraries at all. Although for any non-trivial program this is probably not how things are going to shake out for you.
> Which likely makes this an increasingly niche case?
This assumes that dependencies in general will on average converge on using generics. If your assertion is that this is the case, I'm going to have to object on the basis that there are a great many libraries out there today that were feature-complete before generics existed and therefore are effectively only receiving bug fix updates, no retrofit of generics in sight. And there is no rule that dictates all new libraries being written _must_ use generics.
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.
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.
It is possible to be direct, honest, and polite.
You should consider the possibility that you're mistaken in linking "rude" with "direct"
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.
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.
‘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.
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 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 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 ;)
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.
That's kinda surprising to hear. I wonder what happened. It would have been easy to leave out these 3 sentences or replace them with fluff. The author choosing to write this out suggests that there is some weight here.
Prior to 2023 I pretty much only ever saw the L7s and L8s that I work with leave Google because there was an exciting new opportunity or because they were retiring. Now most of the people I see leave at this level are leaving because they are fed up with Google. It's a mess.
I joined in 2021. I feel like I caught the tail end of old Google. Any decent idea was greenlit.
Now, it is a lot harder to find resources to do things. (This is of course relative. It is still far easier than any other place I've worked at).
The company has transitioned into something a little more traditional.
IC's natural way of growth is to produce larger impact by solving harder problems, there are always hard unsolved problems which hold some business opportunities.
Most of the actual groundwork has already been laid by passionate, actual engineers.
Today big tech is just a place people go to make money, and they don’t necessarily care about long term vision.
Mostly filled with the most uninspiring, forced-to-do-kumon types who have little “passion” for engineering or computers. Zero imagination and outside the box thinking. Just rote memorization to get in and then getting PIP’d or laid off to go do the same at the other big corps. TC or GTFO types.
Better luck at startups that are the Google’s of yesteryear.
But really, Google was cool. Google was hip. So was Apple. Lots of cool things were coming from those companies between 2000 and 2012 or so. My interest in Meta was similar - the reality labs projects seemed really cool when I looked into them back before all the giant cuts lol.
In addition to those things, these were all seen as companies run by engineers, where the software and the tech was seen as the big core thing the company cared about. People thought programmers at google weren't treated as "cost centers" like they often are at companies where software is just a piece of the puzzle.
But yea, times change. In a way a lot of it was just infatuation and dreams that may not have had a basis in reality.
I believe there is a lot of reality. As well as they gave a lot of brilliant co-workers which seems to have made it a great place to spin ideas. Also from stories too leader ship was at least open to listen to criticism in "thanks God it's Friday" meetings.
While from observing some friends the promotion play was always tough as well. If you wanted to be promoted you always had to use your 20% time "wisely" which for some meant to still work on the main project. For other to strategically work on a side project they could use for the promotion panel.
Today's Google seem to be fully focused on numbers, where a lot of the spirit is gone. Back in the days when I visited some friends working for Google we went to Google for breakfast or met at Google for dinner as it was just a good place to hangout. (Which motivated people to stay at Google for more than their regular hours) Nowadays it seem to be more of a workplace.
Now you go for big tech (and startups). The cliche of the young "banker" personality type is now the "tech" personality type, and is coming soon to an Ai startup near you.
There was a mad rush between mid-1997 and mid-2001 to get into tech, then the dot-com bust happened, but that only lasted about 2 years before things ramped up again. That was 20 years ago.
Suggesting that the first decade of the web didn't flip the bit from finance to tech is ahistorical.
"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.
If you wanted to be on the bleeding edge, you would be applying to mobile phone operators like TMN, Vodafone, Optimus, and then code over a remote telnet connection to HP-UX 11 server.
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.
We had a brief window in the mid 2010s when folks started to throw rocks at the tech buses where I thought people were starting to realize it. Around Bernie's presidential run - which makes sense because he preached wealth inequality. But somehow during COVID tech slithered back into everybody's good graces.
* I don't condone people throwing rocks at the buses for both the humanitarian reasons and the fact that few if any executive or social changes could result from that behavior. But it struck me as a microcosm of the prevailing sentiment towards technology workers.
Is that inherent to the technology, or is that just inherent to the way we've chosen to organize society? Really, any technological paradigm shift going back to the industrial revolution has mainly served to enrich a small few people and families, but that's not some immutable property of technology. Like you say, it's a tool. We've chosen (or allowed) it to be wielded toward one end rather than another. I can smash my neighbor's head in with a hammer, or I can build a home with it.
At one point in the United States, there was political will to update our social structures so that the fruits of technological and economic progress did not go disproportionately to one class of society (think early 20th century trust busting, or the New Deal coming out of the Great Depression). I'm afraid we find ourselves with a similar set of problems, yet the political will to create some other reality beyond further wealth concentration seems to be limited.
Refreshing to hear that stated so clearly.
On your general point, I don't know if I feel the same optimism at this stage, much as I'd love to be proven wrong. Populations seem to never tire of jumping from one tech fairy tale to the next.
Developers seem to never tire of burying their head in the sand either, and I sometimes wonder if the two are correlated.
Why do you think this recent AI push will be the straw that breaks the camel's back? What if the camel just keeps plodding along?
Nevertheless the "parasite" "no societal value" reputation of Banking remains. I would suggest however, that doing M&A is less parasitic and has greater social value than any ad-tech.
That was the end of techy swag wearing for me.
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.
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.
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.
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.
in 1992?
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.
You wrote me original message with less words
At Google? You can. Or they spent it all, in which case the point still applies.
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.
Very, very few people actually work for that long for a tech company these days, at least in the IT sector in Europe.
So what you wrote is the most shining endorsement in this whole discussion.
My dad and before him my uncle “retired” from tech at ~61 too, neither didn’t wrote a blog post
If there are no large companies with original culture after few decades of their founding it would just imply it is nature of things instead of being a particular person as chief executive.
It's powerful to a point. If it tries to flex its power too much, and international military coalition rolls over Saudi Arabia.
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
It kind of make sense also since people blasting management while leaving are mostly not looking to launch their own companies so they will not be proven wrong about their "incisive critique" of management.
He did sound relatively defeated when he accused himself of not accurately predicting the future needs of Go users, as if it were even possible!
Maybe management has just been unjustly critical of his performance, and he's taking it too much to heart? Hard to tell, but I just get that feeling.
This severe decline of the median engineer means comp gets cut back, perks get cut back, and most importantly, autonomy gets cut back. Oppressive process and political gamesmanship reign supreme.
Even when I left nearly a decade ago, the idea that something like Gmail could be made in 20% time was a joke. 20% time itself was being snuffed out and dipshit PMs in turf wars would kill anything that did manage to emerge because it wasn’t “polished enough”.
At this point Google is far beyond recovery because it is inundated with B, C and now D players. It’s following the same trajectory of Intel, Cisco, and IBM.
Pockets of brilliance drowning in mediocrity
https://time.com/43263/gmail-10th-anniversary/#:~:text=Gmail...
What do the other engineers have to do with this? Why are they mediocre?
That hasn’t really been happening - perks and comp have been pretty stable for the past 3+ years at least, so…
I actually attribute it to Ruth more than Sundar, but who really knows? All I know is I saw a major decline...and people were already saying similar things when I joined, and they were probably right too.
This isn't to say Google isn't still a great employer...but yes, perks and comp declined.
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.
How are the free massages and dry cleaning treating you?
I wish I had more elaboration on this paragraph. It seems like a real change happened of which Ian took notice.
"Please add Gemini to the go compiler errors, or take a hike."
I don't think it's wrong per se to suggest that Google should not be in the business of "Go" e.g. but presumably there are many other areas where similar technical expertise can be used in this size of company.
That said I've seen good people get stuck in large companies. They are put in a certain bucket and find it very hard to change. Sometimes leaving is the correct answer.
As someone who switched to Go in its early days (from C++) and had some interaction with the community (bugs, conventions etc.) it's a little sad but I think also just the way things go.
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.
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.
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.
But hey we got a few pretty pictures and funny videos along the way!
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.
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.
What is there to elaborate is what the author really thinks. "Well documented in public" is such nonsense. First of all, what you mean by that is purely subjective. Second, you still don't know what the author really thinks.
The meta meta question is how long was Google ever really in the state that so many engineers remember as a golden age?
I joined google in 2022 (and have since left), even as a newcomer it was obvious that not only was the golden era over, but the era after the golden era was winding down too. The atmosphere wasn't "The reckless innovation is over but lets make the product as great as we can" - it was "Just don't break anything and squeeze out 1 or 2% improvements where possible"
Except countless companies did - many went out of business, and few became Googles.
The historical context is essential but there are so many factors that set them apart.
There is an opportunity to build it.
I think the problem with this gen of companies isn’t tech, it’s culture.
Tech culture is so rampant with ruthless capitalism that it'll never happen again. You used to at least have the sense that there was a will to innovate and experiment. Now it's just oiling the machine.
- College students just in it for the money hadn't taken over yet
- Low interest rates led to lots of investment
- Most people had broadband in developed countries
- Most people had cell LTE smart phones in developed countries
- Compute tech (CPUs, memory) was mature, adequate, and stable
Developers are seen as yet another office job, and unless you make it into manager, you will be always looked down has not having made a name for yourself.
Written as someone approaching 50y, that has been trying to avoid the management trap forever.
> 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's not alone.
Another exec fired the entire Python team (many of whom were core contributors to the language) to replace them with the lower salaried TypeScript team, which was then restaffed by a new team in an even lower salaried locale.
Still a mess and my understanding is that the AI portions of the company were none too happy given that the bulk of their development is done in python.
This was my experience with upper-middle management to VP (sometimes SvP) level at Google. The way they communicate is incomprehensible, it says everything and nothing at the same time – announcements with simultaneous dramatic change and all remains the same – it’s very disorienting. My theory is that its not meant to set direction, or describe a vision, or even goals – rather it converges towards something intended to impress and socially posture against other managers. It’s used as fodder for taking credit during performance review.
One meme I remember is ”you might be a Googler if you cant answer which team you are on in 5 seconds”. The engineers are extremely good (impostor syndrome is widespread), but it feels like they are blindfolded, wandering in different directions. I certainly don’t know how to run a large company. But a good start would be to use plain descriptive language. Evidently, even the corp-speech-whisperers can’t establish a shared reality.
Yes, it's self-preservation behavior. It's a strong indicator that the manager knows they are in a position that provides little to no value, so they need to aggressively preserve it.
Why does a single, non-technical middle manager need authority over multiple PL development teams? It makes no sense. The bare minimum of that position must be to connect technical expertise of the ICs to strategic vision of the C-suite. That is a full-time job, and if it's not being done, there needs to be accountability.
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.
That was mostly an artifact of the free money that gets thrown off as tech advancements are integrated into society.
I've often wondered, when people say this, do they mean their direct managers or the management hierarchy in general? If direct manager only, this only makes sense if they have a lot of leeway to run things how they want. For instance, if a company decides to cut 30% of the workforce and more people (naturally) leave afterward, is it really the direct manager that caused them to leave?
I think people leave "the situation" for all kinds of reasons. If you have a really horrible direct manager, that might be why you leave but it certainly isn't universal.
Yes, people leave jobs for all sorts of reasons, but your direct manager is the one who can most influence your workplace experience while also having a fundamental power imbalance by definition, and so is often the thing people are fleeing if they leave.
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.
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.
In this case I expect it's more related to how the engineering ladder has changed at Google over time, and the effects of cost cutting placing pressure to conform to the ladder, even when the ladder doesn't reward what it necessarily should be rewarding.
That's about as unobtuse as i can be about it, for various reasons.
What I find fascinating is that all of them that come to mind were conceived by people who didn't really understand the space they were operating in and/or had no clear idea of what problem the language solved.
There was Dart, which was originally intended to be shipped as a VM in Chrome until the Chrome team said no.
But Go was originally designed as a systems programming language. There's a lot of historical revisionism around this now but I guarantee you it was. And what's surprising about that is that having GC makes that an immediate non-starter. Yet it happened anyway.
The other big surprise for me was that Go launched without external dependencies as a first-class citizen of the Go ecosystem. For the longest time there were two methods of declaring them: either with URLs (usually Github) in the import statements or with badly supported manifests. Like just copy what Maven did for Java. Not the bloated XML of course.
But Go has done many things right like having a fairly simple (and thus fast to compile) syntax, shipping with gofmt from the start and favoring error return types over exceptions, even though it's kind of verbose (and Rust's matching is IMHO superior).
Channels were a nice idea but I've become convinced that cooperative async-await is a superior programming model.
Anyway, Go never became the C replacement the team set out to make. If anything, it's a better Python in many ways.
Good luck to Ian in whatever comes next. I certainly understand the issues he faced, which is essentially managing political infighting and fiefdoms.
Disclaimer: Xoogler.
They haven't taken off as Xerox PARC, ETHZ, Dec Olivetti, Compaq, Microsoft desired more due to politics, external or internal (in MS's case), than technical impediments.
Hence why I like the way Swift and Java/Kotlin[1] are pushed on mobile OSes, to the point "my way or get out".
I might discuss about many of Go's decisions regarding minimalism language design, however I will gladly advocate for its suitability as systems language.
The kind of systems we used to program for a few decades ago, compilers, linkers, runtimes, drivers, OS services, bare metal deployments (see TamaGo),...
[0] - Any form of GC, as per computer science definition, not street knowledge.
[1] - The NDK is relatively constrained, and nowadays there is Kotlin Native as well.
Curious as to your reasoning around this? I've never heard this opinion before from someone not biased by their programming language preferences.
Unbuffered channels basically operate like cooperate async/await but without the explictness. In cooperative multitasking, putting something on an unbuffered channel is essentially a yield().
An awful lot of day-to-day programming is servicing requests. That could be HTTP, an RPC (eg gRPC, Thrift) or otherwise. For this kind of model IMHO you almost never want to be dealing with thread primitives in application code. It's a recipe for disaster. It's so easy to make mistakes. Plus, you often need to make expensive calls of your own (eg reading from or writing to a data store of some kind) so there's no really a performance benefit.
That's what makes cooperative async/await so good for application code. The system should provide compatible APIs for doing network requests (etc). You never have to worry about out-of-order processing, mutexes, thread pool starvation or a million other issues.
Which brings me to the more complicated case of buffered channels. IME buffered channels are almost always a premature optimization that is often hiding concurrency issues. As in if that buffered channels fills up you may deadlock where you otherwise wouldn't if the buffer wasn't full. That can be hard to test for or find until it happens in production.
But let's revisit why you're optimizing this with a buffered channel. It's rare that you're CPU-bound. If the channel consumer talks to the network any perceived benefit of concurrency is automatically gone.
So async/await doesn't allow you to buffer and create bugs for little benefit and otherwise acts like unbuffered channels. That's why I think it's a superior programming model for most applications.
It shouldn't be too difficult to address testing of buffered systems at implementation time. Possibly pragma/compile-time capabilities allowing for injecting 'delay' in the sink side to trivially create "full buffer" conditions and test for it.
There are no golden hammers because the problem domain is not as simple as a nail. Tradeoffs and considerations. I don't think I will ever ditch either (shallow, preferred) buffers or channels. They have their use.
The reality is though that you are directly fighting or reimplementing the OS scheduler.
I haven’t found an abstraction that does exactly what I want but unfortunately any sort of structured concurrency tends to end up with coloured functions.
Something like C++ stdexec seems interesting but there are still elements of function colouring in there if you need to deal with async. The advantage is that you can compose coroutines and synchronous code.
For me I want a solution where I don’t need to care whether a function is running on the async event loop, a separate thread, a coprocessor or even a different computer and the actor/CSP model tends to model that the best way. Coroutines are an implementation detail and shouldn’t be exposed in an API but that is a strong opinion.
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.
Google has lots of processes handling protobuf requests written in both Java and C++. (Or at least, it did at the time I was there. I don’t think Go ever got out of third place?)
GC[0] works for servers because network latency will dominate allocation latency; so you might as well use a heap scanner. But I wouldn't ever want to use GC in, say, audio workloads; where allocation latency is such a threat that even malloc/free has to be isolated into a separate thread so that it can't block sample generation. And that also means anything that audio code lives in has to not use GC. So your audio code needs to be written in a systems language, too; and nobody is going to want an OS kernel that locks up during near-OOM to go scrub many GBs of RAM.
[0] Specifically, heap-scanning deallocators, automatic refcount is a different animal.
Interpreters are a whole different thing. Go is pretty terrible for writing a fast interpreter since you can’t do low-level unsafe stuff like NaN boxing. It’s okay if performance isn’t critical.
And if you consider K&R C a systems language, you would do it like back in the day, with a bit of hand written helper functions in Assembly.
You mean an OS kernel, like Java Real Time running bare metal, designed in a way that it can even tackle battleship weapons targeting systems?
I wish people would have the courage to explain what led to their decision to leave big projects, instead of trying to be overly polite. This statement virtually says nothing and the whole post boils down to nothing but: I left Google.
> When the two compilers differed, we knew that we had to clarify the spec and figure out what the right behavior should be.
This idea of having two implementations for spec stood out for me.
This guy must have been pretty high up maybe at senior staff / principal for several years at least. A principal can probably draw >$1M per year.
Would it be in $50M-$100M range?
Honest question, I'm not after dirty laundry. Just want to know more than "I'm leaving because reasons" which is kinda the tl;dr of that post.
In a world where 4chan can serve 4 million visitors on some dated apache server version running a 10k line PHP script which hasn't been updated since 2015 it's important to remember, that for 95% of all software (if not more), any, general purpose language will be just fine technically speaking and it's in the development processes (the people) the actualy differences are found. Go is productive and maintainable (cost-efficient and rapid changes) for teams that work better without implicit magic and third party depedencies.
The hype may be gone, but the Jobs aren't. In my area of the world Go is the only noticeably growing programming language in regards to job offerings.
1. The standard library has a real HTTP/2 implementation (unlike Python).
2. The Go compiler creates statically-linked binaries and cross-compiling is painless.
3. Channels and goroutines make it relatively easy to write parallel code. There are certainly sharp edges, like every language.
- Pretty decent concurrency built in
- Small language spec that is very easy to read and learn
- A very good and well thought out toolchain and tool ecosystem. This is hard to list as a selling point or quickly summarize but it makes Go code pleasant to work on. Things that other languages have ti have complex third party tooling for are simple and boring in Go.
- If you are writing code that interfaces with Kubernetes or a popular container runtime like Docker or Podman, it is a natural choice.
- Pretty good performance as far as garbage collected runtimes go. Not the best, but really good.
Right. Go is a great language for the server side of web client/server things. It's more reliable than C++, easier than Rust, and is hard-compiled to a read-only executable, which is good for security. Goroutines, which are cheap but can block, get rid of the async/sync distinction. The important libraries are maintained by Google people and used internally, so even the unusual cases are well-exercised.
What more do you want?
There are some Googlers angling for this.
Not that I'm against Rust for network services, but with Rust you're accepting increased complexity for increased safety - a worthwhile tradeoff depending on the project.
I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
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.
However, I would use Go instead when deploying in cloud providers like Vercel and Netlify, as explained in a sibling comment.
It is easier to just go with the less friction option, and deploying such modules requires not only knowing how to write them, also mastering the whole deployment process, thus not something I would advise in teams with mixed skill levels.
They build on top of AWS Lambda, but do not expose the full capabilities, so Go it is.
Working on DevOps space, most tools related to Docker and Kubernetes are written in Go, as this is its reason to fame. Although Rust is starting to show up as well.
But in reality, TypeScript is probably its only legitimate use-case, and only because it already had very stringent requirements.
Most projects either stick to Node.js, or if they need more efficiency, they get rewritten in C++ or Rust, instead of ported to Go.
well, that's the point. it is excellent language for server programming. and not just faster, it is more stable, scales complexity better, stronger security
Am I understanding you correctly? The Go authors basically expected Go to be just a good starting point or source of ideas for real languages to stand on?
Facebook created Hack, a version of PHP with a quite nice static type system, which is virtually not used outside it. They also had an early statically typed version of JavaScript, called Flow, which enjoyed a limited success, but was supplanted by Typescript.
Haskell, OCaml, Erlang, Smalltalk, etc all enjoyed some success in specific narrow domains, while influencing heavily such mainstream languages as Python, Java, Typescript, Rust, and, well, Go.
Compared to this, Go is unreasonably, blindingly successful; it's now all over the place, but that was hard to predict back in the early days of the project.
It's impressive the go team managed to buck the trend and only got to V2 after so many years.
Well there’s at least Slack, and another huge project (which has eventually migrated away from it once PHP has improved) with tens of millions of users. There has to be others, too.
Go was also created at Google and for Google first and foremost, but ended up wildly popular in general.
(React was also created at Meta and for Meta. Same with Pytorch.)
at least single example in open source or in enterprise who is running Hack? haven't seen even one in 8 years
You’re probably reading what you want to read