This is a recap of the FOSDEM 2017 Rust BoF session.
#Who:
I counted about 90 people (7 rows of 8 people with 30 people standing around the sides).
Given a show of hands:
- ~1/2 had never seen or programmed Rust.
- ~1/2 had programmed Rust.
- ~1/5 1/5 had published a crate.
- ~1/18 has written a scientific paper using Rust.
#We discussed:
##What is Rust?
Luca Barata (libav, VLC) treated us to a quick overview of Rust for new people.
Rust on the metal
There was a spirited discussion about the promise of Rust in the embedded sphere. Dimitar initially appeared skeptical of Rust's promise as an embedded language since he had the impression that it was for embedded Linux only and not for running on bare metal. @SimonSapin explained that he had done some work on ARM chips with no OS, but still going through existing C code (because rewriting the C code is boring and doesn't yield any particular benefit if the code works).
Question
Question: Can you use dlopen when you use musl?
Answer: If you statically link, no. If you dynamically link, yes. There is some work to be able to do both but it sounded confusing to my brain.
Multimedia
Marc Antoine and Luca Barata discussed their experience with Rust as a language for multimedia development. Marc was interested in image processing while Luca is more into audio and video. Were there bindings to OpenCL? Yes. Are there bindings to SIMD primitives? Yes. Are they in stable Rust? No. Should anyone rely on autovectorization in LLVM to get SIMD code? No.
A fellow at the back who seemed to be a dab hand at Haskell and embedded systems (an interesting combination!) suggested that Rust gets some SPMD since shoveling data to the GPU and back can be tricky; so just use all your cores(!). I don't really know what kind of solution is envisioned here. Maybe something like OpenMP? Maybe someone could/should have mentioned Rayon and/or crossbeam.
Playing nice with other languages
There was further discussion about bindings from other languages. I get the impression that a lot of people use Ruby, Python, or Node and sometimes need to squeeze more performance out of certain bits of code. The following projects were mentioned:
###Wrapping/working with C:
- bindgen - generated the -sys crate from C code.
-
rusty-cheddar - generate C headers from Rust
#[no_mangle]functions. (basically the opposite of bindgen) - corrode - Jamey Sharp was in the group and plugged Corrode.
###Extending higher level languages:
- neon - Native Node extensions in Rust.
- helix - Write Ruby classes in Rust.
- ruru - Native Ruby extensions in Rust.
-
cffi - Native python extensions using C ABI.
- upside: easy and straightforward and many people know how to do this. Works across python 2., 3., pypy
- downside: you need to describe your interface in C types which could be a source or error. (rusty-cheddar seems like a good tag team partner here)
-
rust-python - Python binding which links directly to libpython
- upside: links to libpython if you need that. All in Rust so it catches errors.
- downside: needs to link to python2 or python3 specifically. Sometimes difficult managing PyObject and Rust lifetimes.
Community
Dario urged people to get involved in https://hashnode.com which is like StackOverflow but for technical opinions. His feeling was that the Rust community should evangelize Rust more on this site and similar sites.
We also discussed how to help move people from 'my first program' to 'my first crate'. Someone had asked to talk about getting code reviews and tips on what to look for when publishing a crate.
- Ask on https://users.rust-lang.org for a review; people seem to do it and people have had very positive experiences with it. But it's not a managed process so it might not be reliable/scaleable/measured/improved.
- IIRC Luca Bruno (Debian packager for Rust) suggested some kind of mentor system.
- I suggested making a community-wide highfive bot but I think I just misunderstand highfive's purpose. I thought something could prod a mentor to take a look at the code.
- People are very happy with Clippy.
- Our embedded+haskell friend suggested that people don't get too monoculture with the style as it's something he didn't like about the Haskell community - though it's somewhat required in the Haskell if you want some hope of getting performant code.
@grummfy (twitter) would like to start a Rust User Group for Belgium. Sounds like a good idea to me!
Package signing
Someone in the room asked if any core developers were in the room who could vouch for the public keys for Rust to be certain that it was the correct code. No core developers were there who could do that. This began a short discussion about the desire for package signing on crates.io.
Conclusion
Thanks to everyone for showing up and putting up with my inability to speak loudly (I had lost my voice on Friday). Thankfully, when the ball started rolling I didn't have to talk much.
I thought that the group was polite and thoughtful. In the beginning it seemed like only a few people wanted to talk but then people warmed up to the discussion and I saw more and more hands going up from people who were speaking for the first time. I wish we had more time to keep the discussion going, but I think an hour is a good stopping point.
After the discussion in the room, people went into the hallway into groups and it seemed like a breakout session where people were in clusters talking with others about the topics they were interested in. So that seemed to work well.
Further work
At the end I asked if we should try to make a devroom track next year. There was a unanimous agreement by show of hands. Asking about various topics, it seemed that some were interested in web development and desktop, but what surprised me was how many embedded developers were interested in Rust. People also said they were very interested to hear tooling, ecosystem, and language talks.
I am normally involved in the HPC, Big Data, and Data Science devroom (which was also a big success; maybe too big...) so I don't imagine FOSDEM will take too kindly of me trying to get two devrooms in. I can't guarantee that I will be able to be involved much. I'd like to continue helping to facilitate the community but I don't think I can run the devroom. If you're interested in doing it, @josh would like to help, and @lucab suggested that CoreOS is happy to contribute in some ways.
##Postscript
I tried to write this from memory and my poor notes and a picture of the board I took when everyone left. I tried to describe the interaction I saw but if I misrepresented or misattributed your comments or questions, please let me know.