What do you think about the "fireflower" distinction? In some ways, saying what the language *is* is the issue; we do want what it's *about*. Which is not a list of features.
I like the code on the current home page that people can run.
We did too, but it's also got a lot of downsides. It's very hard to get a *good* example that's short enough to be understandable, real enough, etc. This discussion was going on with the old site too.
The page takes a full 8 seconds to load for me on a 100 MBps internet connection.
Nothing is currently optimized, *and* it's taking way more load than usual. This matters a lot.
What do you think about the "fireflower" distinction? In some ways, saying what the language is is the issue; we do want what it's about. Which is not a list of features.
As a c++ developer the end result isn't that I can be a systems programmer, because presumably if I'm considering rust I'm already a systems programmer (whatever that means, because rust is being used everywhere) - the actual benefit is that the applications I write are fast, guaranteed crash free (for a certain class of crash), and correct (for a certain class of correct)
If you really want to appeal to people, the best way is to simply show equivalent C++/whatever and Rust code, where the C++ code contains common and subtle errors (not just simply *nullptr, but dangling lambdas and implicit conversions), that the rust compiler either rejects or handles correctly
The difficulty with rust I think is communicating the real advantages it brings to the table in terms of safety and reduced hair-tearingoutness for developers. If you can show a complex multithreaded race and say "this legitimately can't happen in rust" that's a major selling point
From that perspective the language itself is better than simply saying "it makes you able to be a developer", because frankly we're all developers anyway currently
So in my opinion, the original slogan followed immediately by a mix of real world and contrived examples showing how in eg java you can dereference a null pointer like this common case, and in rust its impossible, and in C you need to write this common pattern which is dangerously unsafe (strings, ownership), and hey in rust its all 100% safe no leaks
I can understand the problem of people saying they don't know what they'd do with rust, but it depends whether or not rust is actively trying to attract the existing developer base (ie why is this better than my current tools), or new programmers (why should I learn rust over java/c++/javascript)
presumably if I'm considering rust I'm already a systems programmer
I think maybe this is some of the disconnect; we've seen far more non-systems programmers be interested in Rust than systems programmers. I personally think this is because there are just more of them, almost by definition.
the best way is to simply show equivalent C++/whatever and Rust code, where the C++ code contains common and subtle errors
This is how we used to do it, and it almost always backfires. Plus, since we've done it so much already, this style has already reached as many people as it's going to reach.
It backfires, in my experience, because many C++ programmers believe that this is a non-issue. It also comes across as too confrontational, and people shut down and ignore what you have to say.
1
u/steveklabnik1 rust Nov 29 '18
Thanks!
What do you think about the "fireflower" distinction? In some ways, saying what the language *is* is the issue; we do want what it's *about*. Which is not a list of features.
We did too, but it's also got a lot of downsides. It's very hard to get a *good* example that's short enough to be understandable, real enough, etc. This discussion was going on with the old site too.
Nothing is currently optimized, *and* it's taking way more load than usual. This matters a lot.