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.
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.
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).
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)
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?
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.
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.
"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.
> I believe it's a holdover from a time when it was entirely acceptable to be dismissive of half the race.
Ironically, when it was entirely acceptable to be dismissive of half the race, separate words were used - explicitly calling out a difference between groups. 'Guys' as a gender neutral term is a relatively recent phenomenon, and in many ways is an equalizing term.
> As such, it's probably appropriate to be at least a little sensitive to the topic
Alternatively you could argue that it's appropriate not to be over-sensitive to common, and innocent, language usage.
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.
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 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 :)
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'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.
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!
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.)
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.
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.
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?
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.
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.
> 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.
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.
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"?
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.
Yes, minority is geographical, yet somehow it's come to mean not white male, a western view point. Not sure how female keeps getting classified as minority.
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]
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
We stabilize lots of stuff every release, but we also don't want to stabilize things that aren't ready. Once we do, we're stuck with that interface forever.
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.
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.
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.)
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.
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 :)
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].
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".
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.)
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.
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.)
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.
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.
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.
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.
112 comments
[ 3.1 ms ] story [ 192 ms ] threadServo: https://servo.org/
http://www.redox-os.org/
Lines of code go up quicker than you think.
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.
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).
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've not heard this before. Citation?
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
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.
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?
1: http://english.stackexchange.com/questions/11816/is-guy-gend...
Ironically, when it was entirely acceptable to be dismissive of half the race, separate words were used - explicitly calling out a difference between groups. 'Guys' as a gender neutral term is a relatively recent phenomenon, and in many ways is an equalizing term.
> As such, it's probably appropriate to be at least a little sensitive to the topic
Alternatively you could argue that it's appropriate not to be over-sensitive to common, and innocent, language usage.
> 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.
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 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'm really liking everything I'm seeing in Rust so far.
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.
May I ask what you were doing in PHP that you do now in Rust?
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 :)
Have you been writing too many try/catch statements?
(If anyone knows about numbers along those lines, I'd love to hear about it.)
Stop trying to insert your identity politics into everything. Let's just leave a few pure things in this world, please.
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.
So where were you when Brendan Eich got canned?
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.
My post above was a super-passive expression of this.
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.
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.
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.
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...
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.
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.
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.
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.
Also maybe because rust and vim appeal to the same argument of "performance/only come with the stuff you need"
(I'm a vimmer myself, but that is what I hear other people complain about)
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.
https://github.com/semantic-rs
http://blog.rust-lang.org/2014/10/30/Stability.html
If the code never worked correctly, but silently compiled, one would think a breaking change was welcomed.
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.
(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.
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 :)
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.
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.
(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.)
I disagree that this is more useful, personally, for exactly this reason.
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 :)
[1] https://internals.rust-lang.org/t/solve-std-os-raw-c-void/32...
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?
Do consider all numbers undiscussed and not cleaned up for flaws (we'll document the cleanups and the reasonings).
-- Florian // rust-community team
(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.)
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.
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.
I'm not sure how this is "poorly publicized".