# 2025-12-11 - Vision Doc Meeting

## Attendance

### Attendees

* Pete LeVasseur
* Jack Huey
* Niko Matsakis
* xx
* xx

### Regrets

* Lori
* Ernest

## Agenda

### CFP for Linux Foundation

Niko: Were we wrong? Phrasing?

Jack: Core seems right

niko notes:

> Description (1200 characters max): Open source projects typically gather feedback through GitHub issues and forums - but these create selection bias. This talk presents methodology and surprising results from the Rust Vision Doc project: 4,200 survey responses and 70+ interviews revealing **systematic gaps between maintainer assumptions and user reality**. We'll share how we adapted user research techniques for open source and reveal the unexpected insights we discovered. Spoiler: what we learned wasn't what we expected to hear. You'll leave with practical guidance for implementing similar research in your own project, whether you maintain a library used by dozens or a platform used by millions.

I think I would replace this text with -- "helped us to sharpen our understanding of where Rust adds value and where we more work to do" or something like that. "sharpen our understanding of Rust's value proposition"

Jack: Seems true.

Jack: Going a little further, we could say something to capture interactions with e.g. Rust Global.

Jack: As above + "and its impact across the ecosystem" or similar?

Niko: Good abstract, but a bit non-specific.

Niko: Something particularly interesting to this audience could be those kinds of stories / narratives from the community.

Jack: In the abstract sense, like: "you can learn where you project succeeds"?

Niko: We learned value-prop. We're an open source project and we learned about the user experience of the Rust open source project. Not the same flavor of feedback you might get from a company executing this sort of survey.

Niko: "Of course, Rust is more than a product, it's an open source project so we learned more about how our process impacts our users and their experience participating." or similar

Jack + Niko: Let's lean on Claude

Jack: Pushed up Claude-ified version

pete notes:

I've not submitted enough talks, but the Description and Draft Abstract seem similar. What're the differences in usage?

Jack: Just a remnant, not a field in the application. Will remove one of them.

Jack: Niko, you submit please to get us picked more readily?

Niko: Understood

### Niko's next blog post

> # What do people *love about Rust?*
>
> Rust has been named Stack Overflow's Most Loved (now called Most Admired) language ever since our 1.0 release in 2015. That means people who use Rust want to keep using Rust[^gleam]--and not just for performance-heavy stuff or embedded development, but for shell scripts, web apps, and all kinds of things you wouldn't expect. When we sat down to crunch the vision doc data, one of the things I really wanted to explain was: *What is it that inspires that strong loyalty to Rust?*
>
> [^gleam]: In 2025, 72% of Rust users said they wanted to keep using it. In the past, Rust had a *way* higher score than any other language, but this year, [Gleam came awfully close](https://survey.stackoverflow.co/2025/technology/#admired-and-desired), with 70%! Good for them! Gleam looks awesome--and hey, good choice on the `fn` keyword. ;)

Pete notes:

You noticed this as well, huh? I was updating my internal yearly "track how much people love and wanna use Rust" graphs and noticed a drop.

>
> Based on the interviews, the answer is at once simple and complicated. The short version is that Rust empowers them to write reliable and efficient software. If that sounds familiar, it should: [it's the slogan that we have right there on our web page](https://www.rust-lang.org). The more interesting question is *how* it empowers them, and what it means to be empowered like that.
>
> ## Empowerment begins with reliability
>
> Throughout every conversation, no matter whether someone is writing their first Rust program or has been writing it for years, no matter whether they're building massive data clusters or embedded devices or just messing around, there is one thing that everybody says they love about Rust: **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, coming from Java
> >
> > "Rust 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)
> >
> > "9 times out of 10, I write microcontroller code and I only test it through unit testing. I put it on real hardware and it just works the first time." -- Embedded developer
>
> There's a distinct sense of **"if it compiles, it works"**. Of course that is not *literally* true -- don't go thinking you don't need tests! -- but there's something to it.
>
> ## Types as guardrails
>
> reference our first post, of how people talk about enums, and then talk about the the "seems to stay working" bit
>
> I quite appreciated how this person put it (emphasis mine):
>
> > "My experience with writing Rust software tends to be **once you've got it working, it stays working**. That's a combination of a lot of care taken in terms of backwards compatibility with the language and a lot of care taken around the general ecosystem." -- Long-time Rust developer

jack: minor, but is this same long-time Rust dev? if not, maybe make that clear

>
> I also appreciated how they called out that this sense of reliability isn't just to do with the language, but is something supported by everybody who participates in the Rust ecosystem.
>
> ## Guardrails help you get started
>
> talk about how the impact of guardrails changes:
>
> * when you are a beginner, it can help you get oriented
>
> quote from a beginner about learning new things or "leveling up", e.g.
>
> Another familiar theme, but one that showed up loud and clear in our conversations, is that **learning Rust is a way to "level up" as a developer**, learning new concepts and new domains that were previously inaccessible:
>
> > "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." -- Formal verification researcher
>
> ## Guardrails help you keep going
>
> talk about how the impact of guardrails changes:
>
> * joemag or somebody quote about
>
> > "Rust just lowers that bar. It's a lot easier to write correct Rust code. As a leader on the team, I feel a lot safer when we have less experienced engineers contributing to these critical applications." --
>
> ## Everybody's a noob at something
>
> talk about how experts going into a new area are noobs, or how even experts get tired, or when you come back to work
>
> and then come back to this quote
>
> > "My experience with writing Rust software tends to be **once you've got it working, it stays working**. That's a combination of a lot of care taken in terms of backwards compatibility with the language and a lot of care taken around the general ecosystem." -- Long-time Rust developer

Pete notes:

This is a big deal in Automotive, where the usage of code is measured in decades, once shipped. I think there should be at least one, maybe two pull quotes related to this we could use. (That's historically why decade old compilers are used D:)

>
> ## Empowerment through guardrails
>
> Then put it all together: guardrails and type systems can be empowering when they are at their best because they let you focus on what's important.
>
> ## But guardrails aren't enough
>
> You might love Rust, but to use it in production, it also has to *meet your needs*. And those needs vary by domain
>
> * embedded: no limits

jack: no limits? no quite sure what you mean

> * high-scale network services: performant, memory usage aware
> * safety critical: reliability (check) but also a number of specialied needs and regulatory apparatus (subject of)
> * GUI and application level development: ...?
>
> ## Productivity -- tooling
> ## Versatility = guardrails + performance + productivity
>
> This explains part of Rust's appeal. But it's not enough to have guardrails. Another theme that came out a lot was Rust's *versatility*But guardrails aren't enough. The language

Niko: Overall -- versatility + reliability + empowerment are greater than the sum of the parts in Rust. Goes well: guardrails help keep on track and make progress. Not so well: when guardrails get in the way of the problem you're trying to solve. Async maybe as-yet doesn't have the right modeling for success.

Niko: Need to build up usability to have
- custom error messages
- clean up `async`
- and so on

Jack: "Do we ever want a mode where people can turn some things off to get code running?" Maybe, but we need to be careful that the guardrails cannot be taken down otherwise the value-prop goes away.

Niko: Agreed, below related to this:

Niko: Some notes:

> ### 6. Recommendation
>
> Codify the values and integrate into process:
>
> - Reference existing efforts: Rustacean Principles, other blog posts
> - Propose: RFC to formalize these values
> - Use as rubric when evaluating new features
> - Pay attention to the tradeoffs
> - **Never fall too short on any one value** - the magic is in the combination

Niko: Formalization of values and ensuring that any one of these is not allowed to fall short. An example is ergonomic ref counting in recent discussions.

Niko note to self: this is the key takeaway, we have these things that are good, but they really support each other, none is primary.

Jack: We allow you to compile tests without borrow-checking? (might have missed this)

Niko: None of the values have primacy over the others. It could be possible to turn off certain things when compiling some kinds of code, but care is required to ensure reliability is not lost.

Jack: Agreeing

Niko: Missing, maybe: importance of incremental progress or ease of getting started. Reliability is important, but we need to make sure we have supportive tooling and docs to get people off the ground.

Jack: Agreeing with this idea

Niko: Will work on this during this afternoon. Attempt at draft by end of week to post before holidays.

Jack: Two week cadence might be ambitious, given we're a week from the last blog post. Week to draft, week to review could be tough.

Jack: Ship this one 19th or 22nd before the holidays, then the next one on the list after the holidays, e.g. 2nd week of January.

Jack: Going to start doing actual drafting once Niko's post is out, maybe next week it'll be ready for review.

Niko: Methdology used during writing: as hypothesis were come up with, the script was re-run. There's a trail of them, used along the way. Useful to have ability to do that.

Jack: Using Amazon Q free tier, making account as needed to run it. Documentation in the README works.

Niko: question asker and question analyzer scripts are there, docs on how to use them.

Jack: Will be hard to properly anonymize this in a way if we have a bunch of that content up for analysis.

Niko: May be workable to take analysis files and anonymize.

Jack: More generated, more anonymized D: Cannot rely on LLM tools to anonymize.

Niko: Output of question asker script is too identifiable, likely. Analyses are broader, may take some light edits.

Jack: When applicable, it's good to use fewer data to make more conclusions / data (aggregated data, analyses).

### User Research Team Pre-RFC

Pre-RFC: https://hackmd.io/lnsUyOtNTbeqhKGwQqD2kw?both

Pete jotted some into the Pre-RFC

Pete questions on best way to approach guide-level explanation and reference-level explanation for non-code RFC like this

#### Prior Art

- https://github.com/rust-lang/rfcs/blob/master/text/3599-compiler-team-reorganisation.md
- https://github.com/rust-lang/rfcs/blob/master/text/3595-move-crates-io-team-under-dev-tools.md
- https://github.com/rust-lang/rfcs/blob/master/text/3533-combine-infra-and-release-teams.md
- https://github.com/rust-lang/rfcs/blob/master/text/3455-t-test.md
- https://github.com/rust-lang/rfcs/blob/master/text/3346-t-opsem.md
- https://github.com/rust-lang/rfcs/blob/master/text/3309-style-team.md
- https://github.com/rust-lang/rfcs/blob/master/text/3327-lang-team-advisors.md
- https://github.com/rust-lang/rfcs/blob/master/text/3254-types-team.md