> 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?
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/.
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/ So if you're using a new enough vim, you shouldn't even need the plugin.
> But it turns out that I must install some kind of plugin manager just for rust plugin
It's not well documented, but there's a much simpler way, which I used until recently (newer versions of vim already come with syntax highlighting for Rust out of the box):
Checkout https://github.com/rust-lang/rust.vim and copy everything there except the README/LICENSE/.gitignore to your ~/.vim directory, keeping the exact same directory structure.
> This suggests that it would help to have better getting-started guides for vim, and for using it with RLS in particular.
Yeah I'm not sure that there's classic Vim support, langserver.org has two things that are both for NeoVim.
> Is anyone systematically looking over each of the responses
Someone (jntrnr) did read every single response, that's part of why this post took so long to produce. I just asked him about it, basically, he's going to be giving feedback to each of the teams about the stuff that was in their area, and they can act on it that way; so that'd be the language and community teams in these two cases.
> This suggests that it would help to have better getting-started guides for vim, and for using it with RLS in particular.
Oh man yeah I'm using vim to play around with Rust, would like to see a tutorial in term of usage of the plugins. Like a tutorial with vim and the guess number example would be nice while using the vim plugins. Idea whatever and VScode is meh. VScode is on the cloud iirc meeeeh.
It's based on Electron/Chromium and uses JS for extensions, but it's a local program in every other way. It's also fairly snappy, maybe much more so than the usual Electron app.
It does have the usual broken font rendering on Windows, as does everything that is derived from Chrome. But that's no an issue on Linux or macOS.
Every Chrome derived application, including everything Electron, has substantially degraded font rendering compared to native apps on Windows. Just load the same text with the same fonts and look side by side. Best way to describe it would be that the fonts are fuzzier and have less well defined outlines. Must be some kind of hinting + subpixel-AA issue, or Chrome not respecting the system ClearType settings, or whatever. The bug has been there for ages. I wouldn't care if Chrome was the only thing suffering from it, since you can use another browser, but the appearance of good Electron apps like VSCode has made it very painful.
Maybe someday Microsoft will port VSCode to Chakra.
Chakra is only the JS runtime of the Edge browser IIRC. So they'd have to open-source all of Edge in order to port VS Code to it instead (if they wanted to keep everything open source).
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.
Good idea. I noted that for next year's survey [1]. One of our big initiatives this year is working on our ergonomics [2]. I'm not sure if we can ever get as approachable as Python, but we've been working hard on trying to make the language easier. Results are starting to come out over the next couple releases. Things will hopefully be a bit better if/when you try the language.
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.
Rust Core/Community Team member here, who helped design the survey. You got it. We asked this question to check whether or not we're succeeding at maintaining our backwards compatibility. While we have great visibility on if we're breaking our open source community with tools like cargobomb [1], we don't have great visibility into running tests against our commercial users (which we got a ton now! [2]).
One of the PITA aspects of this type of break is when library writers need to change (via hard break) their external APIs because Rust has made a "minor break that can be easily fixed".
For example, one of the timely traits had `min` and `max` methods, as it corresponded to a type with upper and lower bounds. Rust added `min` and `max` convenience methods to all implementors of `Ord` (which this type was), which now means that anyone who wants to use the type needs to use UFCS. Or, I issue a major break so that their lives don't suck (now `minimum` and `maximum`).
The Rust change was classified as fixing a "papercut", so that folks wouldn't have to `use std::cmp::{min, max};`, but it's a pain in the arse when it's done so casually.
Yeah, it's really hard to strike the right balance here, and we're constantly learning from experience. Sorry for the pain! I'll put a note on the core team agenda to undergo a round of public discussion around policies here, which is overdue at this point.
Maybe a different way to frame it is: Rust provides a stability guarantee for `rustc`, but you could just as easily prioritize stability for the Rust ecosystem. If Rust gets some neat new features that break crates, the experience of stability for users is still missing.
Feel free to factor in that approximately five people use crates that I write, and most of them have bigger problems than Rust breakage. :)
Isn't this more-or-less true of any statically-typed language? I can't think of any off the top of my head that have the behavior of implicitly re-defining a type when a new definition is encountered after another definition was previously brought into scope.
Even C isn't that sadistic:
$ echo "\
> #include <time.h>
> struct tm {};" | cc -ansi -xc -
<stdin>:2:8: error: redefinition of 'struct tm'
struct tm {};
^~
In file included from <stdin>:1:0:
/usr/include/time.h:74:8: note: originally defined here
struct tm {
^~
Absolutely, I was trying to communicate that this is true across a ton of languages. This one isn't super specific to Rust; others may be depending on the exact feature.
- Changing inference in a way that may require new annotations
- Adding types and things to modules which may cause clashes on glob imports (steve's example above)
- Adding methods to types (this may cause code calling trait methods to require disambiguation via the fully qualified UFCS syntax)
- Adding new trait impls (similar disambiguation issues)
- Lint changes (If you `#[deny(lint)]` a lint, this may cause compilation failures). Cargo passes --cap-lints=warn to dependencies so a lint change will at most cause your dependencies to spew extra warnings and cause your code to stop compiling, in a way that's trivial to fix (allow the lint, or fix the warning).
In general for all releases we run cargobomb to look out for breakages, both "okay" ones and not okay ones. Additionally, for the first two kinds of breakages (and other miscellaneous iffy changes) we proactively cargobomb. Even if something is technically allowed by our stability rules we want to make sure that practically speaking it has minimal impact.
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.
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.
To give another example, a change was made in the type inference engine for rustc 1.18 that resulted it in no longer inferring types in circumstances where rustc 1.17 did infer types.
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.
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.)
Core/Community team that helped design the survey here.
We actually did ask about this, but unfortunately it's quite time consuming to process through all the free text entry like this one. Some of the popular things people want from nightly are Clippy, impl traits, RLS, SIMD, and compiler plugins, which isn't surprising. It'll take some time to dig through the rest of the comments to see if there is anything unexpected.
I'm hoping to do follow on posts as we go, but no promises :)
Among other things, embedded support; if you want to compile out the standard library, no_std effectively requires nightly right now. Many embedded developers are stuck on nightly for that reason.
I've seen some proposed solutions in progress for that, at the moment, such as standardizing panic_fmt (needed to write no_std applications).
It works very well for embedded; the only problem is that to build a complete OS-style image, you tend to need nightly, either for no_std or to build your own std/core for the target platform.
The requirement of a nightly compiler for many of my projects has been my biggest problem with Rust for both surveys so far. I recently made an issue for my largest Rust project, Ruma, that enumerates all the things we're waiting on from the nightly compiler, as well as other library/ecosystem maturity issues. Just in case anyone is curious what some specific problems are for a real project: https://github.com/ruma/ruma/issues/189
Just odd socially-charged community management and documentation. I get a strong impression that the lead contributors (perhaps it's a mozilla cultural affect?) are very interested in pushing their equality agenda. Not that I don't subscribe to it in theory, it's just very tacky to me.
Our code of conduct [1] has been the fundamental cornerstone of our project and community since the beginning. Every large institution ends up having to choose explicitly or implicitly how they deal with conflict. We wanted to put our beliefs up front to enable people to choose if they want to participate with us, or not.
When you boil it down, it's really "don't be a jerk". It doesn't seem to be that big of an ask that people don't harass each other, and for people to understand that everyone's situation is different. A lot of people have been discouraged from participating in tech, from active things like aggressive or rude language and sexualized imagery, to passive things like not providing for child care or mothers rooms at conferences. These are all things that are pretty simple to manage if you're aware of it.
It's our belief that not only is this just the right thing to do, it's our best strategy of growing our community. I don't have any proof, but I do attribute our welcoming community to why we have 1,856 contributors to just our compiler.
Got any examples where you think this shines through from the docs? Never noticed it.
(I could easily imagine it in the community management so I'll take your word for that, but I've only really interacted with the IRC channels where this wasn't an issue)
- User doesn't like that dining philosophers is cited with some male and/or gender-neutral pronouns and placeholders (even though the original exposition was already changed to female pronouns) -- proceeds to change the rest of the pronouns to female (I guess gender-neutral didn't make sense) https://github.com/rust-lang/rust/pull/25640
- User thinks that the code of conduct is too general in its suggestions that all people be respected and treated fairly -- it needs to explicitly cite certain groups https://github.com/rust-lang/rust-www/issues/268
This stuff is absolutely ridiculous. Write a code of conduct, make sure everyone is respected, and make that the end of it. Changing documentation to gender-neutral pronouns is something I can actually get behind -- nevertheless, that's still not fair apparently.
1) "User" is the principal engineer of most of Gecko's network stack and pointing out that using that name will lead to complaints during the standardization.
I didn't know that. The fact that a lead engineer is entertaining people who are upset with "brotli" being abbreviated to "bro" is honestly case in point.
If my giving examples of how mozilla as a company engages in social politics (the buildbot one is the best example) doesn't relate to rust, I don't know what to tell you.
Mozilla does not and cannot dictate what happens with Rust, given that we operate by consensus and Mozilla does not hold a majority position in governance. This is on purpose!
> Write a code of conduct, make sure everyone is respected, and make that the end of it.
But that's exactly what all of your examples are. In each situation the decision and action was to make things as neutral and inclusive as possible. That there are people in any given community which want things to be taken in a different direction (any direction, social or otherwise) seems like a pretty natural thing.
Good luck finding these types of patches in the Linux kernel dev community. There is a very specific type of culture that spawns this kind of timewasting.
You either waste a small amount of time up-front defining what's acceptable and how people should deal with each other, or you waste what's likely much more time the first time people have a major problem that could have been avoided with some sane defaults. And then you're faced with the choice to spend more time setting some sane default expectations, or you put it off until the next problem.
The real difference in why the kernel can work with that and other projects can't is the D in BDFL. What Linus says goes, so there's an ultimate arbiter (for better or worse) that can settle these problems, and set the tone. The LKML doesn't need a code of conduct because Linus is the example of conduct, which in this case is "words don't matter put up or shut up". That'f fine, as long as you're aware and okay with marginalizing the people that don't deal well with that, which can, and has happened on the LKML. But that's a choice for Linus. Rust doesn't have a BDFL, so there's no ultimate authority to define what's right or wrong for Rust and the community around it (as much as a BDFL can for something at large as a language). In that situation, a code of conduct that exists to set some sane defaults can be useful.
I don't exactly see the Linux kernel dev community as being inclusive, so that's not really an apt comparison. Nor is it a language-based community. It's a very specific set of people who are expected to follow the rules and do things in a particular manner; and for them that's okay.
For a programming language community though I don't think that's the kind of approach to take. Sure, it could work and you may get some very talented people to help, but it's also arbitrarily limiting the kinds of people who can contribute and feel welcome based on the thickness of their skin, not on their technical ability. You may consider this timewasting, but I think it's more like a clever and nuanced form or marketing. Not only do you get the benefits of including more potentially skilled people into your community, you encourage them to actually get involved with the language. It seems like a worthwhile investment to me.
Dude what you listed are trivialities and if you consider the throughput of Rust project the time taken must surely be negligible. I wonder what Theo or Brad think about timewasting on that other paragon of a project you mentioned.
Rust goes to great lengths to keep everyone happy, but ends up putting off people like you, who don't like projects going to great lengths to keep everyone happy :)
There was a GitHub issue that I recently saw where there was some bike shedding about rustfmt changing the option name "bad-syntax" (or something like that) to something less "judgemental". The reasoning being that you may have a particular coding style that differs from what rustfmt thinks is correct, and is thus "bad" (with bad being defined as giving bad input into a program). I'll try to hunt down the exact URL for the issue...
While the example isn't within official documentation, it does demonstrate the lead Rust devs placing a lot of importance on social politics, and tip-toeing around such politically sensitive topics as coding style.
Again, as the OP stated, nothing in how the Rust development community handles itself can be stated as bad. They go out of their way to be inclusive to everyone, and I think that's admirable. The way they go about it, at least from the example I found, is a bit tacky. There are more important things to bikeshed about than the name of a simple option, and in doing so it can come across as a bit tacky. But what do I know, perhaps I'm the real problem here!
It was about changing the name of a lint from "bad-style" to "non-standard-style".
I still don't understand what this change has anything to do with social politics. Nor was this really related to being inclusive or whatever, it was just about being nicer.
Sure, there are more important things to do. But that's true for just about any bikeshed, that's pretty much a prerequisite for a discussion to be a bikeshed.
> While the example isn't within official documentation, it does demonstrate the lead Rust devs placing a lot of importance on social politics, and tip-toeing around such politically sensitive topics as coding style.
That's a major extrapolation. I'm not a lead rust dev (I do have commit/r+, I guess that can count). I drive-by filed an issue during a conference talk that I thought would be a small improvement that would be nicer to newbies and also just more accurate ("bad style" doesn't actually convey anything, why is it bad?). Various rust devs posted opinions and thoughts there.
Nobody was tiptoeing or anything. You're grossly misrepresenting what happened there.
These types of issues/pulls are honestly intellectually demeaning. I know you're acting in good faith, but it really feels like MK-Ultra braindrain.
Imagine approaching Linus Torvalds at a conference and telling him that you think people who choose to disobey the documented code style (which I, and most others, do not necessarily use outside of Linux kernel code) are just using "non-standard code style".
But this isn't about code style for a repo. If folks don't use the rust code style for contributing to the rust repo, sure, their pulls will be asked to fix it and not merged till they do.
But as you yourself mention, folks use different code styles in different places. This is about being clearer about that.
The better analogy here is GCC calling non-GNU style C code "bad" in all repos it is run on.
Rust as a community is much more uniform wrt code style than C is, which is why the compiler even does things like warn about nonstandard style, but that's just it -- the style is non standard, not intrinsically bad in anyway (and "nonstandard" is better at explaining what's wrong than "bad" is).
But it's true that there's nothing inherently "bad" about the code. It's just not conforming to the standard style. It seems pretty reasonable to want that to sound less menacing than "bad code", which would hint very strongly that one has something semantically incorrect.
> Nor was this really related to being inclusive or whatever, it was just about being nicer.
In what wicked world do you live where the word "bad" is considered as a "not-nice" word should not be said in order not to risk offending people ? What's next ? Replacing "error" by "potential incorrectness" ? This is 1984-like. No one should have to be afraid of words.
This has nothing to do with political correctness or offending people. We didn't think it was some horrible mean thing to have bad_style. We just wanted to improve it, to be nicer (doesn't imply it was not-nice before, but improvement can always happen), and more accurate.
Feel free to continue to call it bad style within the Rust community. Nothing 1984-like about it at all. It was a request for changing some wording, one which could have been rejected, and we would have moved on, because it was a drive-by issue that I didn't care about much.
You're ascribing a lot of intent and background to that post, intent that wasn't there.
Not from the docs, but a pretty clear community example is that tickets for RustFest are more expensive for people who don’t belong to an underrepresented group.
Edit: replaced “minority” with “underrepresented group”, as that is the language used on the website [1].
> Not from the docs, but a pretty clear community example is that tickets for RustFest are more expensive for people who don’t belong to a minority.
Having just looked this up because I wasn't aware of it, I wouldn't classify that statement as true. They allow/ask for donations to help people from diverse locations attend.
NOTE: THIS IS NOT A CONFERENCE TICKET. Support us bringing the opportunity to attend RustFest to more people around the globe who otherwise couldn't afford it. Anything you offer here will go into our diversity pool with the sole purpose of helping people from underrepresented groups attend RustFest.
That doesn't mean minorities necessarily, and even if it did, it doesn't mean everyone in that group gets a cheaper ticket. From the first sentence though, it seems obvious they are trying to get diverse nationalities, not necessarily diverse ethnicity from the hosting country.
RustFest sponsors folks who couldn't otherwise attend with tickets (and sometimes travel and other things, I forget the details). This includes students (IIRC)
They also have tickets on the site which you can buy to add money to the sponsorship pool.
> We believe in diversity and would like to provide support to people of many different backgrounds. This includes, but is not limited to people who belong to one or more of the following groups: people of color, women, nonbinary and gender non-conforming people, disabled people, people with mental health issues, and LGBTQIA+ people.
First of all: RustFest is unaffiliated with Rust, the project. We are in touch, but we run our own ship. I _am_ member of the Rust community team, but my function within RustFest is not that one. Currently, I am the only person in the team with _any_ capacity within Rust, the project.
Most applications for this program are from places that the Rust community currently does not cover with conferences, which has a value to the wider community (spread). It is the express goal of this program to speak to people we would otherwise not reach. We had great success with our outreach program and it's meeting it's intended goal (having a more fun crowd around). We constantly tune it. We've been working and improving this program since around 10 conferences (I ran eurucamp and JRubyConf.EU before and are in close contact with other conferences running such stuff). Almost all people buying a ticket fund these things by either buying a supporter ticket (at 200EUR) or a small donation. They approve.
So, this may be "social politics", I'm very upfront about this, but this is not "we throw something at the wall and see if it sticks". No, we do it precisely because it is a working driver to growing a community. We have a stated goal: a more diverse community many people feel welcome to. We measure, we improve. Just 1.3% of respondents of this survey said they feel "not welcome", I consider that a smashing success. That's around 1/30th of the people that don't use Rust.
Yes, we give out scholarships to people that could or would otherwise not attend the conference. This is according to multiple factors, ranging from being unemployed to being a person from a marginalised group.
I also find it telling that you single this statement out, but for example pass on our wide commitment for accessibility http://zurich.rustfest.eu/accessibility/, which is much more extensive than what most other conferences provide. Also something we've been working on since _years_ and constantly improved. It attracts people. A great many conferences are very sub-standard here.
We do, by the way, also have a travel stipend for people that contributed to the current Rust quality push: http://blog.rustfest.eu/libz-blitz
Note that RustFest is a fully produced 2 days conference at a price point of 100 Euro or 50 Euro for Students which pays _all speakers full travel_ and is able to pay support for people in need. Running all 6 months. That's _dirt cheap_ if you consider we have to pay all bills and no one is giving us stuff for free. We are a sustainable business, if you want to consider it such.
In the end, I want to state clearly: sales and invites to our conference are at our own discretion, that's why we run them. It's the privilege of our work, we're not cogs silently turning a stage.
Unlike docs those conferences are totally optional when using the language. Which is why I asked for doc examples specifically, as that was OP's claim.
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%.
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.
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.
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?