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…
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.
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 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.
There are some Googlers angling for this.
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.
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.
90s_dev•4h 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•4h ago
You’re probably reading what you want to read
lowmagnet•3h ago
nine_k•3h 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•3h ago
nine_k•2h 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•2h 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•2h ago
tuan•2h ago
nikolayasdf123•1h ago
scripturial•2h ago
cdogl•3h ago