[kbenson]

> Hell, even the definition of "System programming language" on Wikipedia[1] is ambiguous enough that many GC'd or even scripting languages would fit it.

And the definition of race car is ambiguous enough that you can take your 70's pinto onto the track if you want. In some contexts that might even be entirely acceptable. But if you look at the current uses of the term and what it applies to, and why, it becomes fairly obvious what class of vehicles it's referring to. There are, of course, more specific terms (Indy, Nascar, Formula 1, Rally) for more specific meaning. If someone says they are building a race car, you have a pretty good idea that they are building a vehicle to compete in a race, and speed and handling are important, but specific details might change depending on the type of racing.

> Newcomers faceplanting into the 10-story granite wall that is the borrow checker is bad enough, there's no reason they should be confused by the tagline on the homepage.

Then again, should newcomers come under the impression it's as easy as Python or JavaScript and when they hit that brick wall think it's just themselves, or that the language is poorly designed because it isn't as accessible? Systems language is probably the closest thing I can think of that approximates what to expect out of languages in this category. More explanation might be nice, but I think systems language signals the right things for people that know the term, or are willing to look it up.

[lmm]

> If someone says they are building a race car, you have a pretty good idea that they are building a vehicle to compete in a race, and speed and handling are important, but specific details might change depending on the type of racing.

Right, but there's nothing like that for a "system programming language". What does that tell me? I might assume it meant manual memory management or a language suitable for writing a kernel, but the Go people call that a "system programming language" even though neither of those things applies.

[kbenson]

Embedded programming, kernel programming, high-performance computing. I view all of these as variations on systems programming.

> What does that tell me? I might assume it meant manual memory management or a language suitable for writing a kernel, but the Go people call that a "system programming language" even though neither of those things applies.

I'm not sure picking one relatively odd member of a category and concluding that since it doesn't match in some aspects that the category doesn't exist is useful. To stay with the theme, you might encounter 24 Hours of LeMons[1] at some point, and I don't think that makes the idea of race cars invalid or useless (there's a reason I said a 70's Pinto might be acceptable).

You can do some systems programming with garbage collected languages, or even dynamic languages in a pinch. It's not ideal in the vast majority of cases, but there are certain situations where it's not entirely unacceptable either (running the webserver in the same language as your dynamic site is implemented in is one).

1: http://www.cnbc.com/2016/06/19/how-an-amateur-launched-a-mil...

[lmm]

> I'm not sure picking one relatively odd member of a category and concluding that since it doesn't match in some aspects that the category doesn't exist is useful. To stay with the theme, you might encounter 24 Hours of LeMons[1] at some point, and I don't think that makes the idea of race cars invalid or useless (there's a reason I said a 70's Pinto might be acceptable).

Is Go an odd example then? What's a typical example? Better, out of the 10 or 20 most popular programming languages, which are "systems languages" and which are not? I genuinely don't know how to tell, other than maybe "no GC". As far as I can tell the term mainly just means "language I like".

[kbenson]

In the current context of contemporary languages I would consider system languages, having GC definitely defines one as abnormal, and Go is abnormal for a systems language. It was apparently much less uncommon to have GC system languages in the past (but I suspect those languages were well adapted to having fine grain memory control coupled with GC). Go is an interesting mix of low-level and close-to-the-metal with a few aspects which are not low-level (channels and GC).

[vertex-four]

I've always argued that Go is wrong for calling itself a systems programming language. Unfortunately, entities with enough clout can single-handedly redefine language that has specific meaning to a minority of people, but where most people have no need for that language.

[infogulch]

I wouldn't disagree with this. But the golang.org website doesn't mention "system" on the homepage, or documents page. You have to go all the way to reading the spec to see the first (and only) mention of Go describing itself as:

> a general-purpose language designed with systems programming in mind

And I'm not sure this definition is actually unrepresentative.

Contrast this with rust-lang.org where "system" is the fourth word on the homepage. People like to blame Go for people being confused about what "systems language" means, but it seems to me like this is just poor branding on Rust's part.

[dbaupp]

Go rolled back a lot of their use of the systems programming label, E.g. the first version of the website http://web.archive.org/web/20091111073232/Http://golang.org has it in the heading.

[infogulch]

Sure, but before even the release of Go 1.0 [1] (which also doesn't mention "system") it's gone. Surely you wouldn't attribute the entire confusion around what a systems language is to a version of a pre-release language's website that made that statement for less than a year [2], almost seven years ago.

I don't want to think about the mental gymnastics it would take to come to that conclusion.

[1]: https://blog.golang.org/go-version-1-is-released

[2]: http://web.archive.org/web/20101001012723/http://golang.org/

[vertex-four]

When Go was announced, the creators made a huge deal around it being a "systems programming language", which many of its users - who have never had a reason to need a systems programming language, and so have no idea what one is - have parroted ever since. Just because they no longer have it on (most of) their site doesn't mean it didn't become a buzzword within the language's community.

[infogulch]

I would say that the term "race car" is recognized by the entire population, plus it's self-descriptive if you know the meaning of both of the component words, which are also very well known and easily defined.

It's self-evident that this is not the case for "systems language", else we wouldn't be talking about this. By itself, "system" means almost nothing and it doesn't help one understand the phrase "systems language" at all without prior knowledge. Take a moment to dwell on the mental context of someone that would say this and what it means to them:

You can write a system in any language right?

> should newcomers come under the impression it's .. easy

Newcomers that don't understand the term at first glance come with no impression because it's ambiguous.

> More explanation might be nice

If you have to reference a footnote to describe the word every time you use it, the word has lost its' value as as word. You might as well call it a "peloozoid programming language" [1]. Just use a better word. Or find a qualifier to tack in front of it to make it more clear. And before you dispute the phrase "every time you use it" I would like to take a second to reference nearly every Rust post on HN and the forums where people are confused by the term "systems"; this theme might be more common than the (tiring) rust-vs-go theme.

This whole paragraph almost comes across as intentionally exclusionary. The Rust community is making huge efforts to make Rust more approachable and ergonomic, especially to non-systems programmers†. This effort can extend past the language itself into the way it describes itself.

I'm not delusional, there's no chance that the 4th word on rust-lang.org will change because I made a comment on HN. But I can wish.

† This is one of the great strengths of Rust! You don't need years of experience with manual memory management to not footgun yourself, Rust has your back. With it's FFI and safety story it's in a great position for dynamic language devs to write extensions for their language with minimal experience and investment.

[1]: http://www.wordgenerator.net/fake-word-generator.php

[kbenson]

> Take a moment to dwell on the mental context of someone that would say this and what it means to them: You can write a system in any language right?

I understand the point, but not every concept is easily explainable or should be known to everyone as common knowledge. That's wasteful. If someone is confused about a term or how it applies, or if it seems like it's being used in a different context, then they can look it or up ask, like they did here. If I had seen a suggestion that better encapsulated Rust, I would be on board with you in saying it should change, but I haven't seen that yet.

> If you have to reference a footnote to describe the word every time you use it

You don't, unless you are exclusively talking to to people about it that have no industry knowledge or training, and then I think the term is probably either not something they care about or something they should learn about. We don't ask Doctors to change their industry jargon for non doctors, and doctors that don't know it are expected to learn it. Communication is a two way street.

There's a middle ground between making up new words and dumbing down all communication to the simplest words in the language. Neither is particularly useful in the long term. I don't know if Rust has hit a good middle ground, but I do't have a better solution than what I see them doing, and I don't see what I consider better solutions being presented.

[steveklabnik]

You're not wrong; we've always been unsure if "systems" is a good way to describe Rust. It has a lot of advantages, but also a lot of downsides, many of which you discuss here.