Hacker News Reader

Comment by vegabook | Hacker News Reader

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.

View on HN

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