Hacker News Reader

Comment by erickt | Hacker News Reader

Rust Community Team lead here.

It is fine if people don't consider themselves underrepresented, we just want to be proactive about discovering if people end up self selecting themselves out of our community because they don't feel welcome. Furthermore, we are starting some initiatives to focus growing a diverse group of participants (https://github.com/rust-community/RustBridge), and so we need some baselines to see if we are successful or not.

We did have a number of categories that people could select from. Our plan for next year is to identify groups from the free text for next year. We are tracking our improvement plans here: https://github.com/rust-community/team/issues/28

View on HN

> we just want to be proactive about discovering if people end up self selecting themselves out of our community because they don't feel welcome.

Why not simply ask the question directly? "Do you feel welcome in the Rust community?"

For those that respond "no, I don't feel welcome", it might be interesting to also ask why, and to see if that correlates with demographics.

That's a reasonable question! I put that on our list for the next survey: https://github.com/rust-community/team/issues/28#issuecommen...

I quit doing the survey when I read the color question.

If you had worded it something like, 'do you feel welcome' I would have answered (yes) and kept going.

I'm a minority who is often "not represented" in things, and that's neither good nor bad - it's simply neutral.

The idea of "representation" is rather silly and I'm always amused by how otherwise extremely intelligent software engineers completely throw out their scientific rigor when it comes to political issues and diversity. There's simply no evidence that deliberately assured diversity has any inherent value to a software project (or any kind of project).

And this is before bringing up the can of worms that is social engineering. The nanosecond in which you introduce deliberate manipulation of what would otherwise be organically formed groups, you unrealizingly cross a line into the slippery slope of what's OK or not OK for you to manipulate, resulting in a relativistic argumentation spiral to authoritarian behavior.

got it - sounds like I probably misunderstood the motivation which appears to have been less about demographics than about under-representation identification. Kudos on the whole survey and this particular section, my nitpick aside, I find the whole thing highly interesting and am personally impressed by your desire to know your user base in this way. Not a Rust user yet as I am a scientific programmer and on the exploratory side I really need a REPL, but I will make an effort to look at Rust for the parallel side of our production code.

Yeah, we iterated a bunch on this question, and I still don't think we have it quite right.

On the REPL side, we've had a few prototyped out [1] out over the years. We'd love something someday. What do you use for your scientific computing? We are also have some projects that are trying to ease using Rust with other languages ([2], [3]), so knowing what we should priorities would help.

[1]: https://github.com/murarth/rusti

[2]: https://github.com/rustbridge/helix

[3]: https://github.com/rustbridge/neon

Python (Numpy/Pandas really) is our go to for all the usual reasons on exploratory with some R (but R is becoming too slow for our growing data sets). What we're really missing is a language that does parallel computing, not necessarily only SIMD (Cuda style), but something that can also be more flexible on algorithms which have step dependencies. Scala/Spark works here, but it's more about big business batch data in our view, whereas we are about big non-linear optimizations in finance (fixed income curve fitting on huge numbers of bonds), and a further requirement for soft real time. We're very very excited about the Knight's Landing Xeon Phi, which will, we think, give us good performance on SIMD, and much more algorithmic flexibility because it can also be treated as a 288-core Xeon (hopefully). I think Rust could be a very good fit here because I predict that these "mega-core" chips will become very important. We can tolerate very little latency between processes so we basically cannot go multi-node too easily. We are also relatively small so don't have super-computer budgets.

Reply on news.ycombinator.com