3 ms·

> The only reason they are compared is because Google co-opted the term "systems" to mean something different than everyone else. Really? You know, for a fact,

> The only reason they are compared is because Google co-opted the term "systems" to mean something different than everyone else. Really? You know, for a fact, that that is the only reason the two languages are compared? There couldn't be any other possible reason? How many years has it been since the official literature made such an egregious and offensive mistake as to misuse the term "systems"? The only reason it's even an issue is because people insist on bringing it up as the root cause for [insert social phenomenon here]. Because clearly, anyone who compares these languages must be so enamored by the original description of Go as a "systems" language that there couldn't possibly be any other explanation. (But maybe this fits in just right with your view of the Go community as "anti-intellectual.") Maybe people compare the languages because many people find them comparable. There's no mystery there.

matthewmacleod 11y ago
There's no mystery there. Contrary to the previous poster, I suspect people simply compare the languages because they appeared around the same time and are both backed by big players. There's nothing really comparable between them (although the that's just my opinion) and I'm baffled as to why they are co pared so often.
- burntsushi 11y ago
  Any two languages can be compared. The notion that the act of comparing two languages can be traced to one particular root cause (such as the use of the word "systems" N years ago) is ludicrous to me. What matters is the analysis that is involved in that comparison. For example, I'd find the answer to this question very interesting: "Compare and contrast concurrency in Rust and Go." I contend that the answer to this question is epic. It will take you back through the history of PL and lots of really interesting design decisions. At the forefront: should concurrency be a first class part of the language? Or should it be part of a library? And that's just one interesting question. There are plenty more.
MichaelGG 11y ago
Right from the article: > When I initially wrote down my reactions to Go, I didn’t know about another new systems language: Rust. But maybe I'm misreading (honestly). Still they end up getting compared an awfully lot, more than they're compared to closer languages. At any rate, yeah, I find it very weird that the languages are compared. There seems to be very little overlap in when you'd want to use them. If you aren't bound by C-linkage or zero-runtime/overhead requirements, then there are higher level, more flexible languages to use than Rust. If you do have those requirements, Go simply isn't an option. (This is a bit simplistic but is generally correct.) Edit: I see you're taking an overly literal interpretation of "only". You're right. Anyone can compare anything for any reason. I think the intent of my comment is clear enough.
- burntsushi 11y ago
  Your reasoning is not just a bit simplistic, it's overly reductive. Just because I'm not bound by C-linkage or zero-runtime/overheard requirements doesn't mean Rust isn't a good choice. Similarly, even if I do need to link to a C library, that doesn't mean Go is a bad choice. > There seems to be very little overlap in when you'd want to use them. If all you're going to do is consider each respective language's wheelhouses, then I might agree that there is little overlap (at least, currently). But in my experience, there are often plenty of other reasons in play that influence language choice. I once chose a language (not Rust/Go) purely because of how popular/accessible it was. There was no technical merit there, but because of that choice, the project has gotten very popular and used by a lot of people. At work, a few months ago, we had an internal debate over whether to use Rust or Go for a new project. There's plenty of overlap. Not every problem has a workable solution governed by uncompromisable requirements that uniquely identify a language, so one invariably winds up adopting other criteria for choosing a language. These criteria may not be uniquely technical; they may be social or even emotional. I contend that nothing I've said here is controversial. My goal is to encourage others to broaden their horizons; we don't need to put our blinders on and snub our noses at people that do things differently. (Which is absolutely how I perceived your comments in this thread.)
  - MichaelGG 11y ago

matthewmacleod 11y ago

There's no mystery there. Contrary to the previous poster, I suspect people simply compare the languages because they appeared around the same time and are both backed by big players. There's nothing really comparable between them (although the that's just my opinion) and I'm baffled as to why they are co pared so often.

burntsushi 11y ago
Any two languages can be compared. The notion that the act of comparing two languages can be traced to one particular root cause (such as the use of the word "systems" N years ago) is ludicrous to me. What matters is the analysis that is involved in that comparison. For example, I'd find the answer to this question very interesting: "Compare and contrast concurrency in Rust and Go." I contend that the answer to this question is epic. It will take you back through the history of PL and lots of really interesting design decisions. At the forefront: should concurrency be a first class part of the language? Or should it be part of a library? And that's just one interesting question. There are plenty more.

MichaelGG 11y ago

Right from the article: > When I initially wrote down my reactions to Go, I didn’t know about another new systems language: Rust. But maybe I'm misreading (honestly). Still they end up getting compared an awfully lot, more than they're compared to closer languages. At any rate, yeah, I find it very weird that the languages are compared. There seems to be very little overlap in when you'd want to use them. If you aren't bound by C-linkage or zero-runtime/overhead requirements, then there are higher level, more flexible languages to use than Rust. If you do have those requirements, Go simply isn't an option. (This is a bit simplistic but is generally correct.) Edit: I see you're taking an overly literal interpretation of "only". You're right. Anyone can compare anything for any reason. I think the intent of my comment is clear enough.

burntsushi 11y ago
Your reasoning is not just a bit simplistic, it's overly reductive. Just because I'm not bound by C-linkage or zero-runtime/overheard requirements doesn't mean Rust isn't a good choice. Similarly, even if I do need to link to a C library, that doesn't mean Go is a bad choice. > There seems to be very little overlap in when you'd want to use them. If all you're going to do is consider each respective language's wheelhouses, then I might agree that there is little overlap (at least, currently). But in my experience, there are often plenty of other reasons in play that influence language choice. I once chose a language (not Rust/Go) purely because of how popular/accessible it was. There was no technical merit there, but because of that choice, the project has gotten very popular and used by a lot of people. At work, a few months ago, we had an internal debate over whether to use Rust or Go for a new project. There's plenty of overlap. Not every problem has a workable solution governed by uncompromisable requirements that uniquely identify a language, so one invariably winds up adopting other criteria for choosing a language. These criteria may not be uniquely technical; they may be social or even emotional. I contend that nothing I've said here is controversial. My goal is to encourage others to broaden their horizons; we don't need to put our blinders on and snub our noses at people that do things differently. (Which is absolutely how I perceived your comments in this thread.)
- MichaelGG 11y ago