shea's blog

The Rust programming language is a self-declared “systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.” Its impl period is a sort of seasonal community Rust project, or organization of projects. To paraphrase Aaron Turon, it is a time for the Rust community to come together to focus on implementation work rather than design/RFC work.

I’ve been lucky enough to have had the opportunity to learn Rust in order to write it over the last year or so at PolySync. PolySync is a friend of Rust and we’ve been moving from using Rust to favoring it. My experience with the language at work drove me to explore the ecosystem independently and to eventually write Rust for myself, outside of work. I’m happy about a recently published crate bnf (a library for parsing Backus–Naur form context-free grammars) and really satisfied with my experience participating in the impl period.

A quickchecking crate

My part in Rust’s the impl period project was work for bindgen, a tool that makes life better for Rust developers that need to use C or C++ by automatically generating bindings to existing libraries. It’s something I’d used in the past for exactly that, writing Rust code that interfaces with existing C. It did everything it promised and I’m incredibly glad it’s in the ecosystem.

Though not directly affecting any of bindgen’s functionality, the quickchecking crate was written to tackle the Add property based testing with quickcheck issue and will hopefully help contribute to its growth. Some of the power of property testing might be boiled down to its efficiency in testing an exhaustive set of inputs. One property test has the potential to exercise what in other paradigms, often requires an impractical or even impossible number of individual tests. quickcheck is a Rust package that enables writing property tests (in the vein of the original QuickCheck written in Haskell) for Rust projects.

My contributions were captured by the following pull requests made to the rust-lang-nursery/rust-bindgen GitHub repository:

• Property testing with quickcheck
• Quickchecking crate CLI
• Enable Cargo features for quickchecking crate

I count my experience as a success. Mostly because three PRs were merged and the corresponding issues closed and little bit because the crate was noticed by @steveklabnik (who does a pretty damn good job summing up its function, “bindgen uses quickcheck to generate random c header files and then tries to parse them”.).

bindgen uses quickcheck to generate random c header files and then tries to parse them https://t.co/HYftqPra7L

— Some(@steveklabnik) (@steveklabnik) December 8, 2017

Check this gist for a peek into what a couple randomly generated C headers look like.

While unable to meet the goal of uncovering “many hidden issues via fuzzing”, the quickchecking crate caught one new bug and is able to regularly catch a couple others, #550 and #684. To me that shortcoming means a couple things. One, there’s still room to improve the crate by generating a broader range of viable code and by support for whitelisting and opaque types. Two, bindgen is already doing a great job at doing a lot of things right.

The impl period experience

Because I do count the experience a success, it’s worth noting a couple things that went right that may be out of the ordinary.

• I live in Portland, OR where the sponsor of the Rust project Mozilla has a presence.

• There was an impl period Meetup nearby where I was able to pick @fitzgen’s brain in person, the impl period’s bindgen project lead.

It’s also worth noting the things that I expect apply more generally.

• The presence of a Gitter channel influenced the decision to contribute. While I didn’t actually use it much, it allowed me to wave, say hi and get a wave back. It was some human interaction that helped reinforce that my work would be seen and that if I did need something, it would be there.

• I loved the newsletters.

• My engagement with the Rust community was enormously positive.

• The impl period documentation was really, really great. The volume of it all was a bit daunting at first but ended up allowing me to browse until something felt right. I was able to settle on a problem that sounded interesting and represented a chance to learn.

• When I took on the project it was with a clear idea of how to tackle it and that clear idea was completely misguided. Mapping out a new solution and implementing it really scratched the itch.

Participating was a fantastic experience, I hope the impl period is an every year thing. It provided a feeling of genuinely leveling up as a Rust developer, in some part because it was a new problem to solve but largely because of the incredibly thorough and thoughtful feedback from @fitzgen who reviewed my PRs.

For more info on implementation details I’ll probably do a follow up post, but in the meantime, if you’re interested in knowing more about it check out the conversations in the PRs linked to above or reach out on Twitter, I’m @shnewto.

I’d like to offer a really enthusiastic thank you to the Rust community and everyone involved in organizing and running the impl period for 2017. I’m glad for the experience and look forward to engaging more.

Also, a huge thanks to @craftloopz for working with me through the drafts of this post. She’s an amazing editor and helped me shape something I’m glad to share.