Microsoft chief engineer: Rust will face ten challenges
Microsoft chief engineer: Rust will face ten challenges.
Nick Cameron, a principal engineer at Microsoft, posted a blog post pointing out the top ten challenges he believes Rust will face now and in the years to come, along with some initial solution ideas.
Nick Cameron is currently in charge of the company’s Rust-related work; at one time, he was a member of the Rust core team.
Nick points out that Rust is in a good place right now; it’s getting more popular, more contributors, and it’s being used in some important areas.
But in these changing times, transitioning from a research project to a new, rapidly changing language to a popular, mature project is a difficult evolution.
“Here I want to describe the top 10 challenges that I think Rust faces now and in the years to come. I have some ideas for solutions, but they are big, hard problems with no easy answers, so real solutions All require iteration, energy, and creativity. My focus is on the core project; the community and ecosystem face many challenges (eg how to make GUIs in Rust, or how to get more crates into 1.0) that I think must be largely driven by community to solve.”
The details are as follows:
1. How to guide development and keep Rust open?
In open source work, there is always some tension between what is best for the project and what volunteer contributors want to do.
Now, as the Rust community grows and Mozilla ends direct support, this tension in Rust seems to be growing.
While there are many people working on basic maintenance, they are often understaffed; there is also a lack of resources, strategic work or effort to guide contributions in some important areas.
In some ways, it might be easier to take a top-down approach, Nick thinks ; but it could also cause Rust to lose some of the advantages it has as an open source project.
The biggest challenge was making sure that important but unattractive work was done without losing parts of the project that made it awesome.
Nick said they are currently working on a number of specific issues, including:
- Prioritize completing the work at hand rather than starting a new one,
- Prioritize tools, libraries and non-technical work as well as languages and compilers,
- Prioritize low-impact, lower-cost jobs that are likely to have a high impact overall (over large, glamorous jobs).
” Related to this challenge is maintaining Rust’s fundamental characteristics in the face of growth. In particular, how projects can evolve and embrace new contributors and leaders (and the inevitable changes that come with them) without ignoring Rust core mission? As the number of observers (and commenters) grows, how do we continue to be open and transparent in discussions and decisions? ”
2. Diversity and Inclusion
The state of diversity in Rust is terrible. While Rust may have done a good job of being an inclusive project, many contributors had to leave the project for some negative reason; avoiding burnout is also part of inclusivity.
“ An important aspect of inclusivity is being able to accommodate a variety of opinions. We cannot be diverse or inclusive if we can only get along if everyone agrees. Helpful, but it also creates problems. Our culture of avoiding conflict instead of resolving it is unhealthy and leads to dysfunctional governance. These are really hard to fix! But we have to prioritize them, even if they are hard, It’s also painful at times. “
3. Avoid the rigidity of inefficient processes
Nick said that while Rust has grown rapidly over the past few years, its processes and organization have not kept pace.
In anything related to governance or process, there is a tremendous amount of inertia for change.
Even though there is a lot of friction in the existing process, there seems to be little else to do but adjust on top of it.
“We’ve built up so much organizational debt that a radical change is needed, but it’s going to be very difficult.”
At the heart of the problem, he argues, is the project’s reluctance to accept “management” (people management, project management, product management) as an important part of project leadership.
These things can be independent of technical leadership, but require real delegation of authority (not just job delegation).
The challenge for the project was to accept commissions, support these activities, and introduce new processes to better support the project.
4、Navigating the crate ecosystem
Rust strikes a good balance between a minimal standard library and “batteries included” thanks to a thriving ecosystem and easy-to-use package manager.
However, the crate ecosystem has always been a thorny issue. T
here are a lot of crates out there, and it takes a lot of effort to find the right one, or to participate well in the community.
This will become an even bigger problem as more and more users who are not active participants in the community emerge, and the number of crates increases.
5、The async ecosystem
Asynchronous programming is important to many areas of Rust’s goals and works well with Rust’s programming model.
However, its ecosystem is somewhat fragmented at different runtimes; improvements are being made, but progress is slow and the ultimate success is uncertain.
“The risk is that we end up bringing stuff into the standard library that isn’t widely accepted by the community, and we end up with a worse ecosystem than we started with.”
6. How can the language be made more broadly appealing without losing its core focus?
Nick believes Rust still has a lot of room to grow on top of its existing success.
Much of today’s software is written in more performance-focused languages, and Rust’s focus on safety, ergonomics, and performance results in better products and increased productivity.
However, Rust is relatively difficult and expensive to learn, and making Rust easier to learn and use may expand its influence.
” I don’t think supporting GC, using sugary syntax for
Rc<RefCell<T>>types or adding a bunch of syntactic sugar is the solution. We have to make things simpler without losing the advantages of Rust being systems programming at its core. Reducing the need for explicit lifetimes needs, making the borrow checker more powerful, not overcomplicating the trait system, focusing on the user experience, avoiding being a bloated language would all help. Maybe we’ll find new abstractions that can dramatically simplify ownership and lifecycle? “
7. Memory Model and Unsafe Code
Security is one of Rust’s main features and what drives many people to use it.
Therefore, there is a need to be able to provide more support and a better experience for programmers working on unsafe jobs.
Doing this requires a clearer understanding of Rust’s memory model, and then developing language features, libraries, and tools.
Fortunately, this area has academic research, great community work, MIRI, guidelines for insecure code, and more.
Unfortunately, this is a very complex and difficult area, and the opinions of many outsiders can slow down progress and make the job harder for those involved.
Nick noted that some potentially high-impact changes simply cannot be made for political and technical reasons.
8. Development of the standard library
The standard library has no way to evolve other than monotonically (it can be deprecated but never removed, and cannot be changed).
By itself, this will cause the standard library to grow larger and more cluttered. But there are also second-order effects: Stability must be taken extremely conservatively, there are no other possible states for the API other than “stable forever” and “only available at night and fully possible to change”.
Relatedly, the standard library is an all or nothing deal (technically there is also liballoc).
In addition to having a more granular version management solution, it would be beneficial to use the standard library more granularly, not just the core library or all of the standard library.
9、Big compiler changes
Rustc is now a very large piece of software. It has a lot of inherent complexity (Rust is a complex language and it’s very difficult to compile quickly while providing good error messages), a lot of common problems with large software, and a lot of technical debt.
There are some significant challenges, especially around compile times (of which incremental and parallel compilation are two approaches in progress), and these are proving to be hard work;
major changes in the future will only change more difficult. Fortunately, the compiler team is competent, energetic, and well-resourced. However, making large, high-impact changes to rustc is still challenging.
Macros are one of the most imperfect parts of the language.
Declarative macros introduce a whole new sublanguage; Procedural macros are clunky, require a lot of dependencies and are difficult to master.
All macros play poorly with the compiler (compile time, incremental compilation, error messages) and tools (various issues with IDEs, rustdoc, etc.).
” The reason I think it’s a huge challenge (and not just another language feature that can be dealt with) is that these problems are fragmented and difficult.
There are no good solutions (probably), just a lot of engineering and design Work.
Many issues (e.g., macro hygiene) require expertise that doesn’t exist in the community.
Macros are also not high-priority (they’re inherently effective, after all), and not glamorous enough to attract contributors. “
Nick concludes with a list of ten so-called “big” Rust problems that might feel a little negative; but they are all real-world challenges.
Fortunately, people inside the project are aware of these problems and are actively working on them.
“ While any solution is difficult, I think there are viable and realistic solutions to all of these challenges.
If we can focus on solving these problems (and of course all the other day-to-day challenges) then I think Rust will continue to grow and succeed. ”
Details can be found in the full text of the blog .