The Job Advertising Story of Rust

Note: This is the first blog post that I’ve ever written. Feedback is much appreciated :).

So this year, The Rust Project decided to take an interesting approach with setting the 2018 roadmap: ask the community to write blog posts on what they would like to see.

As a recent Computer Science graduate, I don’t quite have the technical depth the Rust Core team and other Rust community members may have, and am thus unable to comment as much on the direction of Rust’s language semantics, or other cool things like async I/O. However, I’d like to offer my perspective on the state of Rust job advertising.

The problem at hand

A goal I have in life right now is to get paid to develop software, ideally in Rust. Volunteer open source work is great, but I’d like to get paid to work with Rust so that I don’t have to do it exclusively outside of business hours :).

Unfortunately, the job advertising story is scattered. The only centralised place Rust work is advertised is the This Week in Rust newsletter. The original sources of those job advertisements include the Rust users forum, the Rust subreddit, HackerNews, and the company’s websites themselves. appears to have been an attempt to centralise the Rust job market, though it has fallen quiet in the majority of last year, and it is not clear who developed the site nor what direction development of the site was going to take.

I’ve heard that Aaron Turon has an idea to create a Rust matchmaking website which would link interested freelancers and contractors with Rust opportunities. This is something I’d love to see come to fruition in 2018, and I’d like extend on the idea in form of a Rust jobs website.

Product functionality and direction

To start things off, the website could have a directory of interested Rust developers and contractors. The profiles could show Rust-related contributions on GitHub and GitLab, and showcase previous projects. There could also be some form of contact details visible on the profile. Visibility of the profile could be set by the Rust developer or contractor.

The centrepiece of the jobs website will be the page listing Rust-related opportunities. They could be paid gigs, freelance opportunities, contracts, or permanent full time roles. Initially, the listings could simply be links to opportunities listed on another website. However, the long term goal is to have the full listing on the website to make it easier to index in the search engine. If the listing is being created on the website, there should be an option to create it in Markdown. Ideally there should be no requirement to have a log in to see listed opportunities.

There also needs to be a mechanism to avoid listed opportunities from going stale i.e. no one is applying, and the poster hasn’t indicated whether the opportunity is still open. Perhaps creating a heuristic based on the number of applications, the poster’s engagement with the website, and the time the application is open for to form a score, above which the posting is closed within 48 hours.

Companies that are actively hiring in Rust could also list themselves in an employer’s directory. Employer profiles could contain a blurb on what the company does, where they use Rust, and currently advertised positions. Both the contractor / freelancer and employer directories should be searchable by interested parties, but only if they choose to be publicly listed.

Once the basic functionality of the website has been built and established, an opt-in mailing list of new and available opportunities could be sent to Rust developers. It would be a batch process that runs daily, depending on the timezone of the developer.

The matching of developers and opportunities is a difficult problem, and requires experimentation to get to a solution that all parties are happier with. To start with, tags in different areas could be made mandatory for entities advertising opportunities. These tags could encompass areas such as the nature of the opportunity e.g. contract, the area the opportunity will be working in e.g. security, embedded, and the location of the opportunity e.g. remote, or on-site in San Francisco. Developers could select tags that are of interest to them, and if they are on the mailing list, only have those relevant opportunities made visible.

For the job posters, perhaps there could be an email or a web page that shows a list of developers whose tags align exactly or closely to that of the job post’s.

In the event of demand growing higher, AI could be used to perform the filtering of relevant jobs. AI could also manage the ranking of opportunities based on relevance to a developer logged into the website. The relevance ranking could also be performed in the mailing list. More data could also be included in the matching heuristic e.g. corpus of the developer’s profile.

Community around the website

The website needs to have official endorsement from The Rust Project in some capacity. Job websites are best done as monopolies, and having the endorsement will help drive adoption of the website in the community.

Ideally, the website should be open source to encourage contributions and suggestions from the community. Perhaps an RFC style process for the website can be setup and followed in line with The Rust Project’s core components. Blog posts every now and then highlighting the development direction the website would provide another avenue for the community to voice their opinion.

In order for the site to be used, there needs to be mechanisms in place to measure the effectiveness of the website. One way to test this is to have opt-in surveys to developers and job posters asking them if their goals have been met using the website, and suggestions for improvement if not.

This website is a large community undertaking, and there needs to be a way to fund it into the long term. Companies could perhaps pay freelancers to work on building and maintaing the website. Having a separate organisation to collect and distribute funds would be a significant overhead I’d like to avoid commercialisation of the website, since to me this would be an asset to the Rust community, and I don’t want to see it behind closed doors :(.

Technical recommendations

This section can be thought of more as precursory suggestions with minimal research rather than hard rules that I want followed. I’ve got less than a year’s worth of commercial development experience, and I’m sure that there are people out there who might see a better way to solve the problems outlined above. My rationale behind the following suggestions are the following:

  • A Rust jobs should be built using Rust crates. Of course, the downside of this approach is that there will be a lot of yak shaving.

Rocket currently the biggest mindshare in the Rust web frameworks market, though Gotham also looks like a good choice given that it works on stable. A downside to Gotham though is its use of tokio, which could make things more difficult for new contributors.

I am in favour of building the website with a templating engine in the backend rather than using a frontend framework. Tera is a good looking option that could be used for this purpose. There is also the handlebars crate depending on preferences, on first glance it’s tough to tell which solution looks more complete.

A jobs website is inherently a search problem, and a search engine will be core to its functionality. I recommend tantivy since its main contributor has a background in search engineering. Unfortunately, I do not, and I have no idea how much it will take to bring tantivy to a level required in a jobs website.

For the mailing list, the lettre crate could handle the generation of the email and connect with the email infrastructure managing the sending. This crate is also used in to manage the confirmation of a user’s email address.

My recommendation for the database is Postgres, since Diesel has supported it for the longest time, and I’m not sure how well MySQL works with it.

If AI is mandated in the future, one possible solution is the Rust AI crate is juice. Unfortunately, it looks like it will require a very large amount of work to bring it up to a level required by the website. An alternative is the Tensorflow Rust bindings. These bindings are based off the Tensorflow C API, which is not only partially unstable, but also not as feature complete as the Python API is.

For the website’s infrastructure, I feel Docker would do a very good job replicating a production environment in a local development environment. It would also make it very easy to deploy it into production, whether with AWS or on a VPS such as Vultr.

I am certain that I have missed some more components that will be required, if the website gets off the ground, it can be worried about then.


There does appear a need for companies and other interested parties to find Rust developers. And there are many people out there who want to be paid to write Rust code. Granted, I live in a city where I know of just 1 Rust developer, and no, it’s not me ;). But based on the people I’ve talked to looking for Rust developers, there is interest in any available opportunities.

I propose a Rust jobs website to alleviate the demand from both sides, and that it be developed in tandem with the Rust community so as to build something that will better meet the needs of the website’s main users.

I look forward to what 2018 brings for Rust and where it goes from here :).

Originally published at

Young Creative Technologist at the State Library of NSW.