Rust library team thumbs through reorg playbook, calls for new members

Rust library team thumbs through reorg playbook, calls for new members

With the Rust project expanding, the programming language’s standard library team is trying a separation of concerns between public API design and their actual implementation. 

The change will see the Libs team owning just the public API of the standard library, while the Compiler team will take care of its implementation. The split is similar to the way the Rust language is handled, with the language team coming up with the language design and the compiler team owning the corresponding code. 

According to Libs team member Ashley Mannix, this is meant to “suit the interests of both teams to better support the needs of the standard library”. Currently, there is apparently “little room for development of the standard library itself”. This seems to be mostly down to the libs team spending a lot of time “supporting libraries in the wider Rust ecosystem and working to consolidate idioms into standard APIs”.

The compiler team has “years of experience” working on very specialised codebases like the one presented by the standard library, so handing it over should free up Libs a bit. Of course there will still be a lot of exchange necessary between the teams, since API design and implementation tend to go hand in hand, but the new separation of concerns will hopefully “make standard library activities more focused”.

To make sure there’s enough capacity to move the library efforts forward beyond that, Mannix also called on the Rust community, asking devs interested in any of the two specialisations to get in touch. 

Lately the Mozilla-backed project seems to have had trouble getting new helpers on-board, which, for example, was one of the reasons the docs team was shuttered. Not only are volunteers hard to find, the last annual community survey also highlighted issues when it came to convincing more companies to use the language. Reasons identified for this ranged from Rust being seemingly hard to learn to a lack of user-friendly tooling.

If a more focussed approach can help the team gather additional contributors and free up time to tackle those issues, it may be the right decision. The potential pool of capable (or at least interested) hands shouldn’t be too small given that Rust is still a favourite amongst StackOverflow users, and is currently making headway in the Tiobe index.