by cyphar | 2025-09-25 07:39:49+00:00
> I do recognize this confused the Rust crowd, who bizarrely think that sum types are known as enums, and think that systems are programs that run on raw hardware (think kernels, embedded software, etc.). But nobody else randomly redefines every word they come across.

I was not a Rust developer in 2013 and I still had the same impression. I think that most C developers (which is what I was primarily at the time) would interpret "systems language" to mean "loosely equivalent to C or C++" in that you have a lot of low-level control over what your program does (which usually means you can write operating systems with it, though I don't think that's necessarily a requirement). Go does not fit that bill.

To be honest, I've always felt the Go folks redefined the word and not the other way around. Are web servers very important? Of course, but a programming language intended primarily for performant web servers is not a "systems language". Maybe this usage of the term is a Google-ism that escaped containment. You can probably find comments from me throughout the 2010s bemoaning this (mis)use of the word.

Funnily enough, Russ Cox himself said in 2014 that he "slightly regrets" calling Go a systems programming language because it leads to confusion[1]. There was another panel talk from a long time ago (sadly, I can't find a video of the talk at the moment) where another Go language developer said that a systems programming language is a language that has pointers and allows typecasting of pointers (more specifically, one where you can create a memory allocator) which always seemed like a very low bar to me.

[1]: https://youtu.be/ZQR32nTVF_4?t=408

> Makes sense. The container ecosystem (Docker, Kubernetes, etc.) was originally built as (and for) network servers — the exact niche Go was designed for.

I don't think that's at all accurate. Docker originally needed to do a heck of a lot of core system operations, which it turns out are very annoying to do in Go (I maintain runc, which inherited most of this code -- it's really not fun). Yes, Docker has a HTTP API, but I don't think of it is as being primarily a network server. And whether the process you run is a web server is not incredibly relevant -- most of the heavy lifting for containers is done by the kernel once you've set everything up.

(Of course the first versions of Docker just used LXC so it was slightly less painful but once they started developing libcontainer -- which is around the time I started working on Docker -- the real pain-points with Go started emerging.)

> The Java team did warn the Go team to not to screw up implementing generics like they did. Maybe that's where you got Java in your mind? But the warning was heeded. The generics design Go got is quite different. Or maybe you are thinking of Kubernetes originally being written in Java and being criticized for carrying many of those Java-isms into the Go rewrite?

This is from more than a decade ago now, but I remember that the Russ Cox in particular had a talk about Go's interfaces and my impression of the talk was that he made several references to Java and that they were trying to find a better model than Java's inheritance system while still solving the same problems. Maybe I'm overstating the impact it had (and maybe it was more a case of talk being tailored to a particular audience) but my impression was that interfaces were an attempt to solve something that Java folks wanted but without all of the issues the Java design has. Generics came much later and I think that everyone was unhappy with the result (though thankfully they have slowly become more erognomic, even if in my experience they are still only really useful for utility functions).

I never got the impression that Python was an explicit source of design ideas for Go. Yes, they were all Google people and so all of them were very familiar with Python use in production, but I just don't see it. Maybe you could argue the "batteries included" thing is Python-esque but that's about it.

Also Borg (Google's internal predecessor to Kubernetes) was written in C++[2], not Java. Kubernetes was also always written in Go (again, because Go had become the "container language" due to Docker).

[2]: https://dl.acm.org/doi/pdf/10.1145/2741948.2741964 "All components of Borg are written in C++."

>Perhaps you have already forgotten, but they also evaluated Rust at the time. "It is too hard to learn", they concluded.

Who is "they"? For the Docker example, my memory is that they later said they looked at Rust at the time but it wasn't 1.0 yet in 2012 and so it was a moot point. I think the only other language they seriously considered was C++ and they decided Go would be easier.

> And this is why I ultimately conclude that Go is more like Python and Ruby than it is Rust. More so Python, granted. Ruby's message passing model leads to some different conventions. Put the code for a Python program and a Go program side by side, squint slightly, and you aren't apt to be able to even see a difference. Especially if that Python program actually sticks to the Zen of Python. Put a Python program beside a Rust program and they are going to be completely different animals.

Well, I agree that Go is more like Python than Rust is like Python (though Rust has better support for some of the functional things in Python than Go and there are small things like format strings that are also very similar, but on the whole I would generally agree). But that is an entirely separate question as to why Go and Rust are often compared to one another. In my experience the comparison is not focused on surface-level syntax but is instead about what purpose it serves (this is like the difference between comparing bats, birds, and flying fish to comparing barnacles and shrimp).

That being said, the fact that it is basically impossible to stop the GC from closing the underlying file descriptor of an *os.File (necessitating dup(2) when you're working with libraries that don't like that) is very Python-esque (no, runtime.SetFinalizer doesn't work). You would be surprised with how many times I've run in this issue...