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.
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.
He did sound relatively defeated when he accused himself of not accurately predicting the future needs of Go users, as if it were even possible!
Maybe management has just been unjustly critical of his performance, and he's taking it too much to heart? Hard to tell, but I just get that feeling.
This severe decline of the median engineer means comp gets cut back, perks get cut back, and most importantly, autonomy gets cut back. Oppressive process and political gamesmanship reign supreme.
Even when I left nearly a decade ago, the idea that something like Gmail could be made in 20% time was a joke. 20% time itself was being snuffed out and dipshit PMs in turf wars would kill anything that did manage to emerge because it wasn’t “polished enough”.
At this point Google is far beyond recovery because it is inundated with B, C and now D players. It’s following the same trajectory of Intel, Cisco, and IBM.
Pockets of brilliance drowning in mediocrity
https://time.com/43263/gmail-10th-anniversary/#:~:text=Gmail...
That hasn’t really been happening - perks and comp have been pretty stable for the past 3+ years at least, so…
I actually attribute it to Ruth more than Sundar, but who really knows? All I know is I saw a major decline...and people were already saying similar things when I joined, and they were probably right too.
This isn't to say Google isn't still a great employer...but yes, perks and comp declined.
How are the free massages and dry cleaning treating you?
What do the other engineers have to do with this? Why are they mediocre?
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.
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.
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.
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?
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.
People see their cousin's uncle's neighbor's roommate making $400K at Meta and just assume every single employee there makes that much. Or they point to those salary sharing sites where people self-report their best salary + highest possible bonus + equity as if every year was 2021, and think of them as representative.
Every single employee, no. But the average L5 really does make over $300k in total compensation. Yes some of that is stock, but the companies are now stable enough so that doesn't cause a ton of variation.
Household. A married couple both making that are 98th percentile.
In what percentile of your social class do you sit with $300k? Probably not very high.
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)
There was a mad rush between mid-1997 and mid-2001 to get into tech, then the dot-com bust happened, but that only lasted about 2 years before things ramped up again. That was 20 years ago.
Suggesting that the first decade of the web didn't flip the bit from finance to tech is ahistorical.
The big tech firms finally started doing RSU's insteda of stock options in the early 2000's, though most startups still were (and are) lagging way behind.
But really, Google was cool. Google was hip. So was Apple. Lots of cool things were coming from those companies between 2000 and 2012 or so. My interest in Meta was similar - the reality labs projects seemed really cool when I looked into them back before all the giant cuts lol.
In addition to those things, these were all seen as companies run by engineers, where the software and the tech was seen as the big core thing the company cared about. People thought programmers at google weren't treated as "cost centers" like they often are at companies where software is just a piece of the puzzle.
But yea, times change. In a way a lot of it was just infatuation and dreams that may not have had a basis in reality.
I believe there is a lot of reality. As well as they gave a lot of brilliant co-workers which seems to have made it a great place to spin ideas. Also from stories too leader ship was at least open to listen to criticism in "thanks God it's Friday" meetings.
While from observing some friends the promotion play was always tough as well. If you wanted to be promoted you always had to use your 20% time "wisely" which for some meant to still work on the main project. For other to strategically work on a side project they could use for the promotion panel.
Today's Google seem to be fully focused on numbers, where a lot of the spirit is gone. Back in the days when I visited some friends working for Google we went to Google for breakfast or met at Google for dinner as it was just a good place to hangout. (Which motivated people to stay at Google for more than their regular hours) Nowadays it seem to be more of a workplace.
God forbid
The web is way more mature right now than 20 or even 10 years ago. There's way lass untouched niches waiting to be filled by the new killer product. And Google already owns the search market, the ads market, the smartphone market, the email market, the browser market, the maps market, and soon maybe AI market, etc. What new untapped multi billion market is left for them to conquer? The pond is already fished out at this point. So of course most Googlers are gonna have to be factory workers keeping the factory running instead of dicking around creating new useless things that bring in maybe no significant revenue. The days of Google & Co. spending billions on pipe dreams is over for now.
Innovation is at start-ups which Google then buys because it has ad revenue. People go to work at Google because it pays well and less headaches than working at startups, not because they're gonna invent something new.
Google is proof that yes, it does create innovation. How many products and tools came out of people dicking around?
What new product has Google launched recently that it didn't cancel? Google's main money makers are all still products from 15-20 years ago.
Given all this it's proof that no, paying people to dick around doesn't generate more creativity once you peaked.
in 1992?
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.
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
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.
Go is very much faster, you save time and money on computing resources.
Go has built in testing and type support, making it easier To write more reliable and more bug free code.
But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.
I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close).
But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets.
gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.
Having a standard is fine. But software is not just technical, it's an art too.
Would you be willing to make a Long Bet about it? https://longbets.org
I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)
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 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.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.
This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison.
For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sum https://github.com/gorilla/mux/blob/main/go.mod
If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps).
I don't think it's bad per se to have deps, just a different culture. https://news.ycombinator.com/item?id=43935067 kinda beat that horse already though
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.
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.
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?
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
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.
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.
- 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.
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.
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
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.
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.
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.
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.
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?
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.
> 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.
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.
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.
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 team members, we might bump into them in another situation.
The company, it is all about numbers and meeting projections.
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.
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 ;)
Had a great experience contributing to the project, and Ian was a big part of that. Which for a big project like Go says a lot.
I tried to push back on one of his comments as well.
Imo it just feels kinda cool that someone who really really knows what they are doing gave you a stamp of approval on something.
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.
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.
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'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.
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.
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.
90s_dev•17h ago
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?
chubot•17h ago
You’re probably reading what you want to read
lowmagnet•17h ago
nine_k•17h ago
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.
nick__m•17h ago
nine_k•16h ago
Go was also created at Google and for Google first and foremost, but ended up wildly popular in general.
(React was also created at Meta and for Meta. Same with Pytorch.)
nikolayasdf123•16h ago
at least single example in open source or in enterprise who is running Hack? haven't seen even one in 8 years
nine_k•16h ago
tuan•16h ago
nikolayasdf123•15h ago
90s_dev•7h ago
I shouldn't be surprised, that's like the ideal scenario for PHP. So of course they added strong typing to it.
scripturial•16h ago
throw-the-towel•13h ago
xiphias2•10h ago
darthwalsh•4h ago
It's impressive the go team managed to buck the trend and only got to V2 after so many years.
cdogl•17h ago