
Rust 2017 Survey Results - steveklabnik
https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html
======
JoshTriplett
> Among editors, vim remains king, though we see healthy growth in VSCode
> adoption at 34.1% (up from last year’s 3.8%). This growth no doubt has been
> helped by VSCode being one of the first platforms to get support for the
> Rust Language Server.

This suggests that it would help to have better getting-started guides for
vim, and for using it with RLS in particular.

> 10% responded that tools aren’t use mature enough.

I've seen more than one person mention that the fact that RLS doesn't work on
stable Rust is a sign of immaturity.

Also, in the context of people who had stopped using Rust:

> The rest of users mentioned [...] were turned away by Rust’s syntax, [...]
> or had a bad interaction with the Rust community.

Is anyone systematically looking over each of the responses that said either
of these, in detail, in order to address them as well as possible?

~~~
vbezhenar
What I personally did not like is: I'm very minimal vim user, I don't use
plugins or plugin managers, I just setup some basic options like syntax
highlighting and auto indentation. All I wanted from Rust plugin is to enable
syntax highlighting and some reasonable indentation. But it turns out that I
must install some kind of plugin manager just for rust plugin and I would
receive lots of bells and whistles that I'm not interested, at least while I'm
learning.

Actually I think it's the same problem with golang. Last time I used it, I had
to browse VCS history of go project, they shipped vim plugin long time ago but
then deleted it, I had to recover it from there and install it into ~/.vim/.

~~~
steveklabnik
You don't have to use a plugin manager, that's just how many people use
plugins.

Furthermore, earlier in the year I upstreamed rust.vim
[https://github.com/vim/vim/pull/1356/](https://github.com/vim/vim/pull/1356/)
So if you're using a new enough vim, you shouldn't even need the plugin.

~~~
JoshTriplett
And thank you for that, because it works out of the box for me.

------
y7
I wonder if the results for "I don't use Rust because..." would change if the
answer "It would slow development down too much", or something along the same
lines, would be there. At least that's my personal reason. I like Rust and
I've played around with it, but it's just not the right tool for the job if
you need Python-style rapid development.

~~~
Can_Not
Could they make something like nim for rust?

~~~
dom96
Managing memory manually doesn't sound like it would promote rapid
development. So you may as well just use Nim :)

~~~
steveklabnik
You don't really "manage memory manually" in Rust either, generally.

------
squiguy7
When they ask if an update to a stable compiler has broken their code, what
does this mean exactly? I had thought that a goal of Rust was to always
maintain backwards compatibility?

I know how hard this is to pull off and I am not trying to say they have done
a poor job; I genuinely want to know what others consider a breaking change.

~~~
steveklabnik
In a language that's as strongly typed as Rust, any change can be breaking. So
for example, let's say that you had code that looks like this:

    
    
        use std::cell::*;
    
        struct MoveCell;
    

We then add a new type to std::cell, also named MoveCell. Your code will now
fail to compile, as the two structures conflict.

This kind of breakage can still happen, even though we care a lot about
stability.

~~~
squiguy7
Ah that makes sense. I suppose you can't predict naming in everyone's source
for their projects. Thanks for the answer!

~~~
steveklabnik
No worries. There is also other things as well, that's just one of the easiest
ones to explain. For example, in 1.20 last week, we fixed a bug with include!
in documentation tests behaving strangely; that's technically a change in
behavior, and therefore, a breaking change. Two crates were the only users,
apparently, and so they just wrote a patch and fixed it. Still technically
breakage.

The guiding principle is "it should not be painful to update the compiler",
and I think we do as good a job as we can making sure that that's true.

~~~
nickm12
It would be helpful in these guidelines to make a clear distinction between
changes that result in "code not compiling" versus "code behaving
differently".

It seems like the vast majority of cases you've enumerated are in the category
of "code won't compile". Perhaps some have a knee-jerk reaction against this,
but to me this is kind of incompatibility seems much more preferable to the
other, especially if the update required to the code is trivial and obvious.

------
ewillbefull
The next survey should ask which nightly-only features are keeping them on
nightly. :)

~~~
Manishearth
From asking around (totally unscientific, but I've been asking this question
for a while now), it seems like most folks develop for stable but use nightly
for incremental compilation, RLS, and/or clippy. The first two are on the path
to stable in the next few releases, and the last one is starting to go in that
direction too, but will take longer.

~~~
ekidd
Yes, this is exactly how we do it: Our build systems all run stable, but
developers use nightly for RLS and clippy.

We did have one developer who was excited about using Rocket (which he said
was much better than the other Rust web frameworks he had tried), but we
decided that the grief of building production code on unstable wasn't worth
it.

(We're also holding off on directly using futures in any major way until the
developer ergonomics and especially error messages get better.)

------
danjoc
Only 75% of respondents feel welcome in the community. That seems bad,
considering those who felt unwelcome probably left already and didn't
participate in the survey. I would have expected closer to 100%.

~~~
beefsack
23.6% of the rest of the respondents chose "not sure", I wonder what amount of
these people just didn't interact with the community at all and chose that
response.

Only 1.3% specifically responded with not feeling welcome, which seems quite
low to me.

------
rsynnott
Nice to see only 7.5% have had stuff broken by an upgrade. Last time I messed
around with it, it was still changing rapidly, which is part of what put me
off. May give it another go.

~~~
steveklabnik
Was that before or after 1.0? We do time-based releases, every six weeks. New
stuff is still being worked on all the time, like most languages.

~~~
rsynnott
Before 1.0 :)

Just installed 1.20 now, giving it another try. IntelliJ support helps.

~~~
steveklabnik
Ah yeah, that makes perfect sense. :)

IntelliJ's plugin just became officially supported by the company, so let's
hope it gets even better from here!

------
divs1210
Well, rust+emacs is pretty easy to setup and provides syntax-highlighting,
indentation, documentation, jump-to-definition, etc. out of the box.

