7 ms·

I totally agree that Go is best suited outside of systems programming, but to me that always seemed like a complete accident - its creators explicitly said thei

I totally agree that Go is best suited outside of systems programming, but to me that always seemed like a complete accident - its creators explicitly said their goal was to replace C++. But somehow it completely failed to do so, while simultaneously finding enormous success as a statically typed (and an order of magnitude faster) alternative to Python.

threeseed 3y ago
> (and an order of magnitude faster) alternative to Python Python is increasingly an easy to use wrapper over low-level C/C++ code. So in many use cases it is faster than Go.
- justinclift 3y ago
  Than pure Go code, sure. But not really faster than Go code that's a wrapper over the same low-level C/C++ code.
  - Merovius 3y ago
    That depends. C function call overhead for Go is quite large (it needs to allocate a larger stack, put it on its own thread and prevent pre-emption) and possibly larger than for CPython, which relies on calling into C for pretty much everything it does, so obviously has that path well-optimized. So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go.
    - gwd 3y ago
      > So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go. I don't have experience with Python, but I can definitely say switching between Go and C is super slow. I'm using a golang package which is a wrapper around SQLite: at some point I had a custom function written as a call-back to a Go function; profiling showed that a huge amount of time was spent in the transition code marshalling stuff back and forth between Go and C. I ended up writing the function in C so that the C sqlite3 library could call it directly, and it sped up my benchmarks significantly, maybe 5x. Even though sqlite3 is local, I still end up trying to minimize requests and data shipped out of the database, because transferring data in and out is so expensive. (And if you're curious, yes I have considered trying to use one of the "pure go" sqlite3 packages; in large part it's a question of trust: the core sqlite3 library is tested fantastically well; do I trust the reimplementations enough not to lose my data? The performance would have to be pretty compelling to make it worth the risk.) I think in general discouraging CGo makes sense, as in the vast majority of cases a re-implementation is better in the long run; so de-prioritizing CGo performance also makes sense. But there are exceptions, particularly for libraries where you want functionality to be identical, like sqlite3 or Qt, and there the CGo performance is a distinct downside.
  - iainmerrick 3y ago
    Do you have an example of that? What I’ve heard over and over in comments here is that a) C interop in Go is slow, and b) Go devs discourage using it. (Java is a similar story in my experience.) In Python, (b) at least is definitely not true.
    - deleted 3y ago
      [deleted]
usrusr 3y ago
Go appears to be made with radical focus on a niche that isn't particularly well specified outside the heads of its benevolent directorate for life. Opinionated to the point of "if you use Go outside that unnamed niche you got no-one to blame but yourself". Could almost be called a solution looking for a problem. But it also appears to be quite successful at finding problem-fit, no doubt helped by the clarity of that focus. They've been very open about what they consider Go no to be or ever become. Unlike practically every other language, they all seem to eventually fall into the trap of advertising themselves with what boils down to "in a pinch you could also use it for everything else". It's quite plausible that before Go, its creators would have chosen C++ for problems they consider in "The Go Niche". That would be perfectly sufficient to declare it a C++ replacement in that niche. Just not a universal C++ replacement.
- pjmlp 3y ago
  Consider this, the authors have fixed some of the Plan 9 design errors including the demise of Alef, by creating Inferno and Limbo (yeah it was a response to Java OS, but still). Where C is only used for the Inferno kernel, Limbo VM (with a JIT) and little else like Tk bindings, everything else in Inferno is written in Limbo. Replace Limbo with AOT compiled Go, and that is what systems programming is in the minds of UNIX, Plan 9 and Inferno authors.
fishywang 3y ago
>its creators explicitly said their goal was to replace C++ so nowadays when we say "c++" we mostly mean the works should be replaced by rust, but back then, it's not like that. I would argue that go successfully replaced c++ in specific domains (network, etc.), and changed your perspective on what "c++" means.
- zozbot234 3y ago
  That's nothing new, Java successfully replaced C++ in enterprise code in the mid-to-late 1990s. Because it was safe from memory bugs.
  - lanstin 3y ago
    Mid 2000s in my experience. And not because it was safe from memory bugs so much as safe from memory leaks. Still had plenty of NPEs.
    - justinclift 3y ago
      Java kind of gets around the memory leak problem by allocating all of the leak up front for the JVM. ;)
      - cryptos 3y ago
        I'm a JVM guy, but this is a good one :-)
    - pjmlp 3y ago
      NPE isn't a memory corruption bug.
    - kaba0 3y ago
      Those are safe. And it’s not like Go didn’t just copy nulls (plus even has shitty initialization problems now, e.g. with make!)
    - worik 3y ago
randomdata 3y ago
Except it did replace C++ in the domains it claimed it would replace C++ in. It made clear from day one that you wouldn't write something like a kernel in it. It was never trying to replace every last use of C++. You may have a point that Python would have replaced C++ in those places instead if Go had never materialized. It was clear C++ was already on the way out, with Python among those starting to push into its place around the time Go was conceived. Go found its success in the places where Python was also trying to replace C++.
- bcrosby95 3y ago
  What domains are those? It seems to mostly be an alternative to what people have use(d) Java or C# for.
  - randomdata 3y ago
    The original Go announcement spells it all out pretty nicely.
- deleted 3y ago
  [deleted]
- jeswin 3y ago
  > You may have a point that Python would have replaced C++ in those places instead if Go had never materialized. I don't think Python was starting to occupy C++ space; they have entirely different abilities. Of course, I am also glad it didn't happen.
  - randomdata 3y ago
    I don't think so either, but as we move past that side tangent and return to the discussion, there was the battle of the 'event systems'. Node.js was also created in this timeframe to compete on much the same ground. And then came Go, after which most contenders, including Python, backed down. If you are writing these kinds of programs today, it is highly likely that you are using Go, Node.js, or some language that is even newer than Go (e.g. Rust or Elixir). C++ isn't even on the consideration list anymore.
Thaxll 3y ago
And yet most popular tools written in Go used to be written in C++, Kubernetes, Databases and the like.
- lmm 3y ago
  Kubernetes mostly displaced tools written in Ruby (Puppet, Chef, Vagrant) or Python (Ansible, Fabric?). While a lot of older datastores are written in C++, new ones that were started post-2000ish tended to be written in Java or similar.
  - Thaxll 3y ago
    Kuberentes has nothing to do with Ruby / Python from your example it's far more complex and needs performance, what you described are not what k8s is doing. Kubernetes is the equivalent of Borg /Omega at Google which is written in C++.
    - lmm 3y ago
      > Kuberentes has nothing to do with Ruby / Python from your example it's far more complex and needs performance, what you described are not what k8s is doing. It's what Kubernetes is being used for in most places where I've seen it used. > Kubernetes is the equivalent of Borg /Omega at Google which is written in C++. Maybe, but most Kubernetes users aren't Google and weren't using those things.
unscaled 3y ago
It's not at "an accident" and Go didn't "somehow" fail to replace C++ at its systems programming domain. The reason why go failed to replace C and C++ is not a mystery to anyone: Mandatory GC and a rather heavyweight runtime. When the performance overhead of having a GC is less significant than the cognitive overhead of dealing with manual memory management (or the Rust borrow checker), Go was quite successful: Command line tools and network programs. Around the time Go was released, it was certainly touted by its creators as a "systems programming language"[1] and a "replacement for C++"[2], but re-evaluating the Go team's claims, I think they didn't quite mean in the way most of us interpreted them. 1. The Go Team members were using "systems programming language" in a very wide sense, that include everything that is not scripting or web. I hate this defintion with passion, since it relies on nothing but pure elitism ("Systems language are languages that REAL programmers uses, unlike those "Scripting Languages"). Ironically, this usage seems to originate from John Ousterhout[3], who is himself famous for designing a scripting language (Tcl). Ousterhout's definition of "system programming language" is: Designed to write applications from scratch (not just "glue code"), performant, strongly typed, designed for building data structures and algorithms from scratch, often provide higher-level facilities such as objects and threads. Ousterhout's definition was outdated even back in 2009, when Go was released, let alone today. Some dynamic languages (such as Python with type hints or TypeScript) are more strongly typed than C or even Java (with its type erasure). Typing is optional, but so it is in Java (Object), and C (void*, casting). When we talk about the archetypical "strongly typed" language today we would refer to Haskell or Scala rather than C. Scripting languages like Python and JavaScript were already commonly used "for writing applications from scratch" back in 2009, and far from being ill-adapted for writing data structures and algorithms from scratch, Python became the most common language that universities are using for teaching data structures and algorithms! The most popular dynamic languages nowadays (Ruby, Python, JavaScript) all have objects, and 2 out of 3 (Python and Ruby) have threads (although GIL makes using threads problematic in the mainstream runtimes). The only real differentiator that remains is raw performance. The widely accepted definition of a "systems language" today is "a language that can be used to systems software". Systems software are either operating systems or OS-adjacent software such as device drivers, debuggers, hypervisors or even complex beasts like a web browser. The closest software that Go can claim in this category is Docker, but Docker itself is just a complex wrapper around Linux kernel features such as namespaces and cgroups. The actual containerization is done by these features which are implemented in C. During the first years of Go, the Go language team was confronted on golang-nuts by people who wanted to use go for writing systems software and they usually evaded directly answering these questions. When pressed, they would admit that Go is not ready for writing OS kernels, at least not now[4][5][6], but GC could be disabled if you want to[7] (of course, there isn't any way to free memory then, so it's kinda moot). Eventually, the team came to a conclusion that disabling GC is not meant for production use[8][9], but that was not apparent in the early days. Eventually the references for "systems language" disappeared from Go's official homepage and one team member (Andrew Gerrand) even admitted this branding was a mistake[10]. In hindsight, I think the main "systems programming task" that Rob Pike and other members at the Go team envisioned was the main task that Google needed: writing highly concurrent server code. 2. The Go Team members sometimes mentioned replacing C and C++, but only in the context of specific pain points that made "programming in the large" cumbersome with C++: build speed, dependency management and different programmers using different subsets. I couldn't find any claim that go was meant as a general replacement for C and C++ anywhere from the Go Team, but the media and the wider programming community generally took Go as a replacement language for C and C++. When you read through the lines, it becomes clear that the C++ replacement angle is more about Google than it is about Go. It seems that in 2009, Google was using C++ as the primary language for writing web servers. For the rest of the industry, Java was (and perhaps still is) the most popular language for this task, with some companies opting for dynamic languages like Python, PHP and Ruby where performance allowed. Go was a great fit for high-concurrency servers, especially back in 2009. Dynamic languages were slower and lacked native support for concurrency (if you put aside Lua, which never got popular for server programming for other reasons). Some of these languages had threads, but these were unworkable due to GIL. The closest thing was frameworks Twisted, but they were fully asynchronous and quite hard to use. Popular static languages like Java and C# were also inconvenient, but in a different way. Both of these languages were fully capable of writing high-performance servers, but they were not properly tuned for this use case by default. The common frameworks of the day (Spring, Java EE and ASP.net) introduced copious amounts of overhead, and the GC was optimized for high throughput, but it had very bad tail latency (GC pauses) and generally required large heap sizes to be efficient. Dependency management, build and deployment was also an afterthought. Java had Maven and Ivy and .Net had NuGet (in 2010) and MSBuild, but these where quite cumbersome to use. Deployment was quite messy, with different packaging methods (multiple JAR files with classpath, WAR files, EAR files) and making sure the runtime on the server is compatible with your application. Most enthusiasts and many startups just gave up on Java entirely. The mass migration of dynamic language programmers to Go was surprising for the Go team, but in hindsight it's pretty obvious. They were concerned about performance, but didn't feel like they had a choice: Java was just too complex and Enterprisey for them, and eeking out performance out of Java was not an task easy either. Go, on the other hand, had the simplest deployment model (a single binary), no need for fine tuning and it had a lot of built-in tooling from day one ("gofmt", "godoc", "gotest", cross compilation) and other important tools ("govet", "goprof" and "goinstall" which was later broken into "go get" and "go install") were added within one year of its initial release. The Go team did expect server programs to be the main use for Go and this is what they were targeting at Google. They just missed that the bulk of new servers outside of Google were being written in dynamic languages or Java. The other "surprising use" of Go was for writing command-line utilities. I'm not sure if the original Go team were thinking about that, but it is also quite obvious in hindsight. Go was just so much easier to distribute than any alternative available at the time. Scripting languages like Python, Ruby or Perl had great libraries for writing CLI programs, but distributing your program along with its dependencies and making sure the runtime and dependencies match what you needed was practically impossible without essentially packaging your app for every single OS and distro out there or relying on the user to be a to install the correct version of Python or Ruby and then use gem or pip to install your package. Java and .NET had slow start times due to their VM, so they were horrible candidates even if you'd solve the dependency issues. So the best solution was usually C or C++ with either the "./configure && ./make install" pattern or making a static binary - both solutions were quite horrible. Go was a winner again: it produced fully static binaries by default and had easy-to-use cross compilation out of the box. Even creating a native package for Linux distros was a lot easier, so all you add to do is package a static binary. [1]: https://opensource.googleblog.com/2009/11/hey-ho-lets-go.html https://opensource.googleblog.com/2009/11/hey-ho-lets-go.htm... [2]: https://web.archive.org/web/20091114043422/http://www.golang.org/ https://web.archive.org/web/20091114043422/http://www.golang... [3]: https://users.ece.utexas.edu/~adnan/top/ousterhout-scripting.pdf https://users.ece.utexas.edu/~adnan/top/ousterhout-scripting... [4]: https://groups.google.com/g/golang-nuts/c/6vvOzYyDkWQ/m/3T1DD47AHKcJ https://groups.google.com/g/golang-nuts/c/6vvOzYyDkWQ/m/3T1D... [5]: https://groups.google.com/g/golang-nuts/c/BO1vBge4L-o/m/lU1_LQp_tpIJ https://groups.google.com/g/golang-nuts/c/BO1vBge4L-o/m/lU1_... [6]: https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/NH0jskB_xF0J https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/NH0j... [7]: https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/M9r1D4ch3ukJ https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/M9r1... [8]: https://groups.google.com/g/golang-nuts/c/qKB9h_pS1p8/m/1NlO-vg8V5cJ https://groups.google.com/g/golang-nuts/c/qKB9h_pS1p8/m/1NlO... [9]: https://github.com/golang/go/issues/13761#issuecomment-167721220 https://github.com/golang/go/issues/13761#issuecomment-16772... [10]: https://go.dev/talks/2011/Real_World_Go.pdf https://go.dev/talks/2011/Real_World_Go.pdf (Slide #25)
Merovius 3y ago
> its creators explicitly said their goal was to replace C++ I think that is a far clearer goal if you look at C++ as it is used inside Google. If you combine the Google C++ style guide and Abseil, you can see the heritage of Go very clearly.
bborud 3y ago
It may help to understand the context. At the time Go was created you could choose between three languages at Google: Python, C++ and Java. Well, to be honest, if you chose Python you were kind of looked down on as a bit of a loser() at Google, so there was really two languages: C++ and Java. Weeeell, to be honest, if you chose Java you would not be working on anything that was really performance critical so there was really just one language: C++. So we wrote lots and lots of servers in C++. Even those who strictly speaking didn't have to be very fast. That wasn't the nicest experience in the world. Not least because C++ is ancient and the linking stage would end up being a massive bottleneck during large builds. But also because C++ has a lot of sharp edges. And while the bro coders would never admit that they were wasting time looking over their shoulder, the grown ups started taking this seriously as a problem. A problem major enough to warrant having some really good people look into remedying that. So yes, at Google, Go did replace lots of C++ and did so successfully. () Yes, that sentiment was expressed. Sometimes by people whose names would be very familiar to you.
- sebastianz 3y ago
  > At the time Go was created you could choose between three languages at Google: Python, C++ and Java. Out of curiosity, what languages can you currently choose from at Google?
  - ncruces 3y ago
    Just you guess: Python, C++ and Java… and Go. Or JavaScript, Dart, Objective-C, Swift, Rust; even C#. But then it depends on the problem domain. Google it huge, so it depends. And that's even if you pick Python, C++, Java or Go. So your team will already have it decided for you.
  - bborud 3y ago
    I haven't worked there for a long time so I wouldn't know. I don't even know if they are still as disciplined about what languages are allowed and how those languages are used. Can someone still at Google chime in on this?
- bborud 3y ago
kaba0 3y ago
So, it’s Java 1.2, but worse. Cool contribution!
worik 3y ago
> ...finding enormous success as a statically typed (and an order of magnitude faster) alternative to Python. An alternative to Node.js/{Java|Type}Script catastrophe I have not written any go but I have been dragged into Node.js programming, and it is awful I do not believe in rewriting systems (except in exceptional circumstances that do not apply) so I'm stuck. But for someone else's choice...
- rreichman 3y ago
  Interesting that you say Node programming is a catastrophe, I think it’s fantastic.
  - worik 3y ago
    I have used Node a lot. And many other systems over the decades. Node is catastrophic because it perpetuates mistakes make fifty years ago where other modern systems (looking at Go and Rust) learnt from the past mistakes not to repeat them If Node were not popular it would not be catastrophic
    - matheusmoreira 3y ago
      Which mistakes?
yencabulator 3y ago
Here's a classic tale of Go replacing C++: https://go.dev/talks/2013/oscon-dl.slide#1 https://go.dev/talks/2013/oscon-dl.slide#1

threeseed 3y ago

> (and an order of magnitude faster) alternative to Python Python is increasingly an easy to use wrapper over low-level C/C++ code. So in many use cases it is faster than Go.

justinclift 3y ago
Than pure Go code, sure. But not really faster than Go code that's a wrapper over the same low-level C/C++ code.
- Merovius 3y ago
  That depends. C function call overhead for Go is quite large (it needs to allocate a larger stack, put it on its own thread and prevent pre-emption) and possibly larger than for CPython, which relies on calling into C for pretty much everything it does, so obviously has that path well-optimized. So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go.
  - gwd 3y ago
    > So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go. I don't have experience with Python, but I can definitely say switching between Go and C is super slow. I'm using a golang package which is a wrapper around SQLite: at some point I had a custom function written as a call-back to a Go function; profiling showed that a huge amount of time was spent in the transition code marshalling stuff back and forth between Go and C. I ended up writing the function in C so that the C sqlite3 library could call it directly, and it sped up my benchmarks significantly, maybe 5x. Even though sqlite3 is local, I still end up trying to minimize requests and data shipped out of the database, because transferring data in and out is so expensive. (And if you're curious, yes I have considered trying to use one of the "pure go" sqlite3 packages; in large part it's a question of trust: the core sqlite3 library is tested fantastically well; do I trust the reimplementations enough not to lose my data? The performance would have to be pretty compelling to make it worth the risk.) I think in general discouraging CGo makes sense, as in the vast majority of cases a re-implementation is better in the long run; so de-prioritizing CGo performance also makes sense. But there are exceptions, particularly for libraries where you want functionality to be identical, like sqlite3 or Qt, and there the CGo performance is a distinct downside.
- iainmerrick 3y ago
  Do you have an example of that? What I’ve heard over and over in comments here is that a) C interop in Go is slow, and b) Go devs discourage using it. (Java is a similar story in my experience.) In Python, (b) at least is definitely not true.
  - deleted 3y ago
    [deleted]

usrusr 3y ago

Go appears to be made with radical focus on a niche that isn't particularly well specified outside the heads of its benevolent directorate for life. Opinionated to the point of "if you use Go outside that unnamed niche you got no-one to blame but yourself". Could almost be called a solution looking for a problem. But it also appears to be quite successful at finding problem-fit, no doubt helped by the clarity of that focus. They've been very open about what they consider Go no to be or ever become. Unlike practically every other language, they all seem to eventually fall into the trap of advertising themselves with what boils down to "in a pinch you could also use it for everything else". It's quite plausible that before Go, its creators would have chosen C++ for problems they consider in "The Go Niche". That would be perfectly sufficient to declare it a C++ replacement in that niche. Just not a universal C++ replacement.

pjmlp 3y ago
Consider this, the authors have fixed some of the Plan 9 design errors including the demise of Alef, by creating Inferno and Limbo (yeah it was a response to Java OS, but still). Where C is only used for the Inferno kernel, Limbo VM (with a JIT) and little else like Tk bindings, everything else in Inferno is written in Limbo. Replace Limbo with AOT compiled Go, and that is what systems programming is in the minds of UNIX, Plan 9 and Inferno authors.

fishywang 3y ago

>its creators explicitly said their goal was to replace C++ so nowadays when we say "c++" we mostly mean the works should be replaced by rust, but back then, it's not like that. I would argue that go successfully replaced c++ in specific domains (network, etc.), and changed your perspective on what "c++" means.

zozbot234 3y ago
That's nothing new, Java successfully replaced C++ in enterprise code in the mid-to-late 1990s. Because it was safe from memory bugs.
- lanstin 3y ago
  Mid 2000s in my experience. And not because it was safe from memory bugs so much as safe from memory leaks. Still had plenty of NPEs.
  - justinclift 3y ago
    Java kind of gets around the memory leak problem by allocating all of the leak up front for the JVM. ;)
    - cryptos 3y ago
      I'm a JVM guy, but this is a good one :-)
  - pjmlp 3y ago
    NPE isn't a memory corruption bug.
  - kaba0 3y ago
    Those are safe. And it’s not like Go didn’t just copy nulls (plus even has shitty initialization problems now, e.g. with make!)
  - worik 3y ago

randomdata 3y ago

Except it did replace C++ in the domains it claimed it would replace C++ in. It made clear from day one that you wouldn't write something like a kernel in it. It was never trying to replace every last use of C++. You may have a point that Python would have replaced C++ in those places instead if Go had never materialized. It was clear C++ was already on the way out, with Python among those starting to push into its place around the time Go was conceived. Go found its success in the places where Python was also trying to replace C++.

bcrosby95 3y ago
What domains are those? It seems to mostly be an alternative to what people have use(d) Java or C# for.
- randomdata 3y ago
  The original Go announcement spells it all out pretty nicely.
deleted 3y ago
[deleted]
jeswin 3y ago
> You may have a point that Python would have replaced C++ in those places instead if Go had never materialized. I don't think Python was starting to occupy C++ space; they have entirely different abilities. Of course, I am also glad it didn't happen.
- randomdata 3y ago
  I don't think so either, but as we move past that side tangent and return to the discussion, there was the battle of the 'event systems'. Node.js was also created in this timeframe to compete on much the same ground. And then came Go, after which most contenders, including Python, backed down. If you are writing these kinds of programs today, it is highly likely that you are using Go, Node.js, or some language that is even newer than Go (e.g. Rust or Elixir). C++ isn't even on the consideration list anymore.

Thaxll 3y ago

And yet most popular tools written in Go used to be written in C++, Kubernetes, Databases and the like.

lmm 3y ago
Kubernetes mostly displaced tools written in Ruby (Puppet, Chef, Vagrant) or Python (Ansible, Fabric?). While a lot of older datastores are written in C++, new ones that were started post-2000ish tended to be written in Java or similar.
- Thaxll 3y ago
  Kuberentes has nothing to do with Ruby / Python from your example it's far more complex and needs performance, what you described are not what k8s is doing. Kubernetes is the equivalent of Borg /Omega at Google which is written in C++.
  - lmm 3y ago
    > Kuberentes has nothing to do with Ruby / Python from your example it's far more complex and needs performance, what you described are not what k8s is doing. It's what Kubernetes is being used for in most places where I've seen it used. > Kubernetes is the equivalent of Borg /Omega at Google which is written in C++. Maybe, but most Kubernetes users aren't Google and weren't using those things.

unscaled 3y ago

It's not at "an accident" and Go didn't "somehow" fail to replace C++ at its systems programming domain. The reason why go failed to replace C and C++ is not a mystery to anyone: Mandatory GC and a rather heavyweight runtime. When the performance overhead of having a GC is less significant than the cognitive overhead of dealing with manual memory management (or the Rust borrow checker), Go was quite successful: Command line tools and network programs. Around the time Go was released, it was certainly touted by its creators as a "systems programming language"[1] and a "replacement for C++"[2], but re-evaluating the Go team's claims, I think they didn't quite mean in the way most of us interpreted them. 1. The Go Team members were using "systems programming language" in a very wide sense, that include everything that is not scripting or web. I hate this defintion with passion, since it relies on nothing but pure elitism ("Systems language are languages that REAL programmers uses, unlike those "Scripting Languages"). Ironically, this usage seems to originate from John Ousterhout[3], who is himself famous for designing a scripting language (Tcl). Ousterhout's definition of "system programming language" is: Designed to write applications from scratch (not just "glue code"), performant, strongly typed, designed for building data structures and algorithms from scratch, often provide higher-level facilities such as objects and threads. Ousterhout's definition was outdated even back in 2009, when Go was released, let alone today. Some dynamic languages (such as Python with type hints or TypeScript) are more strongly typed than C or even Java (with its type erasure). Typing is optional, but so it is in Java (Object), and C (void*, casting). When we talk about the archetypical "strongly typed" language today we would refer to Haskell or Scala rather than C. Scripting languages like Python and JavaScript were already commonly used "for writing applications from scratch" back in 2009, and far from being ill-adapted for writing data structures and algorithms from scratch, Python became the most common language that universities are using for teaching data structures and algorithms! The most popular dynamic languages nowadays (Ruby, Python, JavaScript) all have objects, and 2 out of 3 (Python and Ruby) have threads (although GIL makes using threads problematic in the mainstream runtimes). The only real differentiator that remains is raw performance. The widely accepted definition of a "systems language" today is "a language that can be used to systems software". Systems software are either operating systems or OS-adjacent software such as device drivers, debuggers, hypervisors or even complex beasts like a web browser. The closest software that Go can claim in this category is Docker, but Docker itself is just a complex wrapper around Linux kernel features such as namespaces and cgroups. The actual containerization is done by these features which are implemented in C. During the first years of Go, the Go language team was confronted on golang-nuts by people who wanted to use go for writing systems software and they usually evaded directly answering these questions. When pressed, they would admit that Go is not ready for writing OS kernels, at least not now[4][5][6], but GC could be disabled if you want to[7] (of course, there isn't any way to free memory then, so it's kinda moot). Eventually, the team came to a conclusion that disabling GC is not meant for production use[8][9], but that was not apparent in the early days. Eventually the references for "systems language" disappeared from Go's official homepage and one team member (Andrew Gerrand) even admitted this branding was a mistake[10]. In hindsight, I think the main "systems programming task" that Rob Pike and other members at the Go team envisioned was the main task that Google needed: writing highly concurrent server code. 2. The Go Team members sometimes mentioned replacing C and C++, but only in the context of specific pain points that made "programming in the large" cumbersome with C++: build speed, dependency management and different programmers using different subsets. I couldn't find any claim that go was meant as a general replacement for C and C++ anywhere from the Go Team, but the media and the wider programming community generally took Go as a replacement language for C and C++. When you read through the lines, it becomes clear that the C++ replacement angle is more about Google than it is about Go. It seems that in 2009, Google was using C++ as the primary language for writing web servers. For the rest of the industry, Java was (and perhaps still is) the most popular language for this task, with some companies opting for dynamic languages like Python, PHP and Ruby where performance allowed. Go was a great fit for high-concurrency servers, especially back in 2009. Dynamic languages were slower and lacked native support for concurrency (if you put aside Lua, which never got popular for server programming for other reasons). Some of these languages had threads, but these were unworkable due to GIL. The closest thing was frameworks Twisted, but they were fully asynchronous and quite hard to use. Popular static languages like Java and C# were also inconvenient, but in a different way. Both of these languages were fully capable of writing high-performance servers, but they were not properly tuned for this use case by default. The common frameworks of the day (Spring, Java EE and ASP.net) introduced copious amounts of overhead, and the GC was optimized for high throughput, but it had very bad tail latency (GC pauses) and generally required large heap sizes to be efficient. Dependency management, build and deployment was also an afterthought. Java had Maven and Ivy and .Net had NuGet (in 2010) and MSBuild, but these where quite cumbersome to use. Deployment was quite messy, with different packaging methods (multiple JAR files with classpath, WAR files, EAR files) and making sure the runtime on the server is compatible with your application. Most enthusiasts and many startups just gave up on Java entirely. The mass migration of dynamic language programmers to Go was surprising for the Go team, but in hindsight it's pretty obvious. They were concerned about performance, but didn't feel like they had a choice: Java was just too complex and Enterprisey for them, and eeking out performance out of Java was not an task easy either. Go, on the other hand, had the simplest deployment model (a single binary), no need for fine tuning and it had a lot of built-in tooling from day one ("gofmt", "godoc", "gotest", cross compilation) and other important tools ("govet", "goprof" and "goinstall" which was later broken into "go get" and "go install") were added within one year of its initial release. The Go team did expect server programs to be the main use for Go and this is what they were targeting at Google. They just missed that the bulk of new servers outside of Google were being written in dynamic languages or Java. The other "surprising use" of Go was for writing command-line utilities. I'm not sure if the original Go team were thinking about that, but it is also quite obvious in hindsight. Go was just so much easier to distribute than any alternative available at the time. Scripting languages like Python, Ruby or Perl had great libraries for writing CLI programs, but distributing your program along with its dependencies and making sure the runtime and dependencies match what you needed was practically impossible without essentially packaging your app for every single OS and distro out there or relying on the user to be a to install the correct version of Python or Ruby and then use gem or pip to install your package. Java and .NET had slow start times due to their VM, so they were horrible candidates even if you'd solve the dependency issues. So the best solution was usually C or C++ with either the "./configure && ./make install" pattern or making a static binary - both solutions were quite horrible. Go was a winner again: it produced fully static binaries by default and had easy-to-use cross compilation out of the box. Even creating a native package for Linux distros was a lot easier, so all you add to do is package a static binary. [1]: https://opensource.googleblog.com/2009/11/hey-ho-lets-go.html https://opensource.googleblog.com/2009/11/hey-ho-lets-go.htm... [2]: https://web.archive.org/web/20091114043422/http://www.golang.org/ https://web.archive.org/web/20091114043422/http://www.golang... [3]: https://users.ece.utexas.edu/~adnan/top/ousterhout-scripting.pdf https://users.ece.utexas.edu/~adnan/top/ousterhout-scripting... [4]: https://groups.google.com/g/golang-nuts/c/6vvOzYyDkWQ/m/3T1DD47AHKcJ https://groups.google.com/g/golang-nuts/c/6vvOzYyDkWQ/m/3T1D... [5]: https://groups.google.com/g/golang-nuts/c/BO1vBge4L-o/m/lU1_LQp_tpIJ https://groups.google.com/g/golang-nuts/c/BO1vBge4L-o/m/lU1_... [6]: https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/NH0jskB_xF0J https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/NH0j... [7]: https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/M9r1D4ch3ukJ https://groups.google.com/g/golang-nuts/c/UgbTmOXZ_yw/m/M9r1... [8]: https://groups.google.com/g/golang-nuts/c/qKB9h_pS1p8/m/1NlO-vg8V5cJ https://groups.google.com/g/golang-nuts/c/qKB9h_pS1p8/m/1NlO... [9]: https://github.com/golang/go/issues/13761#issuecomment-167721220 https://github.com/golang/go/issues/13761#issuecomment-16772... [10]: https://go.dev/talks/2011/Real_World_Go.pdf https://go.dev/talks/2011/Real_World_Go.pdf (Slide #25)

Merovius 3y ago

> its creators explicitly said their goal was to replace C++ I think that is a far clearer goal if you look at C++ as it is used inside Google. If you combine the Google C++ style guide and Abseil, you can see the heritage of Go very clearly.

bborud 3y ago

It may help to understand the context. At the time Go was created you could choose between three languages at Google: Python, C++ and Java. Well, to be honest, if you chose Python you were kind of looked down on as a bit of a loser() at Google, so there was really two languages: C++ and Java. Weeeell, to be honest, if you chose Java you would not be working on anything that was really performance critical so there was really just one language: C++. So we wrote lots and lots of servers in C++. Even those who strictly speaking didn't have to be very fast. That wasn't the nicest experience in the world. Not least because C++ is ancient and the linking stage would end up being a massive bottleneck during large builds. But also because C++ has a lot of sharp edges. And while the bro coders would never admit that they were wasting time looking over their shoulder, the grown ups started taking this seriously as a problem. A problem major enough to warrant having some really good people look into remedying that. So yes, at Google, Go did replace lots of C++ and did so successfully. () Yes, that sentiment was expressed. Sometimes by people whose names would be very familiar to you.

sebastianz 3y ago
> At the time Go was created you could choose between three languages at Google: Python, C++ and Java. Out of curiosity, what languages can you currently choose from at Google?
- ncruces 3y ago
  Just you guess: Python, C++ and Java… and Go. Or JavaScript, Dart, Objective-C, Swift, Rust; even C#. But then it depends on the problem domain. Google it huge, so it depends. And that's even if you pick Python, C++, Java or Go. So your team will already have it decided for you.
- bborud 3y ago
  I haven't worked there for a long time so I wouldn't know. I don't even know if they are still as disciplined about what languages are allowed and how those languages are used. Can someone still at Google chime in on this?
bborud 3y ago

kaba0 3y ago

So, it’s Java 1.2, but worse. Cool contribution!

worik 3y ago

> ...finding enormous success as a statically typed (and an order of magnitude faster) alternative to Python. An alternative to Node.js/{Java|Type}Script catastrophe I have not written any go but I have been dragged into Node.js programming, and it is awful I do not believe in rewriting systems (except in exceptional circumstances that do not apply) so I'm stuck. But for someone else's choice...

rreichman 3y ago
Interesting that you say Node programming is a catastrophe, I think it’s fantastic.
- worik 3y ago
  I have used Node a lot. And many other systems over the decades. Node is catastrophic because it perpetuates mistakes make fifty years ago where other modern systems (looking at Go and Rust) learnt from the past mistakes not to repeat them If Node were not popular it would not be catastrophic
  - matheusmoreira 3y ago
    Which mistakes?

yencabulator 3y ago

Here's a classic tale of Go replacing C++: https://go.dev/talks/2013/oscon-dl.slide#1 https://go.dev/talks/2013/oscon-dl.slide#1