2017 State of Rust Survey
blog.rust-lang.org/2017/05/03/survey.htmlPosted May 4, 2017, 5:28 PM UTC
110109
blog.rust-lang.org
I've never heard of Rust. What is it generally used for or what is it comparable to?
15
Rust fills a role similar to c. I don't use it personally but started to learn it at one point and from what I understand its designed around the concept of eliminating garbage collection through memory safe checking in the compiler. Because of this design, the programs that do compile are usually fast compared to a similar c program. I'd recommend it if just to take a look at what they do differently.
33
This is a great answer, but I'd add two things:
First, due to this and other things, it's also seeing a lot of attention from those who have chosen to not write code in C for various reasons.
Second, the compile-time guarantees also help with concurrency, which is huge.
29
Because of this design, the programs that do compile are usually fast compared to a similar c program.
I'd say this makes them safe compared to C, not fast.
17
I think that "fast" means "same sort of speed as a C program, which is fast", not "faster than a C program".
14
Yes, it's in the same ballpark for an equivalent program: sometimes faster, sometimes slower.
Where it really shines is where concurrency could help, but people shy away from it in C because they are afraid of the maintenance cost (data races, ...). This is host Servo blows away the competition really: it's much more bold in its design because it uses a safe language.
6
Rust encourages safe zero cost if possible abstractions and let's you program low level without a GC allowing c like performance.
8
It's an OCaml-like language but with more traditional (Algol-family i.e. C-like) syntax and manual but safe (automatically checked during compilation) memory management. This makes it exciting because it's got all the ML-family goodness (first-class functions, sum types and so on) in a language that can run without a runtime, making it suitable for writing libraries that are used from multiple languages (e.g. I believe librsvg is now using it).
Alternatively it's a C-like language with automatic memory safety checking (which eliminates a big class of security vulnerabilities that are still endemic to C, at the cost of having to conform to a somewhat rigid style where every datum has a specific owner) and some fancy features that you don't have to use.
9
I find your priorities perplexing, or, at least, drastically different from mine. As much as I like ML (though I haven't had the chance to use it in almost 20 years), the benefits of "ML goodness" are little more than a minor aesthetic preference for me, and the first thing I'd give up, while the benefit of a safe C/C++ alternative cannot be overstated. If Rust had none of the "ML goodness" and yet still provided a safe alternative to C, I think its importance would not have diminished one iota. I won't say that the ability to write universal libraries in a language with ML goodness has no merit, but it pales so much in comparison that I think it's barely worth mentioning (let alone mentioning it first). It certainly isn't a goal that deserves the attention and investment Rust has been getting (not to mention that it has been done for quite a while on the JVM, which is a different kind of "universal").
In fact, I fear that this ML goodness may indirectly hurt Rust by attracting PL enthusiasts (who are a small minority among programmers, I think) who may influence the direction of the language in ways that may turn away the relatively-silent majority of non-enthusiasts. The way Rust achieves this safety is novel -- and not easy to digest -- enough without additional burdens.
2
I'm starting to wonder if the C folks were right about one thing: maybe memory safety isn't the biggest issue, incorrect code is the biggest issue and memory safety violations are how it manifests. Maybe the problem with C isn't that it's memory-unsafe per se, maybe the problem is just that it's a really bad language. Or maybe not.
In any case, the biggest problem I have that I hope Rust might solve is hitting bugs in system libraries (and in the JVM itself) written in C - or Java, to be honest - the consequences are less immediately severe but the bugginess is still there. Even on the JVM, often the only way to decode e.g. image or video formats relies on C/C++ code. Sometimes there's a promising library for one format in OCaml and one for another in Scala or Haskell, but that doesn't help me because there's no way to use them together.
I don't know what other merits a "safe alternative to C" has that I should care about. I think the notion that embedded devices need to use C-like languages is an outdated myth at this point, at least outside the realtime cases (and I'm not convinced about those either). A less-buggy kernel/hypervisor than the current crop would be a great thing, but is much less of an immediate problem for me than buggy libraries - fundamentally issues there are a much smaller proportion of those I face day-to-day.
2
I don't think most people care about languages being c-like or not, or about language design at all. The evidence clearly does not suggest that languages can reduce bugs in general (quite the opposite, in fact - languages seem to have negligible effect on overall bugs), but it's clear that languages like Rust or Java do eliminate a certain class of bugs, that turn out to be very significant in some respects, like security.
1
used for
Servo (Mozilla-backed browser engine), Redox (an OS), off the top of my head. I think Firefox has some Rust code within it too already. Either way, Rust is aimed at tackling low-level stuff.
comparable to
It's a zero-overhead, systems language (probably most closely rivalling C++) that aims to be safe, high-level and as fast as C (they actually consider a failure to do so to be a bug) without resorting to a GC. This is done through its so-called "lifetimes" that act as generic parameters of sorts, allowing the compiler to prevent several classes of errors without introducing runtime checks.
Feature-wise, it departs quite a bit from your typical Enterprise™ languages though, because it's full of functional ideas and prefers "traits" (simplified typeclasses basically) over OOP.
4
So it's a non-OOP language with traits and it doesn't have a compiler, basically?
0
[deleted]
0
I feel like you could have asked about the contributions to any Rust crate or to anything in rust-lang: docs, cargo, rustc, ...
Almost everyone that I know that uses Rust has either contributed once to a crate, or even maintains one sometimes. I'm not even talking about the tremendous amount of people who have contributed in some way to the rust compiler.
I feel like the community is very important, but it looks like there wasn't any metric for that in this survey. A question like "have you contributed to any Rust crate / library" with "Never", "No, but if I find something that bothers me, I will try to contribute", "Yes, I have contributed once or twice" "Yes, I contribute regularly", "Yes, I maintain one or several crates already" would have been very interesting, because I doubt that a language such as javascript (with nodejs) will have the same percentage of contributors that Rust has for instance.
It can prove quite a lot about the community, in my opinion.
12
I'd really like to see some good IDE support. Have code completion would be really nice for figuring out what methods a Data Type has. Hopefully the Rust Language Server will be stable soon.
5
Racer can do code completion (not that great but works)
2
It's an active goal of this year; the RLS should be good enough for some completions already.
What IDE do you use?
2
I tried using vs code + racer. Wasn't too happy with the auto completion. I guess I may have been spoilt by Intellij
2
Intellij has a plugin that's totally separate, you might want to give it a try.
Depending on when you used VS: Code, it might already be better; the older plugin was abandoned, and there's a fork of it that's actively maintained. Autocompletion works for me most of the time.
Anyway, we definitely want to make it better overall, still workin' on it.
5
Hey that's good to know. Will give both plugins a look when I get a chance. Thanks.
3
I'm surprised that a major pain point, the slow compilation times, is not present in this survey.
I wasn't involved in designing the survey, but we are already very much aware so I'm not sure it's worth asking about. If that makes any sense. It's something we're already putting a massive amount of effort into to improve, as it's one of the more consistent bits of feedback we get.
https://www.rust-lang.org/en-US/faq.html
How come Rust (a rather new language, I would say) is bogged down by "long-standing technical debt" in this case? Thanks.
You know how changing requirements means that your previous decisions don't make sense anymore? Well, rustc is written in Rust. So, before 1.0, the language was changing on a daily basis. So not only was what we were building changing, but the language we were building it in was changing, constantly. For about six years. This is basically a recipe for technical debt.
Two years after 1.0, we're in a better place, but not out of the woods yet. MIR took a long time, and already is making a lot of stuff better, but it's not done yet; the borrow checker hasn't been ported to it yet, for example, which will unlock "non-lexical borrows." Incremental compilation requires a very different compiler API than our previous, bog-standard non-incremental one, and was also waiting on MIR first.
TL;DR: Rust isn't magic. Programming is hard.
Perhaps the lesson for future language designers is that it may not be a important to achieve self-hosting as soon as possible. Go, for example, only did that some time after its public (1.0) release.
Besides avoiding the easy trap of making a language that's primarily suited for its own compiler, it also gives an opportunity to learn some lessons before rewriting the compiler in the language itself.
Improved compilation speed was one of the biggest requests from last year's survey, and indeed it's a huge focus this year (with incremental compilation and a new trait resolver in the works). If it's not in this year's survey then I'm not sure why, but regardless of that it's seeing lots of work. :)
You can certainly add that in the comments section!
How bad is it really? Is it better than C++?
I believe it tends to be faster than C++ at from-scratch builds, but it doesn't (yet) support incremental compilation, so every build is from scratch.
... of each compilation unit. Which tend to be larger than C's, but rust won't build the entire world all the time. That said, incremental recompilation can't come fast enough.
Ouch. That makes sense. It's probably pretty difficult to do incremental with all the safety features Rust tries to cram in.
The safety features have nothing to do with incremental compilation- they're carefully designed to be completely local. It's just a matter of putting in the work for the implementation (which is currently in beta).
I think Rust's strict function boundaries definitely will make it easier to implement incremental compilation - the rust team has just had some many other things to focus on that incremental compilation was not a priority.
By strict function boundaries I just mean that all safety features are marked at the function boundary for type checking - nothing is ever inferred from the body, it's all in the type signature.
Incremental compilation is being implemented now, I think now that the core team's "focus" for this year is usability - now that the language has many more of the features a language needs.
What? It is much much slower. If Firefox was written entirely in Rust, it would take a week to compile...
There's been one or two attempts to measure this by building similar projects in both, and Rust did come out a bit faster. That said there's so many details here that I think it's hard to say definitively one way or the other.
I mentioned it in "What could we do to improve adoption?"
Well none of the language's massive issues (crippled metaprogramming, crippled macros, still unable to write linked data structures without
unsafe, built-in safety only useful in trivial cases, hideously slow compile times, etc.) are here. There are more questions asking if you feel 'uncomfortable' in the Rust community because you're a transblack transwoman transAmerican.A modern browser engine is trivial?
Firefox isn't written in Rust. The safety that Rust gives you isn't useful in the cases where the compiler helping you would actually be helpful to avoid bugs. It's too stupid to understand complex code. It can only understand trivial code that any human can see is correct.
I'm not talking about Firefox- I'm talking about Servo, which is far more parallelized than any other browser engine, and it owes its ability to do that safely to Rust.
Parts of it are. https://wiki.mozilla.org/Oxidation
meta-programming and macro are not crippled : just not finished yet.
Most of the time, you never use unsafe, fast linked data structures are just a noticeable exception. Most of the unsafe blocks are for interfacing with other languages.
Unsafe blocks are not a misfeature of the language. Sometime you have to rely on structures that can't be automatically proved safe. Unsafe allow you to do not use potentially memory unsafe operations without noticing it.
So trivial than nearly every update for critical vulnerabilities on heavily monitored softwares (browsers, OS, ...) contain fixes for memory safety bugs. And Rust help prevent other kind of mistakes too.
They are crippled at the moment.
I've written Rust code, and you have to write
unsafea lot.I never said they were a misfeature. But you have to write them a lot more than you should have to write them. You have to write them when you have to do complex memory-management code. That's exactly when you want the compiler's help. And that's when the compiler throws up its hands!
No idea what you're trying to say here. Rust isn't safe.
This is nonsense. Maybe you used
unsafea lot to write Rust in your own style, but idiomatic Rust (as exemplified by Servo/rustc/just about anything on crates.io) does not.The compiler doesn't just give up. It lets you define your own invariants, and then enforces them for you in the entire rest of your program.
If you want to program a data structure while using safe Rust, then you need to learn about safe data structures, which there are many of, otherwise use unsafe Rust which just tells you why you should not be writing your own linked lists in the first place.
Good job totally missing the point.
Using safer languages requires learning how to program safely.
Why does that surprise you?