Are comparisons what we want?

[steveklabnik]

I'm pretty sure the answer is "yes", but I wanted to raise it in an issue, because this is a significant departure of policy. There's been a psudo-unspoken rule in marketing Rust for years:

don't compare to other languages, but instead, sell on our own merits.

There's a lot of good reasons for this, but it can hamper things as well.

How are we going to do this properly?

[joshtriplett]

I definitely think we want to do this carefully. We don't want to run down other languages, and we don't want to define our features by how they're like other languages.

I wonder if it might make sense to combine the "comparison" bits with the "for Foo developers" bits. Do we really need a separate pitch for "how does Rust compare to Go" and "Rust for Go developers", when they'll have very similar target audiences and information? The former seems like what we've tried to avoid, but I don't see anything wrong with the latter.

[aturon]

So, to be clear, the idea here is that the "pitches" are how we sell directly, and things like "rebuttals" and "comparisons" are more reactive talking points. That is, if someone asks "How does Rust compare to Go?", we want to have an authoritative answer.

[joshtriplett]

On July 25, 2018 12:40:55 PM PDT, Aaron Turon notifications@github.com wrote:

So, to be clear, the idea here is that the "pitches" are how we sell directly, and things like "rebuttals" and "comparisons" are more reactive talking points. That is, if someone asks "How does Rust compare to Go?", we want to have an authoritative answer.

That makes sense, but might it work to combine "how does Rust compare to X" with "how do we pitch Rust to X developers"?

[Mark-Simulacrum]

Loosely it feels like perhaps the compare to X pages might primarily be ~single page that essentially says something along the lines of Rust being a unique language and having both strengths and weaknesses, then pointing people at the pitch for X developers with a note that you can learn more about the differences and advantages of Rust there. Maybe this can be the same page, even.

[graydon]

I concur that not attacking or even making a big deal of competing with other languages has always been a (spoken!) guideline in discussing Rust; but I did mention C++, JVM/CLR languages and Go in the very first slide deck on the topic (the former motivating the project, the latter being something everyone asks about). I think it's fair to at least have an answer. Just keep it technical: explain where there are overarching differences and the costs and benefits of them (i.e. be even more generous to them than I was back then).

Dissatisfaction with pervasive unsafety in C++ was a motive, and we did consider whether it'd be best to just stop and give up when Go came out (and decided against it -- it's trivial to write a data race, no concept of immutability at all, etc.) I think you'll probably also want to have a comparison with a couple JVM and CLR languages, with Swift, with one or more interpreted scripting languages (legit lots of people do not know the differences).

[Moxinilian]

Comparing Rust to other languages is a very tricky matter. I've noticed that language choices seem to be a tense subject to discuss (especially online!), and so comparing Rust to specific languages might raise the guards of somebody we could have convinced had we not attacked their familiar concepts.

I think illustrating advantages should be done against examples, actual use cases, instead of the flaws of other languages. That way, the message we want to convey would sound nicer, less intrusive. Having documentation on how Rust compares to other languages is useful, of course, especially when somebody actively asks. But it should be explicitly noticed that this has to only be used when actually asked, because otherwise Rust will never get rid of its evangelistic reputation.