Aaron Turon Tech | Personal | Academic | Music | About Project maintained by aturon Hosted on GitHub Pages — Theme by mattgraham

Rust and its ecosystem is developed by a diverse mix of staff (from a variety of companies) and volunteers, from all over the world and with a range of circumstances. And “developed” goes far beyond code, to include documentation, podcasts, community work, and more.

People and companies often ask how they can give back to the community and sponsor important work in the Rust world. I think the best approach is to provide direct “match-making” between sponsors and people doing valuable work, making it possible for sponsors to direct their funds and making the individuals more visible.

This page is a first attempt at facilitating sponsorship. This is not an officially endorsed list, but it is a list of Rustaceans that I have personally vetted and sponsored, and encourage you to support. Each of them has a long, public history of impactful work in the community.

Use the Patreon links to sponsor individuals, contact them directly for contract work, or write me at aturon@mozilla.com to find another arrangement.

If you’re interested in being vetted for this list, please reach out.

Leonardo Yvens (@leodasvacas)

Interests: rustc (trait system), community work

Patreon

GitHub, email

Open to direct contract work

Details

Chalk: I’m up for just about anything anything involving rustc, though something related to type checking and chalk **might be the best use of my previous experience.

I’m up for just about anything anything involving rustc, though something related to type checking and chalk **might be the best use of my previous experience. Coercions : I’m particularly interested in the interaction between coercions and type checking . The holy grail here would be to have type checking be smarter around method calls and better transitive coercions. This would be implemented by leveraging chalk.

: I’m particularly interested in the interaction between . The holy grail here would be to have type checking be smarter around method calls and better transitive coercions. This would be implemented by leveraging chalk. Type parameter defaults : I have an interest in the stalled type parameter defaults feature and would like to work on a new RFC and implementation for it’s interaction with inference.

: I have an interest in the stalled feature and would like to work on a new RFC and implementation for it’s interaction with inference. Community work: Giving more talks and workshops and helping the Brazilian and Latin America community organize more Rust events.

Aleksey Kladov (@matklad)

Interests: IDEs, Cargo, rustc

Patreon

GitHub, email

Open to direct contract work

Details

RLS : as an original developer of the Rust plugin for JetBrains IDEs, I have a deep understanding of challenges and specifics of a good IDE backend. While I believe that writing a Rust compiler frontend from scratch in Kotlin was the best choice for IntelliJ, it is also important that the official Rust toolchain has all important IDE features as well. I’ve made a few contributions to RLS so far, because I was busy with IntelliJ Rust, but now I want to transfer more of my experience to this project.

: as an original developer of the Rust plugin for JetBrains IDEs, I have a deep understanding of challenges and specifics of a good IDE backend. While I believe that writing a Rust compiler frontend from scratch in Kotlin was the best choice for IntelliJ, it is also important that the official Rust toolchain has all important IDE features as well. I’ve made a few contributions to RLS so far, because I was busy with IntelliJ Rust, but now I want to transfer more of my experience to this project. Making rustc a better fit for IDEs: there are big differences in how command line compiler and IDE should process code for the best user experience. Incremental on-demand compilation is a great step towards making rustc more suited for IDEs, but there are more things that should be done. In particular, I would like to lay a solid foundation for IDEs by starting from the lowest level – lexer and parser. The plan is outlined in the libsyntax2 RFC.

a better fit for IDEs: there are big differences in how command line compiler and IDE should process code for the best user experience. Incremental on-demand compilation is a great step towards making more suited for IDEs, but there are more things that should be done. In particular, I would like to lay a solid foundation for IDEs by starting from the lowest level – lexer and parser. The plan is outlined in the libsyntax2 RFC. Cargo: I’ve working on Cargo for a long time. Apart from the usual maintenance work, I am especially interested in integration with IDEs and build systems.

Grey Mitchell (@QuietMisdreavus)

Interests: rustdoc, documentation

Details

Rustdoc . As the current lead of the Rustdoc Team, I help organize contributions to the official documentation tool of Rust. I’ve made multiple contributions to various areas of rustdoc, from the appearance of code on the final page to the base of how it collects data from the compiler.

. As the current lead of the Rustdoc Team, I help organize contributions to the official documentation tool of Rust. I’ve made multiple contributions to various areas of rustdoc, from the appearance of code on the final page to the base of how it collects data from the compiler. Documentation. In my own crates and in my work on rustdoc, I’ve always wanted to improve the state of documentation in the Rust community. I’ve written guides to using a crate, to using specific rustdoc features, and to the internals of rustdoc itself. With access to information about the use of a feature or library, I can help extend and improve its docs.

Igor Matuszewski (@Xanewok)

Patreon

GitHub, email

Open to direct contract work

Details

RLS . As a member of Rust IDEs and editors team, I mostly hack on the RLS, the core Rust IDE tool. In addition to helping maintain the project, my work mostly revolved around supporting Cargo workspaces in the RLS and bringing other quality-of-life improvements. However, there’s still much to do, most importantly implementing compiler-suggested code completion, improving macro support or integration with other build systems.

. As a member of Rust IDEs and editors team, I mostly hack on the RLS, the core Rust IDE tool. In addition to helping maintain the project, my work mostly revolved around supporting Cargo workspaces in the RLS and bringing other quality-of-life improvements. However, there’s still much to do, most importantly implementing compiler-suggested code completion, improving macro support or integration with other build systems. Tooling. In addition to RLS itself, I also worked on few tooling-related features when working on the RLS. It mostly consisted of improving interop between RLS and other tools, including the Rust compiler. I’d like to continue working on other tooling-related issues, such as improving the build plan integration in Cargo and RLS or helping with the planned rustup/Cargo refactor.

Stjepan Glavina (@stjepang)

Interests: crossbeam, all things Rust concurrency

Patreon

GitHub, email

Open to direct contract work

Details

Epoch-based GC . This garbage collection mechanism in Crossbeam works quite well already, but its performance can still be improved. The interface is at the moment not very easy to use and could use additional design work.

. This garbage collection mechanism in Crossbeam works quite well already, but its performance can still be improved. The interface is at the moment not very easy to use and could use additional design work. Hazard pointers. This is another popular garbage collection mechanism with different tradeoffs. It’s generally a better choice for working with concurrently modified single objects, while epoch-based GC is faster for traversing graphs of objects. Hazard pointers are an important prerequisite for implementing a primitive similar to AtomicReference in Rust.

This is another popular garbage collection mechanism with different tradeoffs. It’s generally a better choice for working with concurrently modified single objects, while epoch-based GC is faster for traversing graphs of objects. Hazard pointers are an important prerequisite for implementing a primitive similar to AtomicReference in Rust. Atomic primitives . Building a set of atomic primitives in Rust. We do have std::sync::atomic, but it’s somewhat basic and unergonomic. I’m interested in creating AtomicBox and AtomicArc, which would be akin to std::atomic_shared_ptr in C++ or AtomicReference in Java. Another new primitive might be scalable counters like LongAdder in Java.

. Building a set of atomic primitives in Rust. We do have std::sync::atomic, but it’s somewhat basic and unergonomic. I’m interested in creating AtomicBox and AtomicArc, which would be akin to std::atomic_shared_ptr in C++ or AtomicReference in Java. Another new primitive might be scalable counters like LongAdder in Java. Channels and queues . Working on crossbeam-channel has given me the idea to create a coherent set of concurrent queues with different kinds of tradeoffs. In Java, those would be ArrayBlockingQueue, ConcurrentLinkedQueue, LinkedBlockingQueue, and several others.

. Working on crossbeam-channel has given me the idea to create a coherent set of concurrent queues with different kinds of tradeoffs. In Java, those would be ArrayBlockingQueue, ConcurrentLinkedQueue, LinkedBlockingQueue, and several others. Improving parallel sorts . In Rayon, par_sort_unstable uses a parallel pattern-defeating quicksort, but it doesn’t scale as well as it could because the partitioning phase is still sequential. IPS4O is a state-of-the-art parallel in-place sorting algorithm and would be the perfect fit here.

. In Rayon, par_sort_unstable uses a parallel pattern-defeating quicksort, but it doesn’t scale as well as it could because the partitioning phase is still sequential. IPS4O is a state-of-the-art parallel in-place sorting algorithm and would be the perfect fit here. Concurrent data structures. I’m interested in building these kinds of data structures in general. This is still a largely unexplored area of research and engineering, and I believe Rust has unique properties (ownership system, data race freedom, doesn’t rely on GC) that could push this area forward.

Jorge Aparicio (@japaric)

Interests: Rust on embedded devices

Details

I want Rust to become a major player in the field of embedded systems as I believe it holds so much potential to improve the status quo. To that effect, I have been doing a bunch of groundwork in this area. Here’s some of my recent work:

But there’s still lots of ecosystem and tooling work to do! Among my ongoing work you’ll find:

Pushing embedded Rust on stable over the finish line.

Embedded Rust documentation: writing the embedded Rust book, finishing the embedonomicon, updating the Discovery book

Expanding the members of the rust-embedded org to have more people maintain the embedded Rust / Cortex-M ecosystem

Making the Real Time for The Masses framework work in a future stable release

Chris Krycho (@chriskrycho)

Interests: New Rustacean podcast

Details

A show by @chriskrycho about learning @RustLang. Technical—but approachable! Topical deep dives, interviews, crate overviews, and more.

Matthias Endler (@mre)

Interests: Hello Rust! live-coding show

Details

A live-coding show about Rust, targeted towards intermediate Rust programmers who have already read the Rust book and want to learn advanced patterns and tricks as well as how to write ergonomic code in Rust.

Peter Atashian (@retep998)

Interests: winapi

Patreon

GitHub

Open to direct contract work

Details

The winapi crate provides raw FFI bindings to all of Windows API. They are gathered by hand using the Windows 10 SDK from Microsoft

Pierre Krieger (@tomaka)

Interests: graphics APIs, audio APIs, Android packaging

Details

Vulkano (~45k lines of code) is a safe wrapper around the Vulkan API. It is a low-level brick that allows you to interact with your GPU and execute graphical or compute (GPGPU) operations. Vulkano aims to be very explicit and predictable especially if you are familiar with the Vulkan API, but at the same time provide some high-level functionnalities. Ideal for building a game, a game engine, or a GPGPU application when performances and explicitness matter.

Glium (~33k lines of code, unmaintained) is a safe wrapper around OpenGL and OpenGL ES. It aims to provide an easy-to-use high-level API while still remaining predictable and not hiding what it does. Even though many people have liked glium, its main goal of being safe was determined to be too difficult because of the many problems with OpenGL itself.

Android-rs-glue allows you to easily turn your Rust code into an Android package. After installing the Android SDK and NDK, run the cargo apk command and you will get an .apk file which you can then install on your device. Works out of the box with vulkano, glium, winit and glutin. Also provides a docker image.

Winit (~10k lines of code) is a cross-platform window creation library. It allows you to create a basic window on Windows, Linux, MacOS and Android, then lets you handle the events received by this window. In order to show something on the window, you are supposed to create an OpenGL, Vulkan, or DirectX context on top of it, but this is not covered by winit itself.

Glutin (~7k lines of code) does the same as winit, but creates an OpenGL context in a cross-platform way on top of the window. The servo project from Mozilla uses a fork of glutin for its own windowing.

(more projects detailed in the Patreon page)