Lessons learned from the Rust Vision Doc #1746

nikomatsakis · 2025-11-21T21:19:16Z

The first blog post resulting from the Rust Vision Doc effort.

cc @rust-lang/project-vision-doc-2025

Rendered

nikomatsakis · 2025-11-21T21:19:55Z

One thing I'd like is suggestions for a snappier title!

Kobzol · 2025-11-21T21:31:12Z

"Initial Vision of the Rust Vision Doc"?

programmerjake · 2025-11-21T22:10:59Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+First, unsurprisingly, people love Rust's **reliability**:
+
+> "What I really love about Rust is that if it compiles it usually runs. That is fantastic, and that is something that I'm not used to in Java." -- New Rust developer who previously Java


who previously Java

seems truncated

Clearly it should be "who previously Java-ed" 😆

PLeVasseur

Nice write-up. Mostly a couple of typos / rewords.

Wanted to highlight the idea of a potential user research team in supporting gathering feedback on some particular questions Rust Project Teams may be coming up against.

PLeVasseur · 2025-11-21T22:21:34Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+What you want to know, of course, is what's *true* -- so you come at it sideways. You ask them factual, non-leading questions. In other words, you certainly don't say "Do you agree the borrow checker is really hard?" And you probably don't even say, "What is the biggest pain point you had with Rust?" Instead, you might say, "What was the last time you felt confused by an error message?" And then go from there, "Is this a typical example? If not, what's another case where you felt confused?"
+
+To be honest, these kind of "extremely non-leading questions" are kind of difficult to do. But they can uncover some surprising results.


Replace one of the "kind" in the sentence, maybe?

Suggested change

To be honest, these kind of "extremely non-leading questions" are kind of difficult to do. But they can uncover some surprising results.

To be honest, these sorts of "extremely non-leading questions" are kind of difficult to do. But they can uncover some surprising results.

PLeVasseur · 2025-11-21T22:25:09Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+> "What I really love about Rust is that if it compiles it usually runs. That is fantastic, and that is something that I'm not used to in Java." -- New Rust developer who previously Java
+>
+> "Rust is is one of those languages that have just got to your back. You will have a lot more sleep and you actually have to be less clever." -- Long-time Rust developer (>10 years)


Slight typo maybe?

Suggested change

> "Rust is is one of those languages that have just got to your back. You will have a lot more sleep and you actually have to be less clever." -- Long-time Rust developer (>10 years)

> "Rust is is one of those languages that has just got your back. You will have a lot more sleep and you actually have to be less clever." -- Long-time Rust developer (>10 years)

PLeVasseur · 2025-11-21T22:28:00Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+> "Rust introduces you to all these things, like match and all these really nice functional programming methods." -- New Rust Developer
+>
+> "I think Rust ownership discipline is useful both for regular Rust programmers and also for verification. I think it allows you to within the scope of your function to know very clearly what you're modifying, what's not being modified, what's aliased and what's not aliased."


The other quotes have some kind of indication of the background of the individual. Missing it here?

PLeVasseur · 2025-11-21T22:29:05Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+## Enums as Rust's underappreciated superpower?
+
+One interesting thing was the number of people that talked *specifically* about Rust enums, which allow you to package up the state of your program along with the data it has available in that state. Enums are a concept that Rust adapted from functional languages like Ocaml and Haskell and fit into the system programming setting.


I think it's spelled OCaml.

Suggested change

One interesting thing was the number of people that talked *specifically* about Rust enums, which allow you to package up the state of your program along with the data it has available in that state. Enums are a concept that Rust adapted from functional languages like Ocaml and Haskell and fit into the system programming setting.

One interesting thing was the number of people that talked *specifically* about Rust enums, which allow you to package up the state of your program along with the data it has available in that state. Enums are a concept that Rust adapted from functional languages like OCaml and Haskell and fit into the system programming setting.

PLeVasseur · 2025-11-21T22:30:52Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+What we found from talking to people about their experiences contributing to Rust is that, if you come as an individual with a narrow ask, the experience can often be pretty good:
+
+> "If I could make sense of the code, I would file a contribution. Even if you're not a Rust contributor, you can kind of tell if something makes sense. When I struggled with something, I went to a couple of office hours with cargo team, which we found very helpful." -- Rust developer at a startup


Dropped "the"?

Suggested change

> "If I could make sense of the code, I would file a contribution. Even if you're not a Rust contributor, you can kind of tell if something makes sense. When I struggled with something, I went to a couple of office hours with cargo team, which we found very helpful." -- Rust developer at a startup

> "If I could make sense of the code, I would file a contribution. Even if you're not a Rust contributor, you can kind of tell if something makes sense. When I struggled with something, I went to a couple of office hours with the cargo team, which we found very helpful." -- Rust developer at a startup

PLeVasseur · 2025-11-21T22:33:22Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+But when you try to take on larger tasks, and particularly if you are trying to take on a set of larger tasks as a *company*, it can be very confusing to figure out what you should do next:[^notjustyou]
+
+> "\[My other project\] is in a bit of a limbo. We have an MCP. It's been accepted in January, but I myself didn't really spend that much time on it since then. It's a bit unclear to me at times how I can proceed." -- that same Rust developer from the same startup


To make this a bit more readable it might be nice to link out to something that explains what an MCP is, especially in the age of the Model Context Protocol getting popular 😅

Suggested change

> "\[My other project\] is in a bit of a limbo. We have an MCP. It's been accepted in January, but I myself didn't really spend that much time on it since then. It's a bit unclear to me at times how I can proceed." -- that same Rust developer from the same startup

> "\[My other project\] is in a bit of a limbo. We have an MCP [[Major Change Proposal](https://forge.rust-lang.org/compiler/proposals-and-stabilization.html)]. It's been accepted in January, but I myself didn't really spend that much time on it since then. It's a bit unclear to me at times how I can proceed." -- that same Rust developer from the same startup

PLeVasseur · 2025-11-21T22:40:35Z

content/lessons-learned-from-the-rust-vision-doc-process.md

+
+* **First, we have to go broad *and* deep**. For this first round, we focused on high-level questions about people's experiences with Rust, and we didn't get deep into technical blockers. This gives us a good overview but limits the depth of recommendations we can make.
+* **Second, we should find ways to "open the data" and publish results incrementally**. We conducted all of our interviews with a strong guarantee of privacy and we expect to delete the information we've gathered once this project wraps up. Our goal was to ensure people could talk in an unfiltered way. This should always be an option we offer people -- but that level of privacy has a cost, which is that we are not able to share the raw data, even widely across the Rust teams, and (worse) people have to wait for us to do analysis before they can learn anything. This won't work for a long-running team. At the same time, even for seemingly innocuous conversations, posting full transcripts of conversations openly on the internet may not be the best option, so we need to find a sensible compromise.
+


Suggested change

**Third, work done can support Project Teams' decisions**. A challenge raised by Rust Project Teams at times is on obtaining a sense of "what would a user think about this?" on a technical decision being made. An avenue to explore is how a user research team could support collecting qualitative feedback and synthesizing it into a useful report to guide decision making.

Ah yeah, this is a nice callout.

Seems like this has overlap with what t-survey does (or should?) do.

first draft of new post

1d7f195

nikomatsakis changed the title ~~first draft of new post~~ Lessons learned from the Rust Vision Doc Nov 21, 2025

programmerjake reviewed Nov 21, 2025

View reviewed changes

PLeVasseur approved these changes Nov 21, 2025

View reviewed changes


		First, unsurprisingly, people love Rust's reliability:

		> "What I really love about Rust is that if it compiles it usually runs. That is fantastic, and that is something that I'm not used to in Java." -- New Rust developer who previously Java


		What you want to know, of course, is what's true -- so you come at it sideways. You ask them factual, non-leading questions. In other words, you certainly don't say "Do you agree the borrow checker is really hard?" And you probably don't even say, "What is the biggest pain point you had with Rust?" Instead, you might say, "What was the last time you felt confused by an error message?" And then go from there, "Is this a typical example? If not, what's another case where you felt confused?"

		To be honest, these kind of "extremely non-leading questions" are kind of difficult to do. But they can uncover some surprising results.

	To be honest, these kind of "extremely non-leading questions" are kind of difficult to do. But they can uncover some surprising results.
	To be honest, these sorts of "extremely non-leading questions" are kind of difficult to do. But they can uncover some surprising results.

	> "Rust is is one of those languages that have just got to your back. You will have a lot more sleep and you actually have to be less clever." -- Long-time Rust developer (>10 years)
	> "Rust is is one of those languages that has just got your back. You will have a lot more sleep and you actually have to be less clever." -- Long-time Rust developer (>10 years)


		## Enums as Rust's underappreciated superpower?

		One interesting thing was the number of people that talked specifically about Rust enums, which allow you to package up the state of your program along with the data it has available in that state. Enums are a concept that Rust adapted from functional languages like Ocaml and Haskell and fit into the system programming setting.


		What we found from talking to people about their experiences contributing to Rust is that, if you come as an individual with a narrow ask, the experience can often be pretty good:

		> "If I could make sense of the code, I would file a contribution. Even if you're not a Rust contributor, you can kind of tell if something makes sense. When I struggled with something, I went to a couple of office hours with cargo team, which we found very helpful." -- Rust developer at a startup


		But when you try to take on larger tasks, and particularly if you are trying to take on a set of larger tasks as a company, it can be very confusing to figure out what you should do next:[^notjustyou]

		> "\[My other project\] is in a bit of a limbo. We have an MCP. It's been accepted in January, but I myself didn't really spend that much time on it since then. It's a bit unclear to me at times how I can proceed." -- that same Rust developer from the same startup


		* *First, we have to go broad and* deep**. For this first round, we focused on high-level questions about people's experiences with Rust, and we didn't get deep into technical blockers. This gives us a good overview but limits the depth of recommendations we can make.
		* Second, we should find ways to "open the data" and publish results incrementally. We conducted all of our interviews with a strong guarantee of privacy and we expect to delete the information we've gathered once this project wraps up. Our goal was to ensure people could talk in an unfiltered way. This should always be an option we offer people -- but that level of privacy has a cost, which is that we are not able to share the raw data, even widely across the Rust teams, and (worse) people have to wait for us to do analysis before they can learn anything. This won't work for a long-running team. At the same time, even for seemingly innocuous conversations, posting full transcripts of conversations openly on the internet may not be the best option, so we need to find a sensible compromise.


	Third, work done can support Project Teams' decisions. A challenge raised by Rust Project Teams at times is on obtaining a sense of "what would a user think about this?" on a technical decision being made. An avenue to explore is how a user research team could support collecting qualitative feedback and synthesizing it into a useful report to guide decision making.

Lessons learned from the Rust Vision Doc #1746

Are you sure you want to change the base?

Lessons learned from the Rust Vision Doc #1746

Uh oh!

Conversation

nikomatsakis commented Nov 21, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nikomatsakis commented Nov 21, 2025

Uh oh!

Kobzol commented Nov 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PLeVasseur left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nikomatsakis commented Nov 21, 2025 •

edited by rustbot

Loading