Lang NEXT 2014 Panel Systems Programming in 2014 and Beyond

Android already has C/C++(NDK, bionic) and Java. Google is stuck with JVM based languages for Android apps because the ecosystem depends on it. There are millions of apps that are written in Java. So that is not going to go anywhere. So the best alternative they could find for Java was Kotlin. Now comes the question of C/C++, for that Go is not an alternative but Rust is. C, C++ and Rust are systems programming languages, Go is not. For performance critical path systems programming languages are used. Watch the start of this[0] discussion and you will soon realise how out of place Rob Pike felt, with regards to Go, when the topic of systems programming languages came up. In early days Go was touted as "systems programming language" with later clarification that what they really meant was "suitable for server-side programming". So Go is not a replacement for C and C++ as a systems programming language. [0] [VIDEO]

Wow. Thanks for both of your replies. The last paragraph of your reply above reminds me somewhat of a part of this talk, somewhere near the end: Lang NEXT 2014 Panel Systems Programming in 2014 and Beyond [VIDEO] It is the part where Bjarne Stroustrup talks about the issue of the huge compilation times of multi-file C++ projects, due to the number of times that header files are repeatedly included, IIRC. The section is a bit funny, with the responses from the other participants. There may be a solution for by now (modules), but I am not a C++ guy, so don't know if it exists or is good enough. Interested to know what others think of this.

> 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 typecastin