Results of Rust Survey 2016 – early draft for internal usage(docs.google.com)
docs.google.com
Results of Rust Survey 2016 – early draft for internal usage
https://docs.google.com/document/d/1F6oELZcO_ejX2oVk20hmiBWd4lQugfFahn7OOOOyKsw
109 comments
Sorry, I saw it on IRC and didn't know it wasn't supposed to be public
We do most of our work in public, so it is public, just not intended for distribution :)
(In the case of the survey the analysis itself was conducted privately, because the data contains personally identifying information. But usually things are done in the public.)
(In the case of the survey the analysis itself was conducted privately, because the data contains personally identifying information. But usually things are done in the public.)
Happens, I see the need to clarify a bit around #rust-community there :). No harm done.
We added that to the title and buried the submission. One thing we've learned over the years is that it's fine to wait until a story is actually ready before discussing it.
> By large margin, users are often grabbing vim to do their Rust work in
I would rather assume the reverse theory. Vim users are more likely to use new languages since they don't expect complex IDE support. Or maybe just: Early adopter and vim user correlates.
I would rather assume the reverse theory. Vim users are more likely to use new languages since they don't expect complex IDE support. Or maybe just: Early adopter and vim user correlates.
(disclaimer: I'm a vim user)
Also maybe because rust and vim appeal to the same argument of "performance/only come with the stuff you need"
Also maybe because rust and vim appeal to the same argument of "performance/only come with the stuff you need"
To be fair. With YouCompleteMe and rust-racer support the tooling for Rust in vim is solid.
I disagree. I'm used to vim-go, and the difference between that and YCM + rust-racer is stark. Rust really needs to catch up here before it can get a larger share of my hobby time.
That is only completion? IDEs provide more. Refactoring and Debugging, for example.
(I'm a vimmer myself, but that is what I hear other people complain about)
(I'm a vimmer myself, but that is what I hear other people complain about)
Sure, but you have to start somewhere.
With the internal representations of Rust still being changing almost weekly, transformational tasks are a chore.
Debugging is shipped through Rust support in gdb and rust-gdb, so it is coming.
That's the thing about Rust: there's always lots of stuff that is close. We prefer solid over half-baked, and try not to advertise stuff in flight to much.
With the internal representations of Rust still being changing almost weekly, transformational tasks are a chore.
Debugging is shipped through Rust support in gdb and rust-gdb, so it is coming.
That's the thing about Rust: there's always lots of stuff that is close. We prefer solid over half-baked, and try not to advertise stuff in flight to much.
The first diagram shows that 35.5% of respondents don't use, or stopped using, rust.
Its a shame they don't break this down between those who have never used it vs those who have stopped using it.
At the end of the results there's talk about why those who don't use rust don't use it, but again it doesn't separate out why people have never used it vs why people have stopped using it.
I imagine it would be a very interesting to have had this split.
Its a shame they don't break this down between those who have never used it vs those who have stopped using it.
At the end of the results there's talk about why those who don't use rust don't use it, but again it doesn't separate out why people have never used it vs why people have stopped using it.
I imagine it would be a very interesting to have had this split.
I'd also like to see that. I'm in the "temporarily stopped using" camp. I love it, I got to the level where I don't fight the language anymore, but facing reality - I don't have a reason to use it. Everything I do at the moment, I can finish faster in Python and I know it's enough. (sysadmin / deployment / security tools)
The moment I need good performance and safety (new protocol server?), I'll reach for Rust. But I don't have that many real problems where it's worth it.
The moment I need good performance and safety (new protocol server?), I'll reach for Rust. But I don't have that many real problems where it's worth it.
I went further and now I write in Rust with the same speed as with PHP. And my benefits: awesome system of errors handling, enums, match patterns, easy and safe multithreading, MySQL shared prepared queries, and majority of bugs is being catched by compiler (thanks to strict typing and a lot of checks in compiler).
As a mostly PHP developer I'd love to hear more on your PHP -> Rust transition. I helped with a single commit to the early Rust documentation, but this was back in the alpha days. I'm still writing PHP because that's what the job is, but also because I couldn't figure a use case. Would be nice to see from someone who succeeded in his transition!
So you jumped from PHP to Rust? That is very interesting.
May I ask what you were doing in PHP that you do now in Rust?
May I ask what you were doing in PHP that you do now in Rust?
REST API for Angular SPA and Ionic mobile apps.
Few months ago I wrote this article: https://medium.com/@eugeniyoz/restful-api-in-rust-impression...
A lot of things between me and Rust has changed since then, but all changes are positive :)
Few months ago I wrote this article: https://medium.com/@eugeniyoz/restful-api-in-rust-impression...
A lot of things between me and Rust has changed since then, but all changes are positive :)
Would you like to be featured on https://www.rust-lang.org/friends.html ? Feel free to click the link on the bottom.
being caught by the compiler.
Have you been writing too many try/catch statements?
Have you been writing too many try/catch statements?
Note that we tried to publicize the survey amongst non-Rustaceans, so I expect most of these respondents are those who never used it in the first place. We got an overwhelming positive response, especially in the freeform comments.
There's also:
> Equally encouraging is seeing that once someone has become a Rust user, they tend to stick around and continue using it. One might expect a sharp drop-off if users became quickly disenchanted and moved onto other technologies. Instead, we see the opposite. Users that come in and stay past their initial experiences tend to stay long-term, with a fairly even spread between 3 months to 12 months (when we first went 1.0).
There's also:
> Equally encouraging is seeing that once someone has become a Rust user, they tend to stick around and continue using it. One might expect a sharp drop-off if users became quickly disenchanted and moved onto other technologies. Instead, we see the opposite. Users that come in and stay past their initial experiences tend to stay long-term, with a fairly even spread between 3 months to 12 months (when we first went 1.0).
Thanks for your work guys. I took part in the survey when I found it on Reddit. Yesterday I started my first project in two new technologies, Rust and GTK. That's completely different experience and perspective of designing code after years of C++(Qt) and Java(backend). Now I wish I was earlier adopter :)
Thank you! I'd love to hear more about your experience, though perhaps once you have worked a bit more on the project :)
Eh, early adoption is overrated -- you have to fight through lack of docs, lack of libraries, and general ecosystem issues, all while the language keeps changing underneath you :P
(Note that not everyone who works on Rust; or even who worked on this survey, is a guy)
Eh, early adoption is overrated -- you have to fight through lack of docs, lack of libraries, and general ecosystem issues, all while the language keeps changing underneath you :P
(Note that not everyone who works on Rust; or even who worked on this survey, is a guy)
> I'd love to hear more about your experience
I had good experience integrating glade (GTK GUI generator) to Rust, but bad experience with getting auto-complete working in Eclipse, in fact it's still not working ;) It's a pain when I using new technologies (both Rust and GTK are new to me). I want to change its state from `checked` to `unchecked`, and I don't know what's name of the method that does it, it can be setState(bool) setChecked(bool), setEnabled(bool), setActive... you know what I mean, the method is there, but checking docs just to get method name is annoying. I'll try it in vim later today.
My goal is to write (simple) desktop sharing application. Any thoughts how hard can it be? I need OS-integration, ffmpeg to catch screen, integration with decoding video stream without bloating systems...
I had good experience integrating glade (GTK GUI generator) to Rust, but bad experience with getting auto-complete working in Eclipse, in fact it's still not working ;) It's a pain when I using new technologies (both Rust and GTK are new to me). I want to change its state from `checked` to `unchecked`, and I don't know what's name of the method that does it, it can be setState(bool) setChecked(bool), setEnabled(bool), setActive... you know what I mean, the method is there, but checking docs just to get method name is annoying. I'll try it in vim later today.
My goal is to write (simple) desktop sharing application. Any thoughts how hard can it be? I need OS-integration, ffmpeg to catch screen, integration with decoding video stream without bloating systems...
> I'll try it in vim later today.
I use YouCompleteMe with vim, which works for many editors as well as many languages. Though I recently switched to a mac and the sublime plugin is broken :/
> Any thoughts how hard can it be? I need OS-integration, ffmpeg to catch screen, integration with decoding video stream without bloating systems...
Shouldn't be too hard. Rust certainly won't stand in your way, but I'm not aware of how hard some of these things may end up being :)
I use YouCompleteMe with vim, which works for many editors as well as many languages. Though I recently switched to a mac and the sublime plugin is broken :/
> Any thoughts how hard can it be? I need OS-integration, ffmpeg to catch screen, integration with decoding video stream without bloating systems...
Shouldn't be too hard. Rust certainly won't stand in your way, but I'm not aware of how hard some of these things may end up being :)
Note that many people use the term "guy" without relation to sex or even being a person.
I know. I'm not questioning the intention, I'm requesting the term not be used that way -- it is known to alienate people.
Communication is a two-way street. A polite speaker has to take into consideration how their audience wants to be addressed, but polite listeners need to take into consideration that the speaker's words are the speaker's. My autistic brother will get very anxious when he anticipates a specific phrase in response to something but the person words it differently from how he expects, and he then insists that the person repeat the phrase with the "correct" version. The motivation is different from blind political-correctness, but the crime is the same. Words are symbolic of experience, and even though we all generally agree on what words mean, different people associate them with different experiences, so they essentially have reimplementation of the same word. Why should one person have to fully accomodate one person's implementation of "guy" while the other person just ignores what they know the first person means by that word?
> it is known to alienate people
I've not heard this before. Citation?
I've not heard this before. Citation?
> it is known to alienate people.
So is language policing.
The Rust Code of Conduct [0] states:
Don’t just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they’re off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely.
You've brought up something off-topic (and potentially sensitive) when there was no real need, and definitely no ill-intent in the original - and just like the code of conduct predicted, it's already starting to develop in to unnecessary bickering.
This sort of language policing is exactly the type of thing that can drive people away from a community - and was not really necessary in the original context.
As per the Rust Code of Conduct the correct response would have been:
if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize
Now, before you go on to defend yourself, the CoC further states:
Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could’ve communicated better
And that's something worth considering.
Now, I know that the Rust Code of Conduct states that it is only enforced on official Rust venues, and so there is no expectation of you following it here on HN, but as a respected member of the Rust community I would hope it was something you would still follow in a public forum, out of respect for what it stands for.
[0] - https://www.rust-lang.org/conduct.html
So is language policing.
The Rust Code of Conduct [0] states:
Don’t just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they’re off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely.
You've brought up something off-topic (and potentially sensitive) when there was no real need, and definitely no ill-intent in the original - and just like the code of conduct predicted, it's already starting to develop in to unnecessary bickering.
This sort of language policing is exactly the type of thing that can drive people away from a community - and was not really necessary in the original context.
As per the Rust Code of Conduct the correct response would have been:
if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize
Now, before you go on to defend yourself, the CoC further states:
Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could’ve communicated better
And that's something worth considering.
Now, I know that the Rust Code of Conduct states that it is only enforced on official Rust venues, and so there is no expectation of you following it here on HN, but as a respected member of the Rust community I would hope it was something you would still follow in a public forum, out of respect for what it stands for.
[0] - https://www.rust-lang.org/conduct.html
You know, if you feel the need to make an account to post what amounts to a rules lawyering comment to what you perceive as a language police comment, perhaps you're taking the wrong approach. There are less blunt methods.
You are right, and I apologize.
It was done to belabor a point. Namely that for a community that aims to be welcoming, belaboring that point can actually make it less welcoming.
It is taxing to participate in an environment where common language usage causes people to take offense where none is given or intended.
It was done to belabor a point. Namely that for a community that aims to be welcoming, belaboring that point can actually make it less welcoming.
It is taxing to participate in an environment where common language usage causes people to take offense where none is given or intended.
Using the word "guys" to describe Rust developers is not offensive; it's just incorrect.
How is it incorrect - 'guys' (plural) is not gender specific, and refers to groups of people regardless of gender.
In addition to general usage anecdotes (of women using this word to address groups of women), I'm happy to provide dictionary citations if you'd like?
In addition to general usage anecdotes (of women using this word to address groups of women), I'm happy to provide dictionary citations if you'd like?
"Guys" is a fairly complex term[1]. Its common gender association changes when used plurally from male (when used singularly) to non-gendered. Like "man", when used in place of "humanity", I believe it's a holdover from a time when it was entirely acceptable to be dismissive of half the race. As such, it's probably appropriate to be at least a little sensitive to the topic, since it's not just a matter or speech norms, but a reference to past inequality.
1: http://english.stackexchange.com/questions/11816/is-guy-gend...
1: http://english.stackexchange.com/questions/11816/is-guy-gend...
Later in this thread, someone even uses it specifically to refer to only men:
> The reason I said hostile is that in most discussions on Hacker News and Reddit a lot of people argue that the only reason women are so under-represented in tech is that all the guys are very hostile to women. This survey goes against that. For some reason they refuse to believe that some things are more interesting to women than men and vice versa.
> The reason I said hostile is that in most discussions on Hacker News and Reddit a lot of people argue that the only reason women are so under-represented in tech is that all the guys are very hostile to women. This survey goes against that. For some reason they refuse to believe that some things are more interesting to women than men and vice versa.
In the "people who have never used it" camp, I just started learning Rust and wrote a toy program yesterday. I was very pleasantly surprised by how helpful people in the IRC channel were, they were very patient and eager to help.
I'm really liking everything I'm seeing in Rust so far.
I'm really liking everything I'm seeing in Rust so far.
Hmmm. That 20% of Rust users identify as part of an 'underrepresented group' does not seem like poor number. I would naively guess that it is a larger percentage than exists in the overall technical population. If that's correct, then bravo Rust!
(If anyone knows about numbers along those lines, I'd love to hear about it.)
(If anyone knows about numbers along those lines, I'd love to hear about it.)
This part of survey is really weird and full of American racist bigotry. What does "Person of color" mean considering people all around the globe? In Africa or India whites are super-minorities so should they vote as "persons of color"?
You may be interested in the discussion on this topic from when the survey was posted: https://www.reddit.com/r/rust/comments/4ikawg/launching_the_...
What terms would you recommend that they use instead?
As national/racial/other "minorities" issues as well as their common understandings are very different around the World, I would like to avoid any questions following any paradigm, if we're building truly globalized community, not a racist one following American views on American problems.
Amazing how a bigger focus is placed on getting certain demographics to use a programming language rather than focusing on improvement of the language itself.
Where did you get "bigger focus" from? It seems to me they are hard at work improving the language all the time.
Programming languages are for programming, not capturing token demographics. This shouldn't even be a consideration.
Programming languages are used for and by humans. The experience of the people using the language plays a massive role in the success of the language and of the software built with it.
So why are we needlessly injecting race and sexual orientation into something that used to be just about programming? Are we tracking the demographics for lawn sprinkler users with equally bated breath?
Stop trying to insert your identity politics into everything. Let's just leave a few pure things in this world, please.
Stop trying to insert your identity politics into everything. Let's just leave a few pure things in this world, please.
What I don't get is how you consider this such an important crusade to go on. Is collecting the opinions of under-represented groups such an objectively damaging thing that you're going to spent your limited energy and time on earth fighting that? Can you seriously think of no better things to be concerned about?
oh come on. just stuck it up, we don't need grand standing on this topic here.
Rust has had a code of conduct from the beginning too; that's their choice. Its also part of the Mozilla charter I believe.
If you don't like it, tough luck.
Run your own project however you like, but you've got no ground to stand on how others run theirs.
Rust has had a code of conduct from the beginning too; that's their choice. Its also part of the Mozilla charter I believe.
If you don't like it, tough luck.
Run your own project however you like, but you've got no ground to stand on how others run theirs.
I would argue that the language will benefit from having more diverse feedback.
Does anybody actually believe that diverse cultural backgrounds are at all relevant to ideas about programming language design or compiler programming? Claims that diversity is good for project organization sound believable, but I see no reason to think the diversity of background has any impact on technical contributions.
There is no moral obligation to have a diverse group, just to have a group that is tolerant of diversity, in the interest of fairness for members of minority groups. Encouraging actual diversity is just a strategy to avoid letting people who don't care about this stuff develop bubbles of intolerance in homogenous bubbles where intolerance isn't challenged regularly. The presence of diversity indicates a lack of intolerance, but a group consisting entirely of one demographic could be just as tolerant, and its homogeneity just a coincidence or a result of lack of advertising. So I find it a little strange when a group is "congratulated" on its diversity.
There is no moral obligation to have a diverse group, just to have a group that is tolerant of diversity, in the interest of fairness for members of minority groups. Encouraging actual diversity is just a strategy to avoid letting people who don't care about this stuff develop bubbles of intolerance in homogenous bubbles where intolerance isn't challenged regularly. The presence of diversity indicates a lack of intolerance, but a group consisting entirely of one demographic could be just as tolerant, and its homogeneity just a coincidence or a result of lack of advertising. So I find it a little strange when a group is "congratulated" on its diversity.
Thank you for coherently and politely saying what others have said in... less eloquent terms. I think many people feel this way but find it difficult to express in these contexts without coming off as (or at least being accused of) a bigot or something.
My post above was a super-passive expression of this.
My post above was a super-passive expression of this.
> but I see no reason to think the diversity of background has any impact on technical contributions
Exactly this. The internet is the great equalizer. There is no need for anyone to know anything about me unless I choose to bring it up.
For a technical project, conducted and run over the internet, my work can stand entirely on its merits in a way that would not be possible in a regular office environment.
Exactly this. The internet is the great equalizer. There is no need for anyone to know anything about me unless I choose to bring it up.
For a technical project, conducted and run over the internet, my work can stand entirely on its merits in a way that would not be possible in a regular office environment.
Since you are prepared to make that argument, in what way will it benefit?
Does the color of my skin, my gender or my sexual orientation matter when providing feedback for a project such as this?
I would argue that those things are entirely irrelevant in this context, and wouldn't want them connected/associated with any contribution I made.
Does the color of my skin, my gender or my sexual orientation matter when providing feedback for a project such as this?
I would argue that those things are entirely irrelevant in this context, and wouldn't want them connected/associated with any contribution I made.
The general idea here is that when you are part of a majority, it's alarmingly easy to accidentally set up your community in such a way that makes those from a minority feel less welcome. It's a potential unknown-unknown. I assume the Rust community is trying to find out if this is the case.
Put another way, your skin color, sexual orientation, gender, etc. likely will not change your contribution. But if it turns out that people of a particular skin color, sexual orientation, gender, etc. are somehow disincentivized from contributing, that's a problem.
Put another way, your skin color, sexual orientation, gender, etc. likely will not change your contribution. But if it turns out that people of a particular skin color, sexual orientation, gender, etc. are somehow disincentivized from contributing, that's a problem.
Author here.
Hi all - thanks for the interest in the survey! The Rust community team is still working the blog post (this link was to an early draft), and we're looking forward to posting it when it's done.
Hi all - thanks for the interest in the survey! The Rust community team is still working the blog post (this link was to an early draft), and we're looking forward to posting it when it's done.
I think this survey was very poorly publicized. As somebody who only dabbles in Rust, this is the first I have heard of this survey. I am sure that others are in the same boat as I am. We would have participated, but we learned about it weeks after it closed!
Only now do I see the blog article, and a submission here [https://news.ycombinator.com/item?id=11661056] that got no traction. I don't remember seeing any sort of a notice on the main Rust web site.
The fact that many participants were excluded, albeit unintentionally, makes me really question the completeness, and hence the validity and usefulness, of this survey data.
Only now do I see the blog article, and a submission here [https://news.ycombinator.com/item?id=11661056] that got no traction. I don't remember seeing any sort of a notice on the main Rust web site.
The fact that many participants were excluded, albeit unintentionally, makes me really question the completeness, and hence the validity and usefulness, of this survey data.
This survey was publicized in all official channels including this week in rust, mentioned in the 1 year of rust announcement, on Hacker News (we cannot control traction), on the subreddit, the users forum, our Twitter account (where it also got huge traction) and literally all our other venues. We got a huge amount of replies.
I'm not sure how this is "poorly publicized".
I'm not sure how this is "poorly publicized".
Why was a link apparently not in the most obvious place, on the https://www.rust-lang.org/ web site? A small notice across the top would not have been disruptive, yet I and others would have seen it.
We put a great deal of effort into publicizing the survey, with a special focus on public spaces and piggybacking on highly-visible announcements. The website's front page sees less traffic than e.g. HN or the Rust subreddit, so it's not hard to imagine why nobody considered putting it there. It certainly wouldn't have hurt to have had it there, and I'm sure we'll consider putting it there for next year's survey, but we're quite happy with the several thousand respondents that we received.
According to the survey, ~16% of people experience breakage with minor upgrades. Isn't this a pretty serious violation of semver?
The Rust compiler has been very stable after 1.0. The issue lies in the ecosystem, and people is still figuring out the best design and/or solution for doing things, while occasionally breaking them. The biggest ecosystem breakage so far was termed "libcpocalypse", which was a massive hit for everyone (transitively) depending on libc crate for FFI. The proper resolution is still in under way [1].
[1] https://internals.rust-lang.org/t/solve-std-os-raw-c-void/32...
[1] https://internals.rust-lang.org/t/solve-std-os-raw-c-void/32...
This percentage includes people using explicitly unstable things (e.g. me).
I believe (but cannot verify) that these breakages were due to libraries breaking, especially libraries which evolve in lockstep with Rust internals like aster.
The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something unsound.
The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something unsound.
Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API? I feel like blaming the user isn't really going to help make the ecosystem more stable.
(Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number generation in the standard library.)
I of course understand that you folks are still working hard on it and it'll come in time; it's just that all other recent languages (Go, Ruby, Python, heck even the . Net and JVM ones) come with a large and usable standard library.
(Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number generation in the standard library.)
I of course understand that you folks are still working hard on it and it'll come in time; it's just that all other recent languages (Go, Ruby, Python, heck even the . Net and JVM ones) come with a large and usable standard library.
> isn't covering a large enough API?
A significant portion of nightly users are on it due to compiler plugins, even for libraries that work on stable, because it makes development a bit easier. Stabilizing those immediately would mean stabilizing compiler internals, which is a pretty huge drawback.
We have plans for addressing that specifically, as well as for the more general "libraries change" problems. They will come as part of an actual announcement, not a leaked first draft blog post :)
I came from languages where a big standard library was de rigeur (python, java), and I quite like rust's approach personally. For one thing, having RNG in the standard library would make it much harder with rusts stability guarantee to iterate on the API design in meaningful ways. For another, it's way easier to maintain external dependencies in a rust project than in others. Cargo is like night and day compared to pip, for example.
Yes, it's harder to iterate on API design once it's in the stable API. But that's the point, basically; it's harder to keep code working if the thing you're using keeps iterating.
And yeah, cargo is really nice. I just think the part where you have to go to it for all the things, with no direction on which alternative is (API- / crash-) stable, maintained, etc. is frustrating. That's the thing a standard library gives me - curation.
And yeah, cargo is really nice. I just think the part where you have to go to it for all the things, with no direction on which alternative is (API- / crash-) stable, maintained, etc. is frustrating. That's the thing a standard library gives me - curation.
I wasn't talking about the stdlib, I was talking about crates. Rust tries to keep its stdlib small so that crates can evolve on their own (and have alternatives). I think that's a valid choice, just because needing to fetch a crate for random numbers is different doesn't necessarily mean it is bad. It also means that the versioning can be different -- the URL library can make breaking changes if it wants with a major version bump, and that's okay.
Sometimes, a breaking change in the ecosystem is marked as a minor version bump, and sometimes you need to coordinate versioning across crates. This causes breaking changes for downstream users.
------
Most of the actual libs with unstable rust dependencies out there are compiler plugins. "Things depending on unstable internals" exist in many communities and Rust is no different. That doesn't necessarily mean these internals should be stabilized.
A big one is clippy, which I maintain. This lints code by hooking directly into compiler APIs, which will never be stable to the extent clippy needs them to be, since that would freeze compiler evolution. Similar tools for other languages either reimplement a mini-parser+typechecker internally, or hook directly into the compiler (gimple passes, etc). There is a solution being worked on for clippy specifically. For tooling/IDEs in general, the Rust compiler will eventually get an "oracle" API that can be queried for type information and whatnot (which probably won't have enough info for clippy to work, but will have enough for general IDE stuff)
Another big one is serde, the community serialization library. There is an official one that works pretty well, but serde is better. However, the serialization codegen is done by a plugin. It can also be done with a build script on stable, but this is a bit more unwieldy. Some libraries use the plugin instead of the build script, and often break.
There is work going on for a better procedural macro/metaprogramming interface too.
That is mostly the extent of things which depend on Rust unstable internals and are used widely. There are a few more things, but they are less used.
Sometimes, a breaking change in the ecosystem is marked as a minor version bump, and sometimes you need to coordinate versioning across crates. This causes breaking changes for downstream users.
------
Most of the actual libs with unstable rust dependencies out there are compiler plugins. "Things depending on unstable internals" exist in many communities and Rust is no different. That doesn't necessarily mean these internals should be stabilized.
A big one is clippy, which I maintain. This lints code by hooking directly into compiler APIs, which will never be stable to the extent clippy needs them to be, since that would freeze compiler evolution. Similar tools for other languages either reimplement a mini-parser+typechecker internally, or hook directly into the compiler (gimple passes, etc). There is a solution being worked on for clippy specifically. For tooling/IDEs in general, the Rust compiler will eventually get an "oracle" API that can be queried for type information and whatnot (which probably won't have enough info for clippy to work, but will have enough for general IDE stuff)
Another big one is serde, the community serialization library. There is an official one that works pretty well, but serde is better. However, the serialization codegen is done by a plugin. It can also be done with a build script on stable, but this is a bit more unwieldy. Some libraries use the plugin instead of the build script, and often break.
There is work going on for a better procedural macro/metaprogramming interface too.
That is mostly the extent of things which depend on Rust unstable internals and are used widely. There are a few more things, but they are less used.
Thanks for replying!
And my view is that having a smaller stdlib and pushing all the responsibility to crates means that the language isn't actually usefully stable, since it means downstream still can't depend on not having breaking changes of its dependencies. The URL library can make breaking changes and have a major version bump; but that means everybody ever that used a URL will need to deal with it, which can be annoying if you happen to be using a crate that does so half a dozen layers in. Saying that a library is broken because its dependencies changed shifts the blame but that doesn't actually help the end developer. I totally understand though; that's more of an artifact of having a young language. I just still find it frustrating.
As for unstable compiler plugins: sure, it's looking at dirty compiler internals and whatnot. But that means people are using non-release compilers, and makes it more likely to start using the same in their code. The same could have been achieved by having a compiler version (completely separate from the language version, sort of like how GCC version numbers are decoupled from the C language); instead, we've got instructions lying around encouraging people to use unreleased toolchains.
I guess I really just want a stable, battery-included thing to build on top of, but while Rust is exciting it isn't quite there yet. Really thankful for the Rust team (and friends) for working on all this and letting us have a look, though, and looking forward to the day the ecosystem gets there :)
And my view is that having a smaller stdlib and pushing all the responsibility to crates means that the language isn't actually usefully stable, since it means downstream still can't depend on not having breaking changes of its dependencies. The URL library can make breaking changes and have a major version bump; but that means everybody ever that used a URL will need to deal with it, which can be annoying if you happen to be using a crate that does so half a dozen layers in. Saying that a library is broken because its dependencies changed shifts the blame but that doesn't actually help the end developer. I totally understand though; that's more of an artifact of having a young language. I just still find it frustrating.
As for unstable compiler plugins: sure, it's looking at dirty compiler internals and whatnot. But that means people are using non-release compilers, and makes it more likely to start using the same in their code. The same could have been achieved by having a compiler version (completely separate from the language version, sort of like how GCC version numbers are decoupled from the C language); instead, we've got instructions lying around encouraging people to use unreleased toolchains.
I guess I really just want a stable, battery-included thing to build on top of, but while Rust is exciting it isn't quite there yet. Really thankful for the Rust team (and friends) for working on all this and letting us have a look, though, and looking forward to the day the ecosystem gets there :)
> Sometimes, a breaking change in the ecosystem is marked as a minor version bump,
To be clear, you're saying moving from 0.x.y to 0.(x+1).z is valid to be a breaking change, right?
(For other readers, Rust/Cargo uses a---more useful---variant of SemVer where an upgrade from one version to another from assumed to work if the most-significant non-zero numbers are identical, whereas SemVer says that any version number change pre-1.0 could be a breaking change, even 0.1.0 to 0.1.1.)
(For other readers, Rust/Cargo uses a---more useful---variant of SemVer where an upgrade from one version to another from assumed to work if the most-significant non-zero numbers are identical, whereas SemVer says that any version number change pre-1.0 could be a breaking change, even 0.1.0 to 0.1.1.)
Semver says that for x.y.z, x == 0 means no guarantees about anything. Cargo currently treats x == 0 as the same as x == 1.
I disagree that this is more useful, personally, for exactly this reason.
I disagree that this is more useful, personally, for exactly this reason.
Hm, I'm interested to hear why you think 0.1.0 -> 0.1.1 being considered just as dangerous as 0.1.0 -> 0.2.0 is more useful than treating 0.1.0 -> 0.1.1 as "semver-safe" and having only 0.1.0 -> 0.2.0 be breaking.
I don't know the details in rust's case, but I wouldn't consider it a violation of semver if the code which broke in a minor update was doing bad things (maybe accidentally exploiting a bug or limitation in the language or implementation, probably by violating some requirement that wasn't checked properly, etc) and simply couldn't be correct code if left alone.
How do you define a "bad thing"? The semver spec is quite clear about "even the tiniest backwards incompatible changes" (http://semver.org/#if-even-the-tiniest-backwards-incompatibl...) requiring a major version bump.
Rust has its own definition of what it defines to be stable. Soundness fixes and bug fixes do not count, though as much as possible they will try to fix them in a way that breaks very little.
http://blog.rust-lang.org/2014/10/30/Stability.html
http://blog.rust-lang.org/2014/10/30/Stability.html
Semver does not define what a "compatible" vs "incompatible" change means, though. Manish linked to how we define it, but SemVer specifically leaves that up to the project.
It may not be considered a backwards incompatible change to rust if it no longer compiles invalid code.
If the code never worked correctly, but silently compiled, one would think a breaking change was welcomed.
If the code never worked correctly, but silently compiled, one would think a breaking change was welcomed.
Cargo does not (yet) ensure that the library maintainer did follow the semver's doctrine.
But there are people working on it.
https://github.com/semantic-rs
https://github.com/semantic-rs
48.8% of Rust users use nightly, 23 percentage points among them use both stable and nightly, which means 25.8% of Rust users use only nightly.
Is it just me or does that seem exceedingly high? I'm guessing that a good deal of them are Rust language/core lib developers?
Is it just me or does that seem exceedingly high? I'm guessing that a good deal of them are Rust language/core lib developers?
I personnally use nightly without being a core dev, because Rust is not available in Debian Stable so I just compile it from Git.
Also a factor is that there are very useful libraries that either can only be used in nightly, or are more ergonomic to use in nightly. Usually because they rely on compiler internals or unstable language features. This is mentioned as one of the points under "Challenges for Rust".
I use nightly for osdev. No other option.
This link is asking for a login. Is there anywhere one can read the results without creating an account?
This was a draft blog post intended for review which was posted on HN, and has been made private for now.
Wow, ~180 people with projects more than 100000 lines.
All / most of them are likely Servo contributors.
Servo: https://servo.org/
Servo: https://servo.org/
100k may seem like a lot, but if I do the sum of all lines of codes (exluding blank lines and comments) of the Rust projects where I'm the only contributor (or where other contributors are minor) I'm at around 61k lines of code.
Lines of code go up quicker than you think.
Lines of code go up quicker than you think.
How come there are as many women (47) answering this survey as trans people? Is there anything in the Rust community that is hostile to women but not trans people?
In fact trans people appear to be over-represented in this survey as 1.7% of people in it were trans compared to optimistic 0.3% of the US being transgender [0]
[0] https://www.quora.com/What-percentage-of-the-US-population-i...
In fact trans people appear to be over-represented in this survey as 1.7% of people in it were trans compared to optimistic 0.3% of the US being transgender [0]
[0] https://www.quora.com/What-percentage-of-the-US-population-i...
Most female devs I know are trans women. So maybe they are over-represented in the dev-world in general?
Hostile may be jumping to conclusions. It's a small number, and it's a self-selected sample. Small change in any of the numbers will result in big ratio change. Unless someone actually claims hostile behaviour, why expect it?
Either way, the trans population is very much overrepresented in the survey. You took one of the sources from the link which claims 0.3%. The next source which I would trust (DSM-5 stats) claims 0.005-0.014% natal male and 0.002-0.003% natal female for gender dysphoria.
Either way, the trans population is very much overrepresented in the survey. You took one of the sources from the link which claims 0.3%. The next source which I would trust (DSM-5 stats) claims 0.005-0.014% natal male and 0.002-0.003% natal female for gender dysphoria.
The reason I said hostile is that in most discussions on Hacker News and Reddit a lot of people argue that the only reason women are so under-represented in tech is that all the guys are very hostile to women. This survey goes against that. For some reason they refuse to believe that some things are more interesting to women than men and vice versa.
> For some reason they refuse to believe that some things are more interesting to women than men and vice versa.
It could be that this is just as wrong as the "only hostility is the problem". Not everybody sees the same barriers. Not everyone faces the same challenges. We don't even know if/what's more interesting, because we're bombarded with ideas of what should be more interesting since very young age. Software engineers I know successfully raise girl geeks for example.
It could be that this is just as wrong as the "only hostility is the problem". Not everybody sees the same barriers. Not everyone faces the same challenges. We don't even know if/what's more interesting, because we're bombarded with ideas of what should be more interesting since very young age. Software engineers I know successfully raise girl geeks for example.
In different cultures (e.g. Russia), and different time periods (e.g. the 80's), the level of interest and participation from women is/was much, much higher. I would say that's a pretty objective reason for believing that it's cultural and not biological.
What I find hard to believe is that some people don't think that women get treated differently than men, or that that wouldn't matter when it comes to people choosing to participate in certain communities.
What I find hard to believe is that some people don't think that women get treated differently than men, or that that wouldn't matter when it comes to people choosing to participate in certain communities.
To author: would it be possible to improve the bar graphs, so that they were sorted by value, not by label? I believe it would make reading them much easier, and make them more informative [or, "deobfuscate" them]. (I mean those like "editors", etc., not "how long I know Rust" where the labels introduce sensible order.)
The link is now locked. Can we replace it with something interesting? Or a cached copy?
There will be some kind of actual communication of this data at some point, quite possibly on the official Rust blog. This was a rough draft of the post that was leaked.
Yes, put something interesting in its place please, rust-related.
We've closed this thread to new accounts because new accounts have taken it into the weeds of angry troll war.
Is it just me or the doc requires permission?
Do consider all numbers undiscussed and not cleaned up for flaws (we'll document the cleanups and the reasonings).
-- Florian // rust-community team