I really, really appreciate key people taking the time for retrospectives. It makes a huge difference to people now who want to make a real difference.<p>But I'm not sure Rob Pike states clearly enough what they got right (IMO): they managed the forces on the project as well as the language, by:<p>- Restricting the language to its target use: systems programming, not applications or data science or AI...<p>- Defining the language and its principles clearly. This avoids eons of waste in implementing ambiguity and designing at cross-purposes.<p>- Putting quality first: it's always cheaper for all concerned to fix problems before deploying, even if it's harder for the community or OS contributors or people waiting for new features.<p>- Sharing the community. They maintained strict control over the language and release and core messaging, but they also allowed others to lead in many downstream aspects.<p>Stated but under-appreciated is the degree to which Google itself didn't interfere. I suspect it's because Go actually served its objectives and is critical to Google. I wonder if that could be true today for a new project. It's interesting to compare Dart, which has zero uptake outside Flutter even though there are orders of magnitude more application code than systems code.<p>Go was probably the key technology that migrated server-side software off Java bloatware to native containers. It dominates back-end infrastructure and underlies most of the web application infrastructure of the last 10 years. The benefit to Google and the community from that alternative has been huge. Somehow amidst all that growth, the team remained small and kept all its key players.<p>Will that change?
I picked up Go in 2012 as a Python dev in need to doing some bit twiddling over the wire for Modbus. I never shipped that code but it blew my mind how easy it was to just twiddle those bits and bytes and it just worked.<p>A decade later and a couple almost full time Go jobs under my belt and it still surprises me how well most things Just Work™.<p>I love the Go language and I love the Go community.<p>I appreciate what Rob, Ian, Russ and the others do for Go and I appreciate that this talk / blog is honest about the "bumps in the road" working with the community. There's not much point in beating a dead horse around this but having lived through it I find it very hard to believe they didn't know exactly how they were behaving, especially in regards to the package management debacle. Never the less the blog is also correct that we have landed at a very good solution (Drew's legitimate complaints aside).<p>Here's to another 10 years of Go and the inspired / similar languages (Zig, Deno, etc) and hoping we continue to grow as a healthy community.
(rant)<p>That's nice, but also rather self-congratulatory.
I was expecting some kind of acknowledgment of the deeper issues in the language.
But perhaps that's the central issue, that the language is perfect in their eyes.
I'm the problem.<p>Well, okay then.<p>I can't recommend the language, because of its type system, the error handling, the unsafe concurrency, the simplistic syntax, nil, default zero, and a large number of mainstream packages are abandoned.<p>I now use Rust as my main language. It has a flourishing ecosystem and is visionary in so many ways that Go is not.<p>Put more pointedly, I'm sure Go had its day, when it was competing with PHP as a backend language.
I know I sound salty here, but 10 years ago I got ridiculed on go-nuts, with dismissive comments from Rob Pike, because I dared to suggest that the way go get and module imports over the wire 1. worked, 2. were advertised in all their docs for beginners, and 3. how they were subsequently used throughout the community was ultimately harmful / shortsighted.
This seems like a more personal account of the ACM article they published [1]. In both they recognize that they didn't make a great new programming language in terms of a language specification but instead did a great job building up all the things around programming languages that may end up being even more important.<p>In the submitted article they talk about inventing an approach to using interfaces and also an approach to concurrency. Go routines are identical to Haskell threads and interfaces are very similar to Haskell typeclasses (now that they support generic arguments). Haskell's preceded Go- it's interesting to see procedural programmers independently discover the power of ideas from functional programming.<p>Go's one language innovation is to not require an interface implementation to declare the interface it implements. This is awful from a safety perspective but in practice it causes few issues and gets rid of awful circular dependency issues experienced in Haskell and now Rust.<p>[1] <a href="https://cacm.acm.org/magazines/2022/5/260357-the-go-programming-language-and-environment/fulltext" rel="nofollow">https://cacm.acm.org/magazines/2022/5/260357-the-go-programm...</a>
I haven't seen someone mentioning Go's issues with crypto yet. After OpenSSH deprecated SHA1, the Go team took a year (!) to add support for SHA2 to x/crypto/ssh [1]. Gitea was one famous victim [2]. Furthermore it doesn't instill confidence to see a crypto maintainer bashing on GnuPG [3] and trying to discredit Dan Bernstein [4].<p>[1]: <a href="https://github.com/golang/go/issues/49269">https://github.com/golang/go/issues/49269</a><p>[2]: <a href="https://github.com/go-gitea/gitea/issues/17798">https://github.com/go-gitea/gitea/issues/17798</a><p>[3]: <a href="https://twitter.com/FiloSottile/status/1127643698676797441" rel="nofollow">https://twitter.com/FiloSottile/status/1127643698676797441</a><p>[4]: <a href="https://twitter.com/FiloSottile/status/1555669786826244096" rel="nofollow">https://twitter.com/FiloSottile/status/1555669786826244096</a>
This mentions gofmt as a "what we got right" and I think that's especially worth underscoring.<p>This seems to many language inventors and proponents like a small thing but it delivers huge value because it eliminates one common bike shedding opportunity entirely from day zero of a Go project. I've seen several newer languages embrace this, either copying it quite intentionally or just figuring hey Go has one so we should make one as well.<p>I've seen some pretty weird formatting rules but I have <i>very rarely</i> seen rules I couldn't get used to, whereas I have worked on plenty of codebases without enforced formatting rules where as a result it was harder to understand the code.
> the existence of a solid, well-made library with most of what one needed to write 21st century server code was a major asset.<p>Yes. Go was funded by Google because Google had a problem. They needed to write a lot of server-side application code. Python is too slow, and C++ is too brittle. Go does very well in that niche. A big bonus was that Google people wrote the libraries you need for that sort of thing, and uses them internally. So, when you used a library, it was something where even the error cases were heavily exercised.<p>I have some technical arguments with the language, mainly around the early emphasis on using queues for everything, including making mutexes out of queues. They got the "green thread" thing right for their use case. The "colors of functions" thing is a problem, and the arcane tricks needed to make async and threads play together in Rust are just too much. Go gives up a little performance for great simplicity.<p>I'm amused at the old hostility to threads. I started out on UNIVAC mainframes, which had threads starting in 1967. (They were called "activities") By 1972, there were not only user-space threads, but they ran on symmetrical multiprocessors. There was async I/O, with user-space completion functions.
There were built-in instructions for locks. The operating system was threaded internally.<p>I thought of threads and multiprocessors as normal, and felt the loss of them when moving to UNIX. It was <i>decades</i> before UNIX/Linux caught up in this area. Several generations of programmers had no clue how to use a shared-memory multiprocessor. The early concurrency theory from Dijkstra was re-invented, with different terminology and often worse design than the original. The Go people understood Dijkstra's bounded buffers, and understood why bounded buffers of length 0 and 1 are useful. It was nice seeing that again. With the right primitives, concurrency isn't that hard. If you try to do it by sprinkling locks around, which was the classic pthreads mindset, it will never work right. It didn't help that UNIX/Linux had an early tradition of really crappy CPU dispatchers, so that unblocking a thread worked terribly.
Interesting bit here about the decision to use Ken Thompson's C compiler rather than LLVM --- something that people grumbled about, and that resulted in (especially earlier versions) less optimal generated code. The flip side of that decision is that they were able to do segmented stacks quickly; they might not have done them at all if they'd had to implement them in LLVM and fit the LLVM ABI.<p>(He cites this as an example of the benefit of that decision, not the only benefit).
<i>> Critics often complained we should just do generics, because they are "easy", and perhaps they can be in some languages, but the existence of interfaces meant that any new form of polymorphism had to take them into account.</i><p>I've been noodling on a statically typed hobby language and one of the things I'm trying to tackle is something like interfaces plus generics. And I have certainly found first-hand that Rob is right. It is really hard to get them to play nicely together.<p>I still think it's worth doing. Personally, I'd find it pretty unrewarding to use a statically-typed language that doesn't let me define my own generic types. I used to program in BASIC where you had GOSUB for subroutines but there was no way to write subroutines where you passed arguments to them. I don't care to repeat that experience at the type system level.<p>But I can definitely sympathize with the Go team for taking a long time to find a good design. Designing a good language is hard. Designing a good language with a type system is 10x harder. Designing a good type system with generics is 10x harder than that.
The biggest win for Go is its approach based on composition rather than inheritance.<p>There isn’t any “architect engineer” building cathedrals with interfaces and abstract classes. There’s no cult behind needing to follow DDD in an event-driven architecture powered by a hexagonal architecture in all projects, or you are tagged as a bad engineer. We don’t have thousands of traits to define every possible code interaction, yes. From a type system point of view, Go is lacking compared to HM based type system, yes. Yes, it’s all pros and cons with this decision. We can agree on that.<p>I’ve seen that the predominant enemy for a software project is software engineers. Go keeps them in line for the sake of the project.
GopherConAU organizer here. Here's the whole playlist. I am not sure why I cannot make it public. <a href="https://www.youtube.com/playlist?list=PLN_36A3Rw5hFsJqqs7olOAxxU-WJGlXS0" rel="nofollow">https://www.youtube.com/playlist?list=PLN_36A3Rw5hFsJqqs7olO...</a>
I think two big failures were:<p>1. Nil pointers (two types of them, even!). We knew better even then.<p>2. Insisting that the language doesn't have exceptions, when it does. User code must be exception safe, yet basically never use exceptions. The standard library swallows exceptions (fmt and http)<p>Those are the biggest day to day concrete problems. There are many more that are more abstract, but also hurt.
The post mentioned a few things that Go has done that seem to be "obvious" choices today:<p>- automatic formatting<p>- unified tooling<p>- module/library support<p>I'd add more items to that list, which aren't unique to Go of course, but where Go has clearly contributed to the new consensus:<p>- composition over inheritance<p>- compiling to native binaries<p>- error values over exceptions<p>- array slicing<p>- no automatic integer type conversions<p>There's plenty I don't like about Go, and I rant about it sometimes, but I also respect it. It moved the art forward.<p>...now can I please compile my code with unused variables when I'm deliberately trying to make my tests fail? :-D
Something that I really like about go is how easy it is to make a monorepo, and how quick and easy it is to build all of the contained apps (go build ./...).<p>I also find it really easy to make CLI tools in Go that can form part of unix pipelines, since: you just need a single go file and app-named folder to get started, it gives you a self-contained binary as output, and the Reader/Writer interfaces make it easy to stream and handle data line-by-line. We have a couple of CLIs at work that analyze multi-gig logs in a couple of seconds for common error patterns - Go is very handy for such things.
Maybe I'm misunderstanding here, but it sounds like he's claiming they invented "interfaces". The Go interfaces seem like the same thing as a Haskell typeclass which predates them by a long shot. Either way a great invention that should be in more languages.
Every way I look at it, Go brings tremendous regression when it comes to "modularity & composability" in the general sense of the terms.<p>Package management, package definition, interface definition, exporting, protecting or hiding components, feel like they were an afterthought, and as if specified by people who had absolutely no prior experience in other languages or actively ignored it.<p>There is no nesting of packages in Go. There is no selective visibility protection among packages except on the very first level. Exporting is such an afterthought that it is declared by the change of the first letter to uppercase. Local development of cross-modules was only introduced recently (workspaces) and is extremely primitive (no transitive replacement -- so workspaces depending upon other workspaces is not a thing, workspace-vendoring in the next release but will essentially conflict with mod-vendoring). This probably works with skilled and disciplined teams with strict linters and other tooling, and operating in a large mono-repository or on ultra small codebase. For others, it ends up in a large plate of spaghetti code with no help to untangle, and every single newcomer shedding blood, sweat and tears to wrap their head around a codebase which inexorably became monolithic by the invitation of the very language.<p>All learnings obtained from decades of building very large-scale applications in C++, of managing and publishing packages in Java or C#, was essentially put aside and ignored.<p>The sad but good news is that it's all being progressively rediscovered, but relearning from decades of nuget and maven for example, will take time, effort, exemplary humility and open mindedness.
> And of course, today there is an LLVM-hosted compiler for Go, and many others, as there should be.<p>Isn't that the dead llgo effort?<p><a href="https://github.com/go-llvm/llgo">https://github.com/go-llvm/llgo</a> (now archived)<p>Its readme points to a dead link on the LLVM website, and it looks like there's no matching Go project under the LLVM org.<p>Does anyone know if there really is still a working LLVM based Go toolchain (other than TinyGo)?
Curious as to no mention of the choices around interoperability and C FFI.<p>"Rewrite in go" as the answer closes off a whole chunk of options.
I was surprised at the poor quality of serviceability given its enterprise deployment with k8s. No thread dumps without killing the process (or writing a SIGUSR1 handler). No heapdump reader so you have to use the memory sampler and hope you catch the problem (and that requires adding code), and viewcore is broken in new versions (and it doesn't work with a stripped binary which is most production binaries).
I appreciate that he talked about examples in api documentation. I can't believe people are still writing documentation nowadays without examples.
This is a retrospective written by Rob Pike, one of the creators of the Go language.<p>I worked at Google at the time go was created and had coffee with Rob from time to time and got to understand the reasons Go was created. Rob hates Bjarne Stroustrup and everything C++ (this goes back decades). C++-as-used at Google (which used far more threads that he says) had definitely reached a point where it was extremely cumbersome to work with.<p>I can think of some other things that they got wrong.<p>For example, when I first started talking to Rob and his team about go, I pointed out that scientific computing in FORTRAN and C++ was a somewhat painful process and they had an opportunity to make a language that was great for high performance computing. Not concurrent/parallel servers, but the sorts of codes that HPC people run: heavily multi-threaded, heavily multi-machine, sophsticated algorithms, hairy numerical routines, and typically some sort of interface to a scripting language with a REPL.<p>The answers I got were: Go is a systems programming language, not for scientific computing (I believe they have now relaxed this opinion but the damage was already done).<p>And a REPL wasn't necessary because Go compiled so quickly you could just write a program and run it (no, that misses the point of a repl, which is that it builds up state and lets you call new functions with that built-up state).<p>And scripting language integration was also not a desirable goal, because Go was intended for you to write all your code in Go, rather than invoking FFIs.<p>A number of other folks who used Go in the early days inside Google complained: it was hard to call ioctl, which is often necessary for configuring system resources. They got a big "FU" from the go team for quite some time. IIUC ioctls are still fairly messy in Go (but I'm not an expert).<p>I think Go spent a lot of time implying that goroutines were some sort of special language magic, but I think everybody knows now that they are basically a really good implementation of green threads that can take advantage of some internal knowledge to do optimal scheduling to avoid context switches. It took me a while to work this out, and I got a lot of pushback from the go team when I pointed this out internally.<p>IN short, I think go could have become a first-class HPC language but the go team alienated that community early on and lost the opportunity to take a large market share at a time when Python was exploding in ML.
The anecdote about writing the compiler in C is very interesting. LLVM is obviously very popular these days, so it’s refreshing to see a counter example. I also love that the compiler was decidedly mediocre. It just goes to show that often the user ((or developer) experience is typically more important than the technical merits of a product.
> First, he was generalizing beyond the domain he was interested in [...]<p>And then they proceed to dump on async/await. It's not a target concern for Go but often you want to run code specifically on a UI thread or call into a foreign function on some specific OS thread. AFAICT that's most easily done with async/await.
I’m surprised the fact that they manage to keep the language small and minimal isn’t mentionned as a huge success. To me that is the number one reason to use this language : it forces you to not be distracted by language constructs (there aren’t enough for that), and focus on what is it exactly you’re trying to build. Even as an educationnal tool, this is excellent. Maybe they don’t realize it because they come from C, but when you come from more recent languages that include everything and the kitchen sin, this is a godsend.<p>It’s now to the point that whenever i develop a feature in a language, i ask myself « how would i do that in go » to ensure i don’t go fancy with the type system for no good reasons.
> Also, writing a compiler in its own language, while simultaneously developing the language, tends to result in a language that is good for writing compilers, but that was not the kind of language we were after.<p>I have seen this sentiment a few times recently. First of all, it raises the question is a language that is not compiled in itself a bad language for writing compilers? My intuition is usually yes. Secondly, the implication is that a good language for compilers will not be good for other applications. I really don't understand this because a compiler will use most of the same building blocks that are used for other programs.<p>I would really like more context into what the author is trying to say though.
I made some videos introducing Go. They're not important and the view count isn't impressive at all but it interested me that the one with the most hits is about "Go Project Structure".<p>I have to say I'm not at all a fan of how modules get imported in go - and how it works with github. It's an extremely confusing and complicated issue and my bete noir was forking a library. The way things are exported, the paths you need to use to access them.......the whole area is far worse than the problems I've ever had with C/C++ and certainly Java or Python.
> A key point was the use of a plain string to specify the path in an import statement, giving a flexibility that we were correct in believing would be important.<p><i>Wrong.</i><p>Importing a string is like a touchscreen UI in a car: it's deferring the problem. It's lazy.<p>> But we didn't have enough experience using a package manager with lots of versions of packages and the very difficult problems trying to resolve the dependency graph.<p>No one on the team had ever used Java? Really? Maven was ~8 yeras old when Go was released. It came from previous learnings and errors with Ant. Maven did other things too that aren't necessarily relevant or necessary (eg standardized directory structure). But the dependency system was really solid even if it was verbose because it was XML.<p>> Second, the business of engaging the community to help solve the dependency management problem was well-intentioned<p>This feels ahistorical. It felt more like the problem wasn't understood and/or thought important. This fits in with the importing a string: it's a way of not solving the problem, of kicking the can down the street.
I am not a Go user and the language has never appealed to me. On paper, it offers less than more established ecosystems for generalist backend development, such as C# and Java.<p>Perhaps some Go users can weigh in?
The structure of that post is weird, in that it's quite difficult to figure out where are the parts which were done right and where are those done wrong.<p>Can someone tl;dr the done-wrong items?
I gotta say, reading this tells me exactly why Go struggles to evolve as a language.<p>Go ahead, skimming the article tell me what go got wrong? Stumped? Yeah, well I was too. That's because a lead designer can certainly write paragraphs on paragraphs of "Look at how amazing and kool we are for being so smart" but doesn't seem capable of writing more than a half a sentence of "we got this wrong".<p>I saw 2 things Pike believes go got wrong. Documentation and packaging. The rest is a lot of self congratulatory "Look at how smart we are and how dumb our critics are".<p>No language is perfect, every language has it's own weaknesses (and go has plenty). Yet for some reason Pike can't help but gush over how perfect it is. Even with the 2 faults listed, the documentation fault very much has an undertone of "our functions are so simple but the dumb users weren't smart enough to understand the amazingness of our elegant code and libraries."<p>> The key missing piece was examples of even the simplest functions. We thought that all you needed to do was say what something did; it took us too long to accept that showing how to use it was even more valuable.<p>Go is a language designed in the last 20 years that decided "You know what wasn't bad about C? Pointers and null". Yet the only part pike can really fault is "well, we didn't know how to do package management so we sort of messed that up".<p>He even goes so far as to talk about how interfaces are so good and generics are dumb even though go has the notorious `interface {}` used to try, in an type unsafe way, to pass around random objects. (But hey, pike hand waves that away with "the dumb community just isn't smart enough to accept the brilliance of our type system".)<p>How can a language evolve when the lead designer puts on blinders to the community raising faults? When a "what we got right, what we got wrong" post is filled with how awesome the language is with scant reference to what is wrong? Even just openly dismissing concerns with the language?<p>Contrast that with a lead language architect I really like, Brian Goetz (seriously, go watch his talks about evolving Java). His approach is nearly the polar opposite. It's "Ok, we've seen that a lot of people using java run into problem X, so we are going work hard to find language or library solutions which help improve things for the developers". They very rarely just dismiss problems and when they do it's more along the lines of "Well, we'd love to have it but ultimately there's not a good way we can think of to do this which is also backwards compatible."<p>And you can really see that in the way java has evolved from 8->21. From adopting a faster release process, a ton of new language features, and a LOT of active development into the most painful parts of dev work. Virtual threads is a shining example of this. Java now has go like concurrency even though it took several iterations and trials to bring that in, they worked hard to evolve the language in a way that fits perfectly. Valhalla is another great example of the language working hard to solve real problems. A 10 year project open to the community working to fundamentally redefine the JVM memory model because the one designed in the 90s doesn't fit with modern hardware.<p>But hey, if you like go, that's great. Just don't expect even an iota of evolution. Barring a change in leadership, generics is almost certainly the last new language feature (at least in this decade). A feature that landed primarily because of over a decade of articles and community screaming about how horrible the lack of generics impacts everything.
The fact that he doesn't mention context as a huge failing of Go is very suspect...<p>I also find the post a little too self-congratulatory for what was essentially a reinvention of C with a GC at the right time, and not just C the language, but C's philosophy on programming.<p>I think as Go has become more popular, the core of C has been drowned out by people coming from other languages who insist on too many libraries, too many abstractions, generic solutions at every level, and more features. Go today has essentially moved much closer to Java, and some projects like Kubernetes are without a doubt just Java projects with a slightly different syntax.<p>Concurrency and interfaces I think are also a big fail in Go.<p>Interfaces because they failed to add enough of them to the standard library for simple things like logging, filesystem access, etc, causing numerous incompatible implementations, which is something that wouldn't have happened if they hadn't been so gung-ho on interfaces being defined where they are used instead of having community interfaces.<p>Concurrency is harder to summarize, but day to day you still get locking issues, libraries that don't expose interfaces that are easy to work with via coroutines (which is ironic given rob's finger pointing at async/await coloring), and as I said context is really a prime example of why CSP IS a bad model compared to mailboxes and the Erlang model of concurrency. Every function has to take an extra noisy argument, every function has to wait for a ctx cancellation, instead of just baking the semantics of cancellation into the language itself.
I would have more respect if they at least admitted to the flawed type system but instead say it is not a problem. It is disappointing to see past mistakes repeated in a new programming language. Even the Java language creator was humble enough to admit fault for the null pointer problem. The Go devs do not have such humility.<p><a href="https://github.com/uber-go/nilaway">https://github.com/uber-go/nilaway</a>
I was following the mailing list as this was being developed way back then, but it always frustrated me that the team chose such a trite, un-googleable name for the language. I mean, if you want to find the community and the docs, you have to search for 'golang' which let me tell you, was not an automatic solution to the problem. That's actually my only complaint.
I really wanted to love Go, spent time learning it, bought a few books read it,etc.<p>It did not work out for me for embedded field, it's too large in binary size, no real time due to GC, and I still need to interface with C code here and there.<p>In the end, I'm back to c and c++, I consider my time on Golang is actually totally a waste.<p>Go has its own uses e.g. native cloud or something, even there lots of alternatives exist.<p>It's pretty hard to replace existing popular languages, as those languages are also evolving fast.
The value it’s brought to Google has definitely not been worth the cost. It did not really replace other languages. If you join Google now as a new engineer, you will likely be writing C++, Java, or maybe a web language