Rust 2018 survey results

It was a bit weird to me as well. There's like 7.x% of gay people which would leave 0.4% for non-gay people that feel that they belong to some kind of minority. It makes gay people look like having a ton of issues at once and I can't imagine that's true.

Or is it: "Yes I'm a woman, but I don't feel underrepresented"?

I think being a woman means (and certainly is intended to mean) you're automatically part of an under-represented group - namely, that of women. There are (far) fewer women among Rust users than in the general population, which you could say is the (a?) definition of under-represented.

The percentages can add up to >100% because you can be part of multiple groups, e.g. a gay woman.

> as the number of women is still lower than the industry average of women in programming fields

I think averages shouldn't be goals by themselves. And there's no good reason on why should Rust approach this Hypothetical Average, since Rust Lang != Hypothetical Average Lang.

I mean that I guess being closer to this hyp. avg. doesn't make it "better", whatever that means..

>It seems to exclude the possibility of women who don't identify as belonging to an underrepresented group.

Absolutely. If I had taken this survey, I wouldn't have checked "I feel underrepresented because I'm gay" because... well, it's literally never been an issue. In that sense, why would I care if I'm the only gay guy in a team of a million programmers? They all treat me just fine. Must I be "represented"?

I can imagine the numbers, for that reason, simply won't reflect the number of non-heterosexual people. It could be higher.

I'm not sure what population the survey intends to look at; it's not Rust users because 25% of respondents aren't using it (per the first question). We don't know how the survey was conducted. We don't know if women or others are overrepresented or underrepresented in the results - and that's relative to an undefined population. We know very little, and thus we can't begin to know the reasoning behind the quoted comment.

> women who don't identify as belonging to an underrepresented group

The existence of significant numbers of such people seems to be the object of much speculation on HN, possibly because it would undermine attempts to increase the representation of women. However, I have not seen evidence that such a population exists. Also, underrepresentation in this case is much more a matter of math and not one of chosen identity.

I would not pick Rust over C#/Go/Python for web development.

I've used it for:

* Processing 300GB of zipped text/access logs (my first attempt was in python and was much slower)

* Writing a git hook / git repo processor (again, first attempt was in python doling out to the git process alot. It was nice to compile a single binary for the hook, instead of worrying about having the correct python version installed)

* I'm writing a web service in Rust right now. It's a little rough around the edges honestly, but once async/await lands, I think I'll be much happier. The type safe templating and endpoint definitions I'm using are very nice, but probably not unique to rust. The compiler is also slow.

So probably not the best bet for webdev yet, but useful in other contexts.

It’s more like C than any of the high-level languages you mentioned, so yeah, it usually outperforms most of them. It’s basically “memory-safe C” with some modern constructs thrown in for good measure.

I personally wouldn’t build a website in Rust, but a webserver? Yeah, maybe.

> Does it only outperform them, or is it also a pleasant language to use?

I think you'll find a wide range of responses to this question, as personal preferences tend to vary quite a bit. For my two cents, I really enjoy using Rust, and I find myself super productive in it compared to other languages. In broad terms, I find Cargo to be miles ahead of any other build tools/language-specific package managers in terms of ergonomics, and in broad terms, I find the language to be expressive enough to save me a lot of time in having to define things I would have to in other languages and the compiler powerful enough to ensure that I don't break things when doing so. Granted, it takes time to learn how to leverage the expressiveness, and I can understand that not everyone will value this as much as things like being able to ramp up new developers quickly. I'll give the caveat that I don't actually do much web development, so my comments about expressivity/ergonomics describe the language itself and not the web ecosystem.

tl;dr Pleasant is subjective, but yes, some people (like myself!) really enjoy using it

I think the consensus among Rustaceans is that using Rust for web development today is an...aggressive choice. Especially with async/await not yet stabilized. I think most of the people doing it either have very specific requirements (wasm experiments maybe) or do it because it's fun to be on the ground floor of a new thing.

That said, I find Rust very pleasant to use. I don't have to make as many defensive copies of things or reach for as many immutable data structures, because I have much stronger guarantees around what code is allowed to mutate what data. I'm a fan of static typing, and I really like that enun matches will fail to compile by default if you haven't handled all the cases. There's a lot of explicitness like that, and I find explicitness pleasant. But of course different people feel differently about that, and there's also the widely acknowledged learning curve for lifetimes and borrowing.

Rust is a general purpose programming language, and as such, has a wide array of use-cases. Current production uses of Rust include:

* Extending other languages, like Ruby, Python, and JavaScript, for various tasks. Usually when performance is paramount.

* Web services (though see below)

* Infrastructure, such as Amazon's announcement today: https://news.ycombinator.com/item?id=18539539 and quite a few other things, like Chef's Habitat product, Boyant's linkerd2, Dropbox's core infrastructure, or System76's hardware flashing tooling

* Cryptocurrency stuff of various kinds

* Databases, such as PingCap's TiDB

* Operating systems, like Google's Fuchsia (This one is arguably not "production", but they are one of the largest employers of Rust programmers, and keep hiring... so maybe consider this, maybe don't.)

* Version Control systems, like Facebook's Mononoke, or the internals of mercurial itself, as well as things like Pijul

* Cryptography, in some cases working alongside C to slowly port things over

* Video games, mostly indie stuff, though some AAA studios have started to use Rust for various things, and a new studio, Embark, is going all-in

We have a partial list of companies that describe their usage here: https://www.rust-lang.org/en-US/friends.html

This year, we identified four areas we really wanted to improve Rust on:

* Embedded development

* Network services

* WebAssembly

* CLI tools

These are other common areas we see people wanting to use Rust in the near future, or areas where we could significantly improve Rust for that given case.

EDIT: I forgot to answer your other question

> Does it only outperform them, or is it also a pleasant language to use?

Performance is a key thing we hear from people in web development, but increasingly, it's also memory usage, both in amount and stability. Less memory means less money spent on servers, and steady usage makes scaling calcuations easier. For example, crates.io is a rust-based web application, and it uses about 30MB memory resident at all times, last I checked. That's very little. More serious systems use more, but often significantly less than the JVM.

>I mean, why would I pick it over C#/Go/Python for web development?

Who said it should be picked for web development?

It's however good for systems programming, libraries, embedded, data crunching, network systems, and so on...

There's more to programming than web development.

Rust is a modern, memory safe systems language. The code you write compiles to native machine which executes in a predictable way every time you run it.

If you need to write firmware for, say, a satellite, C# and Python are out because they have an intermediate step between your deployable and the machine instructions you eventually execute. You have an external dependency which adds a level of unpredictability. All three of your example languages are out because they are garbage collected languages, which makes them inherently unpredictable at runtime. The last thing you want is an OOM in the middle of a rocket engine burn.

Go and C# are competing with Python, Java, Ruby, etc. All languages you would write a web application in, but not a satellite's firmware.

Rust is competing with C and C++.

If you want a really fast webserver. Tokio's[1] zero-cost abstractions are amazing. Further, the examples provided make futures/async/low-level socket work quite understandable.

[1] https://github.com/tokio-rs/tokio

I'm a front-end developer, but I picked up Rust originally to do some audio processing in the browser/node - a thing that's still a little to heavy and time-critical for JavaScript.

Also the compiler is pleasant and gives you helpful advice on how to make your program compile.

Getting concurrency right is difficult, even in Go (I know, I have been there, it was a huge pain in the a$$). Rust guarantees via the borrow checker that the code is data race free. This alone is a huge advancement. I would argue that Rust contains as much boilerplate as Java, but Rust is as fast as C++ and safer than both.

-> You trade some code noise for safety and speed. Compared to C++ the code has even less noise.

Turning code into concurrent code is super easy in Rust. Just use the Rayon crate and change iter() functions into par_iter() and you are done (if the borrow checker doesn't complain).

Rust shines where you need robust code, speed (including reliable multicore processing, low memory usage) and possibly low-level interaction with the OS or hardware.

For me the robustness is great. It's not just memory safety, but strong type system without nulls is superb for avoiding stupid bugs (no more "undefined is not a function").

If you're writing a small blog, you probably don't need any of this — you won't hit resource limits, and you'll manage to write 100 lines properly in any language.

But if you need to process gigabytes of data, Rust may be super helpful:

https://blog.sentry.io/2016/10/19/fixing-python-performance-...

I've been deploying Rust to AWS Lambdas for months for a side project. I chose rust because it's just my favorite language to work in - I'm very productive in it. I also really wanted predictable, solid performance, and Rust is a great fit for that.

I don't really like any of the 3 languages you mentioned though.

You should think of Rust as a better systems language, a better C. This was something that Go was pitched as but as a GC language it just doesn't fit a bunch of systems applications.

What I think is driving Rust and will continue to drive Rust is how it compares to C/C++ in certain key areas:

- Ownership is enforced at compile time. C++ obviously has smart pointers now (ie std::unique_ptr and std::shared_ptr) but these come with not insignificant runtime cost. What's more you end up passing around raw pointers anyway at least some of the time.

- C/C++ do suffer from and will continue to suffer from memory corruption, buffer overruns and undefined behaviour resulting from this. This has been and will continue to be the source of security vulnerabilities.

- Security is becoming so important and software so large and complex that the need for memory safety without sacrificing runtime speed will become increasingly important.

I honestly see a point where there'll be a need for a safe OS that is written in Rust or something like it.

One other thing about Web development: I think this is one area where Rust offers no real benefits (other than memory safety). Honestly I think the best model for serving HTTP requests is the cooperative multitasking model used by Hack (FB's PHP successor) where everything the request uses and does is created and torn down within the scope of a single request. This is a model that's far easier to reason about.

I came from years of doing Java where we had to deal with full GC pauses (something Go isn't immune to either).

In short: any place you would use C/C++, and lots of places where you wouldn't.

It will outperform them (although not by much in the case of Go and C#), and it's also a pleasant language to use. It has a number of features like traits and enums which make it possible to expresa business logic in a way that can feel more natural than OOP classes.

It's also fantastic for reliability. In the same way that Java and C# represent a step up from python/php/js in compiler driven correctness, Rust represents another jump of similar magnitude.

The way I'd describe Rust is, it's what C++ would have been if it used ML as a source of inspiration rather than Simula, and didn't care about preserving syntactic compatibility.

To unpack, this means that it's still a language that is very "close to the metal" in terms of lack of overhead, and broadly follows the don't-pay-for-what-you-don't-use C++ maxim. But at the same time, it's a very high-level language with lambdas and ADTs and destructuring.

Rust might be good for algorithmic trading, and is good for other real-time uses. It's good for building wasm modules. It's good for most any kind of performance sensitive or resource constrained application. If you need high throughput, low latency network services, it's good for that. CLI tools. You can build libraries to expose through C FFI, and even plug them into nodejs to do heavy lifting for existing js codebases. I think its good for anything c and c++ get used for and a lot more.

It's not that good for rapid prototyping, won't please many big enterprises who don't trust it and can't hire maintainers easily, and it can't do much on mobile phones. There are also some types of integration work where you'd be wasting your time with rust due to lack of domain specific crates.

Should they have had a perfect idea of how many others were non-heterosexual?

The question asked about "technology", not the Rust community. It can be interpreted as implying that non-heterosexuals are underrepresented and simply asking if the respondent identifies as non-heterosexual. Also, people's concepts of representation often include visibility.

> When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm.

as for how `rustup install nightly`

For a long time, there were really useful things that were available only in nightly, I believe.

The Rust team has also done an unprecedented job of balancing stability and improvement.

It's very easy to use nightly (install via rustup, then `cargo +nightly blah --args` instead of `cargo blah --args`), and there are (ugh, still) a number of somewhat popular libraries that require nightly versions of the compiler.

In particular, using nightly allows you to opt-in to a number of experimental language features in exchange for maintenance burden. It's not a choice I make, although it's fun to do every now and then just to get a feel for what's available in the nightly builds.

Companies using Rust are not too conservative I think. Conservative companies use Java or C++, or something similarly stable and easy to hire for.

At this point, I think it's mostly being used to it as nightly was more convenient for a long time.

I've currently switched to nightly to use the 2018 edition changes already, which will soon be unnecessary.

Almost all libraries work fine on stable now. (the new async/wait support is an exception, but it's still very experimental right now and not used by many)

Important note: You can always develop on nightly and get potential speedups etc, but not use any features and then deploy only with stable.

I've seen some people gladly using nightly rust but restricting themselves with the GCC and CMake that comes with CentOS 6. The damage done by distributions shipping development toolsets is never-ending.

Nightly isn't really as unstable as the name implies. Without invoking `#![feature(...)]` flags it's basically functions identically to stable. Sure, occasionally something breaks, then you type `rustup default nightly-<a date a few days ago>` and keep on chugging.

Meanwhile you get access to more and better tools, which has no impact on the stability of your code base but a positive impact on productivity. It enables you to decide to bite the bullet and give up on language stability for new useful features if you want to (which I often do, for nll).

So, what I do is develop on nightly, and make things I want other people to use work on stable.

The biggest one for me is the async/await support for futures, which is not stabilized quite yet. In Rust it buys you not only the usual ergonomics, it also allows you to handle lifetimes in futures in ways that are basically impossible when using only combinators.

Some of the packages I use require nightly, Like the syscall crate and iirc I had to use the nightly compiler for inline assembly as well.

Right now, a lot of people want nightly (and [Rust 2018]) for NLL. It makes the borrowchecking system a lot more precise and less conservative, which in turn makes the language much less annoying to use.

Using nightly as the compiler is much easier in Rust than, for example, using Python 3 early on was, because unlike, say, Python 3, nightly is fully backwards-compatible to earlier stable releases. (While not being backwards-compatible to previous nightlies.)

This means it's easy to limit yourself to the features used in stable + one major change you want, and if there is no change to that major feature, you won't even notice all the instability of the compiler.

There has been some hope of people moving to stable versions as NLL hits them, I think most people will always want the next big feature (personally waiting for const generics) on nightly, at least until the language is a lot more complete.

when i was checking things out a while back, it felt like every interesting library required nightly. it was a significant turnoff. :\

Companies? Only 30% of respondents reported using Rust at work. Presumably a majority of Rust hobbyists use nightly and less so for those writing Rust for a job.

We ship all stuff on stable but I regularly use nightly for local development to get extra features for debugging (for instance cargo expand is nightly only).

Most of the programmers out there do not have any community contact outside of the company they are part of.

We are not representing the majority here

Thanks! And to jononor's comment below as well.

We're not exactly data scientists... maybe for next year we'll make some of these changes.

That's true of 95% of all pie charts in existence. Yet pie charts still seem to be the default choice for graphs. I honestly don't understand it.

> Coming from a C++ background I consider the Rust library ecosystem to be one of its strong points already!

In a sense, I agree with you. Certain kinds of features available in the Rust ecosystem are much more easily available than in the C++ world, and there's been a lively pace of articles published about libraries and applications in Rust. But another sense I got from looking at libraries to use myself and applications to learn from was that the ecosystem is quite smaller and ... not quite as matured as the C/C++ ecosystem (I'm _completely_ ignoring FFI for this argument). Of course, all of this is completely natural, and I'm simply not expecting them Rust ecosystem to be competitive with the much older C/C++ ecosystem(s), but this realization does temper my excitement with Rust a bit.

I have a feeling some of it is due to all the "Why isn't X in the std library" questions being bundled into library support.

If this is the case then its a bit misleading as it could be loads of people asking for a single thing, rather than people asking for better library support in general.

I don't think the Rust Standard lib is too bad, so i'm also surprised its so high up.

Agreed. I also wonder what "productive" means. It would be interesting if they framed it in terms of other languages ("I'm as productive as I am in my most-frequently-used non-Rust language") or similar.

I use Rust daily, and it took me a while to be productive. Productive is hard to define, and I guess I'm not "all the way there"; the design of a Rust project still takes me longer than a C++ or JavaScript one, mostly due to its pervasive restrictions around mutability.

There are still things I'd have trouble doing. I used to do game development professionally, and I still don't think I'd use Rust for it. I also have worked on virtual machines and high level programming language runtimes, and I wouldn't want to write a GC in Rust.

(Yes, I've seen shifgrethor[0] and the rustconf 2018 closing keynote[1] (I was there, actually) -- both are great, but they're almost more examples of my point; Rust makes certain patterns much harder).

[0]: https://github.com/withoutboats/shifgrethor/

[1]: https://kyren.github.io/2018/09/14/rustconf-talk.html

Coming from Crystal/Ruby, I just could never get it to do what I wanted it to do. Tried writing a generic stream API, and using closures naturally like anyone would to do things like "on_data" etc., only to run into insurmountable life cycle and borrowing problems. Tried for 4 weeks straight to get the same 100 lines of code to work. Ended up giving up when the rust gitter told me it was impossible to do this sort of thing, and wrote a perfectly working implementation in crystal in an afternoon.

Not currently, as we only blog in English.

We’re still, as a project, working on i18n. Conducting the survey was one of the big first steps. We’ll get there.