
State of Rust Survey 2016 - steveklabnik
http://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html
======
kej
I'm disappointed that "No" and "I stopped using Rust" were merged into one
answer for the "Do you use Rust?" question. Knowing the reasons people have
never used Rust compared to the reasons people have used Rust but moved away
would have been a really interesting result.

~~~
Animats
That's a good point. Since this is apparently a self-selected sample of people
interested in Rust, a 1/3 "No" report is a problem.

If the survey was from a random sample of all programmers, the usage level
would be much lower.

~~~
pcwalton
> Since this is apparently a self-selected sample of people interested in
> Rust, a 1/3 "No" report is a problem.

How do you know what usage level is a "problem" without any point of
comparison?

I'm interested in JavaScript, for example, but I don't use it more often than
a handful of times per year, if that. I wouldn't be surprised if a third of
people answering a JS survey were in the same boat. And I'm not worried about
the future of JS.

> If the survey was from a random sample of all programmers, the usage level
> would be much lower.

Is there _any_ language which more than a small minority of all programmers in
the world use?

~~~
nickpsecurity
"I'm interested in JavaScript, for example, but I don't use it more often than
a handful of times per year, if that. I wouldn't be surprised if a third of
people answering a JS survey were in the same boat. And I'm not worried about
the future of JS."

This may or may not counter the point. Your language specifically... per
various comments I've read here (esp vs Go language)... targets programmers
demanding high-efficiency or low-level usage that are basically using C, C++,
Objective-C, Java, or C#. Vast majority are with most in efficiency camp using
first two. So, _if_ data self-selected for those, then a third saying No
_could_ be a serious failure if the goal was replacing those with significant
uptake. At the least, it would be meaningful metric on if Rust was succeeding.

Unfortunately, we need the people responding to represent those groups to be
sure. I suggest that whoever has the responses filter out everything but those
languages above. Then look at the No's or any problems reported. Then, filter
again to get just C, C++, and Objective-C as they're the low-level ones. Then
look at the negative responses again. That could get information on uptake in
most important targets plus generate ideas for action to take for key
demographic.

~~~
pcwalton
First of all, it's not "my language". I haven't even worked on the compiler
for over a year.

Second, think about C++. A year after it came out, were 90% (say) of C users
who had heard of C++ using it? I highly doubt it.

There simply isn't enough data to compare to. So you can look at that number
and support any narrative you want by making up what you think a "healthy"
number "should" be.

~~~
nickpsecurity
Good rebuttal. Especially with the C++ vs C example. :)

------
JoshTriplett
I'm curious if there were any significant responses to the tooling/ecosystem
questions regarding packaging and integration with Linux distributions.

I'd like to provide an application written in Rust in major Linux
distributions. "cargo install" will not work, both because it depends on
network access, and because it pulls in dependencies from outside the
distribution. Similarly, many distributions have policies against bundling
library sources in the application. There needs to be a straightforward way to
turn a source package with a Cargo.toml file into a package for Debian and
Fedora that depends on other packages corresponding to its Cargo dependencies
(and C library dependencies).

~~~
steveklabnik
Cargo install was never intended to be used that way. It's for things useful
for Rust developers, not for people who use a program who happen to be written
in Rust.

There's a few things at play here. For "build from source" distros, we've been
making some changes to make it easier to package rustc. Namely, instead of
relying on a specific SHA of the compiler to bootstrap, starting with 1.10, it
will build with 1.9, and 1.11 will build with 1.10. This is much, much easier
for distros. As for Cargo dependencies on those packages, we'll see. There's a
few ways it could go, but we need the compiler distribution sorted first.

A second is that we'd like to eventually have tooling to make giving you a
.deb or .rpm or whatever easier: [https://github.com/mmstick/cargo-
deb](https://github.com/mmstick/cargo-deb) is an example of such a tool. This
won't necessarily be good enough to go into Debian proper; I know they tend to
not like these kinds of tools, and want to do it by hand. But "Hey thanks for
visiting my website, here is a thing you can download and install", these
kinds of packages can be made with this kind of tooling.

In general, it's complex work, as then, these issues are also different per
distro or distro family. We'll get there :)

~~~
JoshTriplett
I was more looking for a path to producing Policy-compliant packages for
Debian and other distributions.

Do you know of anyone working on that right now, and how I can help?

~~~
steveklabnik
[https://internals.rust-lang.org/t/perfecting-rust-
packaging/...](https://internals.rust-lang.org/t/perfecting-rust-
packaging/2623) is the big internals thread about it; weighing in there is a
good entry point. Thanks!

------
vegabook
Are disabled people "under represented in technology"? Just a question... I
have fused wrists from a motorcylce accident. It's inconvenient and I cannot
drive or play most sports, but I don't consider myself disabled. Am I under-
represented? Do I self-identify as disabled? No. Would others in my position?
Maybe... I guess that's a question about disabled threshold...

Do wheelchair bound people identify as "under-represented in technology"? I
don't even know. All I know is that some of them may say yes, and some of them
may say no. So we don't know who is in the 81%.

Gay - are gay people "under-represented in technology"? Somehow I doubt it.
Again same problem. You're gay. You're part of a minority group, definitely.
But are you "under-represented in technology"?

Wouldn't it have been better just to spell out the categories and ask people
if they are in them? "Are you white", "how old are you?", "black", "gay",
"trans", "female", "disabled" etc?

~~~
erickt
Rust Community Team lead here.

It is fine if people don't consider themselves underrepresented, we just want
to be proactive about discovering if people end up self selecting themselves
out of our community because they don't feel welcome. Furthermore, we are
starting some initiatives to focus growing a diverse group of participants
([https://github.com/rust-community/RustBridge](https://github.com/rust-
community/RustBridge)), and so we need some baselines to see if we are
successful or not.

We did have a number of categories that people could select from. Our plan for
next year is to identify groups from the free text for next year. We are
tracking our improvement plans here: [https://github.com/rust-
community/team/issues/28](https://github.com/rust-community/team/issues/28)

~~~
brighteyes
> we just want to be proactive about discovering if people end up self
> selecting themselves out of our community because they don't feel welcome.

Why not simply ask the question directly? "Do you feel welcome in the Rust
community?"

For those that respond "no, I don't feel welcome", it might be interesting to
also ask why, and to see if that correlates with demographics.

~~~
erickt
That's a reasonable question! I put that on our list for the next survey:
[https://github.com/rust-
community/team/issues/28#issuecommen...](https://github.com/rust-
community/team/issues/28#issuecomment-229799193)

~~~
markus2012
I quit doing the survey when I read the color question.

If you had worded it something like, 'do you feel welcome' I would have
answered (yes) and kept going.

------
firebones
Good start for a year one survey.

I'm surprised there aren't more Java devs responding. Rust is characterized as
a systems programming language, but Java is a language that has made
incursions down into the C/C++ "systems programming" space over the last
decade than any other language, and it is ripe for disruption by Rust due to
Rust's superior efficiency.

In agreement with the survey, I believe this will not happen until there's
good IDE support, and until more hardened enterprise-y dependencies/libraries
emerge (e.g., database access to things like Oracle via OCI or ODBC). After an
extended run with Rust, I returned to the Java 8 world briefly shocked to find
a) how much more productive a good IDE made me and b) how productive such an
IDE made me in terms of writing inefficient code! In there lies an
opportunity. Rust should be attacking Java from below. The waste in a typical
Java stack should make us all weep. The only barrier I see is perception
around the ownership learning curve.

In bouncing between languages, what Rust lacks (and what other languages have)
is the ability to pass the sip test...the first experience. Out of the box,
untuned Java screams due to JIT and the IDEs; it's only far later when you try
to do something serious that you feel the cost of the abstractions that help
productivity, and you're in a forest of JVM tuning options and writing non-
idiomatic Java code in order to get reliably performance and behavior. Rust
requires too much faith at this point--that the microbenchmarks matter and
that investment in mastering the borrow checker will pay off with more stable
performance and behavior later.

Other points: Cargo is underrated. Traits over primitives is a huge win over
Java's boxed collections. Community involvement and health is underrated.

Keep up the good work.

~~~
firebones
Someone posted a great question here that they later deleted. My full response
also wasn't submitted (and lost), so I'm trying to recreate part of it here.
It was actually a good question about whether Rust's efficiency has been
tested.

I've done some testing; Java is _faster_ in terms of the sip test for a lot of
stuff, especially for cases where you micro-benchmark single processes without
regard to overall CPU or memory usage. However, when you scale up (to the
point where JVM tuning comes into play), the raw performance in terms of
response time is comparable, while the overall system utilization (e.g.,
"time" measurements of user/sys) is much better for Rust--Java uses a _lot_
more system time due to JVM housekeeping threads. So more _efficient_ is not a
win for Java, even though wall-clock benchmark time might look better for a
single process (as long as you don't look at overall system utilization.)

Java's performance comes at the price of more memory usage and higher variance
in response time. You can attempt to constrain one or the other, but you can't
constrain both at the same time. Microbenchmarks typically put a high enough
ceiling on memory that they're relevant for very constrained loads. To be
robust beyond the microbenchmark, incremental GC is required, which levels the
playing field between Java GC and Rust's jemalloc. Still, even when you attain
parity, the Java solution is using far more memory due to the JVM's OOP
overhead.

Another example of a hidden "cost" of Rust comes from things like Unicode
support. Recently I tested a regex-heavy algorithm that used burntsushi's
regex library for Rust. In initial testing, Java blew it away. What I later
realized was that the default Java implementation I used did not support
Unicode characters. When I enabled that support, and enabled incremental GC
(to support the scale of testing I was performing), the performance was
similar.

This is another example of Rust being mischaracterized up front. Older
languages took short cuts, and fare well for the low end of testing (the
microbenchmark). Rust tends to look forward and to the bigger picture.

Anyway, sorry you deleted your legitimate question. It was a good one, and the
kind that will make Rust better.

~~~
burntsushi
> Another example of a hidden "cost" of Rust comes from things like Unicode
> support. Recently I tested a regex-heavy algorithm that used burntsushi's
> regex library for Rust. In initial testing, Java blew it away. What I later
> realized was that the default Java implementation I used did not support
> Unicode characters. When I enabled that support, and enabled incremental GC
> (to support the scale of testing I was performing), the performance was
> similar.

Could you explain a bit more about this? I find it surprising. If you can't
share the code, perhaps you could share the regexes? Which Java regex engine
did you use? (There really should only be one case where Unicode support
causes performance problems, and that's when you use word boundaries.)

~~~
firebones
It was a find_iter() across \w+. There was other surrounding code that might
have affect the output (it emitted (String, position pairs).

I will try to isolate a test case and reach out...

BTW, your fst is great stuff.

~~~
burntsushi
Thanks! If you come up with an example I'd love to see it.

Generally, even though `\w` in Rust's regex library supports Unicode, it
shouldn't result in a slow-down compared with the non-Unicode `\w`, assuming
you're using find_iter. (Of course, Unicode support isn't free, but the
primary cost here is memory and compile time, not matching performance.)

If you were indeed emitting `String` (a new allocation for every match)
instead of `&str`, then that could certainly be a possible explanation for the
slow down.

------
dom96
Thank you for publishing the results of this survey. It has inspired a similar
survey for the Nim programming language[1] that is still open, so please take
a look if you have a spare couple of minutes.

It will be very interesting to see how the results differ between Rust and
Nim.

1 - [http://nim-
lang.org/news/2016_06_23_launching_the_2016_nim_c...](http://nim-
lang.org/news/2016_06_23_launching_the_2016_nim_community_survey.html)

------
squiguy7
My favorite part about this survey is that for many of the questions there is
a majority agreement. Many developers believe that tooling needs to improve or
that crates should work with stable features.

I think this is great for the Rust team going forward knowing that they will
act on it.

~~~
kartD
It's early days for Rust, there will be general agreement on what needs work
because it's usually obvious and everyone has roughly the same experience with
the language.

I feel the difficulty comes when the language ages and the most apparent
problems have been tackled. Take Python, what's needed: async ? GIL fix ? more
functional? faster execution?

~~~
kibwen

      > async ? GIL fix ? more functional? faster execution?
    

Three out of these four boil down to "this isn't fast enough", which makes it
seem as though the Python community is unified in understanding the problems
it faces. :P

~~~
kartD
This could also be because of my limited knowledge of the Python community :P

------
bahjoite
"Person of color": perhaps this answer had so few responses because few people
identify as being a person of colour. The wording does seem rather twentieth
century.

~~~
douche
I feel like we talked about this already

[https://news.ycombinator.com/item?id=11959232](https://news.ycombinator.com/item?id=11959232)

~~~
bahjoite
Thank you. This reddit thread discusses it some:
[https://www.reddit.com/r/rust/comments/4ikawg/launching_the_...](https://www.reddit.com/r/rust/comments/4ikawg/launching_the_2016_state_of_rust_survey/d2yyb41)
plus there's this little gem[0]: 'Talking with my Korean friends here in
Korea, I found that they didn't check "person of color" checkbox because they
had no idea what that is. Typical response: "does it mean person with colorful
personality?" Just for your information.'

[0]:
[https://www.reddit.com/r/rust/comments/4ikawg/launching_the_...](https://www.reddit.com/r/rust/comments/4ikawg/launching_the_2016_state_of_rust_survey/d2zpndo)

------
bishop_mandible
As many women as trans people (1.6%).

~~~
minimaxir
That's actually a poorly-constucted survey question since a person can be a
part of several underrepresented demographics in technology, which makes
percentage breakdowns inaccurate.

~~~
thenewwazoo
The percentages total 106.6%.

~~~
vardump
Yup. Total is 3138 [1], not 2942. 196 are unaccounted for.

Maybe the survey form let you choose two or more different groups?

From the article:

> A huge thank you to the 3,086 people who responded!

3138 is also more than the number of respondents.

[1]: (2402+86+51+189+159+73+47+47+84)/2942 = 1.0666

~~~
masklinn
> Maybe the form let you choose two or more different groups?

Yes, since you can be a member of multiple groups.

------
MichaelGG
If items ("fn" definitions) implemented type inference instead of requiring
the programmer to manually document something the compiler can figure out, the
learning curve would be easier.

Especially with tooling that shows the type of any given expression
(integrated with an editor).

~~~
pcwalton
> If items ("fn" definitions) implemented type inference instead of requiring
> the programmer to manually document something the compiler can figure out,
> the learning curve would be easier.

No, it wouldn't. Not when the compiler is spewing error messages about types
you didn't even mention, especially if the compiler inferred that type on the
basis of code in some random other file you didn't know about.

~~~
MichaelGG
Guess our experiences are different. In F# I do this all the time, and I've
never had it be an issue. In Rust, if I'm trying to play around with
something, I have to figure out the signatures even when there's only one
option.

I hear this argument that the inferred types will be confusing (from C#, F#,
and Rust communities; I'm sure it exists in others) -- but they will be
accurate! It's something the human has to figure out anyways, except without
computer assistance. All because of some misguided attempt at enforcing
documentation guidelines and verbosity on programmers, sight-unseen.

I guess users can wait for IDE support with a "show inferred types" option.

Edit: And just as a note, I really love Rust. My only core complaint is the
verbosity. And that's a small price to pay since I'd either be paying with
perf/memory usage (more expressive languages) or bugs and far more verbosity
(C).

~~~
sanderjd
Just as an anecdote, the fact that Haskell does this (infers type signatures
for functions) is one of the things I don't like about it, because it seems to
often infer things that are surprising to me. I think inferring types in most
places, but enforcing explicit types at the level of method definition strikes
a really good balance. I care about the types required to satisfy _interfaces_
, but enjoy not needing to care so much in _implementations_.

IDE support for creating method signatures by inferring types would be neat
though.

~~~
MichaelGG
Haskell _allows_ it. The programmer decides if they want it. Requiring a full
signature inhibits natural code writing by introducing a high amount of
overhead per function. Writing a 1-line inner function is no longer an obvious
win. The annotation requirement applies to nested functions in Rust.

~~~
untothebreach
I don't really understand this issue. If I write a one line function in rust,
nested within another function, I will use a closure. Which, incidently,
rarely requires me to annotate any types.

