State of Rust Survey 2016
blog.rust-lang.org
blog.rust-lang.org
Yeah that was a mistake. We were trying to cut out redundant questions, but it would have been so easy just to split this into three answers. We might be able to split this out based on secondary information, but we didn't finish that analysis in time for this post. Maybe we can get it into a future post if we trust our result.
If the survey was from a random sample of all programmers, the usage level would be much lower.
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?
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.
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.
Or it could just reflect strong interest for a relatively young language. I'd love to write some Rust in my day job, but it's rough getting support for using new toolchains and package managers (i.e., cargo). Relatively modest changes (C++11, CMake) are ambitious.
Anyway, if a suitable greenfield project or even a job offer surfaced, I'd be extremely interested.
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).
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 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 :)
Do you know of anyone working on that right now, and how I can help?
No, not "by hand". By automation provided by distribution.
And you know what it takes for this automation to be able to build a DEB out of the source tree? A "compile" command that (a) does not touch network, ever, and (b) does not expect dependencies to be downloaded into the source tree nor $HOME/.whatever, but allows them to reside somewhere in /usr/lib.
It's that simple, yet most of the language-specific package managers completely fail at this or at least make this building mode awkward.
BTW, the same stands for RPMs, and virtually any binary packaging system.
> No, not "by hand". By automation provided by distribution.
> And you know what it takes for this automation to be able to build a DEB out of the source tree?
There's absolutely nothing wrong with auto-generating the packaging files in the debian/ directory, as long as the uploaded package contains the generated versions. I'd love to see a tool that can generate a Policy-compliant Debian source package from a Cargo crate, ready for upload.
> (a) is already covered, as is (b). That said, we're still working on making it easier.
I've seen the proposed plan for addressing (a) and (b), namely shipping the full source code of library crates in the -dev package. Has this been implemented, in a way that Cargo can use?
Oh no, I meant that Cargo itself will already not hit the network, and you can configure exactly where it downloads sources. I wasn't aware of any "Cargo can use a .deb for source" plans.
You got it a little wrong. Cargo should not expect sources in -dev packages. It should expect precompiled libraries (static ones).
I'm glad to read this. The only thing that remains then is to keep programmers (those writing applications in Rust) from breaking either of these points...
> That said, we're still working on making it easier.
...and making the documentation clear how to use the build tool in this manner, even for sysadmin who doesn't write Rust code (I don't know the current state of Cargo's docs; maybe it already achieved that).
https://www.reddit.com/r/rust/comments/4ofiyr/announcing_car...
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?
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), 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
On the REPL side, we've had a few prototyped out [1] out over the years. We'd love something someday. What do you use for your scientific computing? We are also have some projects that are trying to ease using Rust with other languages ([2], [3]), so knowing what we should priorities would help.
[1]: https://github.com/murarth/rusti
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.
If you had worded it something like, 'do you feel welcome' I would have answered (yes) and kept going.
The idea of "representation" is rather silly and I'm always amused by how otherwise extremely intelligent software engineers completely throw out their scientific rigor when it comes to political issues and diversity. There's simply no evidence that deliberately assured diversity has any inherent value to a software project (or any kind of project).
And this is before bringing up the can of worms that is social engineering. The nanosecond in which you introduce deliberate manipulation of what would otherwise be organically formed groups, you unrealizingly cross a line into the slippery slope of what's OK or not OK for you to manipulate, resulting in a relativistic argumentation spiral to authoritarian behavior.
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.
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.
> My full response also wasn't submitted (and lost), so I'm trying to recreate part of it here.
Just an aside, that's exactly why I installed browser extension "Lazarus: Form Recovery" years ago. Let's me easily recover/reuse anything I typed into a form previously. Hasn't been updated since 2014 (Chrome web store) but works fine.
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.)
I will try to isolate a test case and reach out...
BTW, your fst is great stuff.
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.
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...
I think this is great for the Rust team going forward knowing that they will act on it.
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?
> async ? GIL fix ? more functional? faster execution?
[0]: https://www.reddit.com/r/rust/comments/4ikawg/launching_the_...
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
Yes, since you can be a member of multiple groups.
This survey question allowed for people to describe themselves as they decided, and so people could select multiple choices if they wanted, as well as enter in free text. The percentages John used in this writeup should just be compared to the total number of people that replied, rather than across each of these demographics.
Especially with tooling that shows the type of any given expression (integrated with an editor).
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.
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).
> All because of some misguided attempt at enforcing
> documentation guidelines and verbosity on programmers,
> sight-unseen.
Your description of contracts in Rust vs other languages isn't reflective of how they can be used. With global inference, nothing prevents a programmer from deciding where the major boundaries of his program are and annotating where desired. This not only provides the benefits of both worlds, but allows the author to decide where the contract and documentation goes.
Nothing is gained by requiring the programmer to annotate every little helper function, nested or otherwise. And for people just playing around, it brings a significant barrier. They must not only sort of grasp how the borrow system works, they must be able to write a flawless annotation to boot.
At worst, lack of annotations should be a warning (the warning can include the inferred type!), like the casing/naming style ones. Perhaps with an option for public/exported functions only.
(Sorry if my tone comes off hostile; not my intention.)
> "it's best that people document/annotate their types,
> so we require it."
"it's generally regarded as best practice to write out the types of your functions, hence Rust's choice here. ... Rust follows 'explicit over implicit'"[1]
If it's a technical limitation then that's far more understandable. I've just not heard this explanation until now -- not that I really was seeking it I suppose. Thank you.
IDE support for creating method signatures by inferring types would be neat though.
We also may just disagree about what constitutes a "high" amount of overhead. Thinking about the contract of my method does not seem like overhead to me; I have to do that anyway.