| layout | title |
|---|---|
default |
Sponsor work on Rust! |
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 [email protected] to find another arrangement.
If you're interested in being vetted for this list, please reach out.
- 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.
- 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.
- 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.
- Community work: Giving more talks and workshops and helping the Brazilian and Latin America community organize more Rust events.
- 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.
- Making
rustca 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 makingrustcmore 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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:
- Lead of the embedded devices WG. This WG is an official part of the Rust project and we are working towards making embedded Rust a first class citizen. Check our goals for the 2018 edition.
- Embedded Rust on stable
- Xargo, a Cargo wrapper for
no-stddevelopment. Used for embedded, OS and game development! Notable users: Baidu, Chucklefish and Redox OS. - Cross, a Cargo wrapper that eases cross compiling Rust programs to tons of different architectures (ARM, MIPS, PowerPC, System Z, etc.). Used by Microsoft in their Azure IoT Edge project build system.
svd2rust, a Rust code generator that produces an API to access a device's peripherals from SVD files.- A bunch of
no_stdcrates:cortex-mfor access to common Cortex-M functionality, device crates like thestm32f30x, Board Support Package (BSP) crates like thef3and miscellaneousno-stdcrates likefpafor fast Fixed Point Arithmetic. - Compiler hacking:
-Z linker-flavor,#[used], MSP430 support, llvm-tools component, etc. - The Discovery book, a beginner friendly text about programming microcontrollers in Rust. And,
- The Real Time for The Masses framework for embedded concurrent programming.
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
A show by @chriskrycho about learning @RustLang. Technical—but approachable! Topical deep dives, interviews, crate overviews, and more.
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.
The winapi crate provides raw FFI bindings to all of Windows API. They are gathered by hand using the Windows 10 SDK from Microsoft
-
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 apkcommand 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)