Results of Rust Survey 2016 – early draft for internal usage
docs.google.com
docs.google.com
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.)
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.
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.
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.
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.
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".
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.
> 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 :)
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.
> Sometimes, a breaking change in the ecosystem is marked as a minor version bump,
(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?
Servo: https://servo.org/
Lines of code go up quicker than you think.
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.