Try   HackMD

Vision doc notes

2025-01-30

Agenda

Links

Notes

nikomatsakis:

  • I think an important part of this work will be establishing and clarifying Rust's mission – what are we doing here?
    • it's not to be the only language anybody uses
    • so what is it?
  • I am embarassed I didn't even include interop =)
  • I want the recommendations to be specific enough to be useful without being proscriptive. I didn't sketch anything there because I didn't want to make this about what Niko thinks we should do from the very get go, but as an example
    • "ease Rust adoption via language interop", with a focus on
      • C++, particularly for domains X Y and Z
      • mobile phone
      • "write once, Rust anywhere", I don't know
  • I would like to leave this meeting with a kind of plan around how we get "snapshots" of what is happening in Rust
    • what kinds of communities should we reach out to?
    • can we get a concrete list?
    • shall we start by holding one conversation as a group to get the feel? hold all conversations as a group?
  • I want to be sure we include the Rust org, I think we need to capture perspectives of
    • existing maintainers
    • would-be volunteers and individual contributors
    • companies looking to participate
    • rust foundation members
  • I wonder how much we can use this doc to identify the right "role" of the Foundation
  • I am embarassed I left out safety critical :)
  • late-breaking idea
    • what promises have we already made in our message, and should we evaluate how well we are keeping them
      • and maybe add more?
      • e.g. stability over stagnation

Josh:

  • Most of what's there looks reasonable
  • Good to have a "where Rust is" and not just "where we see Rust going"
    • This is a good opportunity to try to establish some axioms, since that'll help us maintain those axioms as we continue forward
    • We should have both axioms and non-axioms
    • Important to write things down, because some things that people think are axioms might instead be happenstance that we don't intend to preserve, and we should find that out and document it
  • Some amount of recognition for Rust being maximally general purpose, an "everything" language. It isn't necessarily the best for every possible domain, but it is capable of addressing every domain, and that's not something many languages can do.
  • Not sure about "upcoming trends" here; is the intention to talk about Rust in relation to those trends? How should that interact with what kinds of problems we should work on?
  • Upcoming trends should include Rust for Linux and more use of Rust in places that were previously only C
  • Need to have interoperability highlighted very highly, and I think we should have a clear vision of interoperability being far above what people expect. Something like "Rust should interoperate with C and C++ at least as well as C++ interoperates with C, if not better".
  • Some mention of specification goals and standardization non-goals.
  • Some very early/central mention of Rust's community with respect to inclusion, safety, etc, in two specific aspects:
    • How do we maintain this as we grow, given that as we grow our community will include more and more people who come to Rust without initially sharing Rust's values? We want to avoid regression to the mean, because that's the default.
    • How do we maintain this given gestures to the state of the world around us.
  • Grumble grumble "AI", "AGI/ASI", "let's not help kill everyone". Full acknowledgment that this is an important domain for many people, but if we're going to include it can we at least provide some kind of nod towards not trying to enable accelerationism?
  • UI/GUIs/etc
  • Mobile development
  • Interop with other languages: Java, Python, .NET, etc
    • Safe interop, not just interop via C
  • Rust is not "done" and will not draw a line saying "no new use cases", we won't stop listening to users and evolving the language
  • Rust will not become C++, Rust should not be a kitchen sink, Rust needs to bound complexity
  • Bridges with more communities, the way we have bridges with the Rust for Linux project.
  • "We are not a fact of nature, we are not immutable". People should never treat Rust as something they can't make better; people who run into issues (whether in a new or existing domain) should have the thought that they could make Rust better or make Rust suck less.
  • Governance and evolution of governance.
  • Crater and detecting breakage. Crater is a two-way conversation.
  • Discussion about the tension between "LTS" models and other models. People who want to freeze parts of the world, and people who want to keep current / handle changes in smaller amounts.
  • Are there things that Rust has "lost" since its inception? (I don't just mean things like "we can't make breaking changes / Rust 2.0". I mean axioms/ethos/etc.)

Santiago:

  • The TOC mentions learning curve which of course I agree, I wonder if we should focus or pay some attention to universities.
  • +1 on Rust mission but I think is also important to pay a lot of attention to the "health" of our organization, teams and people.
    • Not sure if "health" describes what I'm thinking about but talking about processes, communication, coordination, way to solve issues in general or address general issues, etc
    • I feel it would be great to have somebody that is trusted, respected and entitled in order to communicate issues/feelings and know that is not only going to be listened but also that things are going to be handled or someone is going to try to handle them.
  • Rust for Linux is key IMHO for some "next level" floor of success :)

Jon:

  • What about safety critical applications in upcoming trends (automotive, autonomous, aero)?
  • Should Rust education also be part of this vision, both professional and postsecondary?
  • Does it make sense to include negative goals? As in, what areas does Rust deliberately avoid trying to participate in
  • Should support in more than just one toolchain be part of the Rust vision, or does that just invite more complexity?
  • Should the governance/evolution of Rust itself be part of the vision?
  • What about essential crates in the ecosystem that are maintained by individuals/orgs with no concrete support/accountability to the community and project (the Nebraska problem)
  • As Rust gains maturity, how do we balance the natural increase in complexity from adding desired features with the overall complexity of the language for attracting new users?
  • Who decides where Rust goes? For example, democracy vs technocracy?

Nadri:

  • how do we even start answering the question of "what Rust is for"
  • I'd want to see a breakdown of "where rust is strong today"
  • big fan of phrasing it in terms of "finding opportunities for rust to be even better"
  • one good outcome of the whole project for me would be some "no"s, i.e. some areas/applications/users where we acknowledge they're not our priority
    • random thought: we already implicitly favor open source Rust projects over closed-source ones by using crater as a "source of truth for rust code out there"
    • not just "no"s of course, "not this" is not a direction that leads anywhere, it's more like a litmus test of clarity of purpose
  • would be interested in acknowledging the things we're already prioritising somewhat covertly as a project
    • e.g. open source as I just said
    • e.g. we put a lot of effort into helping beginners (in our docs, error messages etc.)
    • e.g. we put a lot of effort into having a clear story for what is or isn't a breaking change when evolving a crate
    • are we doing good on these in practice?

Notes:

  • Kissiedu: Language interop would be a good section to have
    • C++ has momentum, of course, but there is a need for Python interop
    • How will we build those bridges, what does an ambassadorial effort look like?
  • Josh: Don't think we should fold that into webassembly but full agreement that this is important on its own
  • niko: Antigoals are a theme that came up, I like it, I think a goal for us should be that we are better able to focus, and antigoals seem like they would help
  • josh: establishing axioms of Rust seems important, people all have different ideas of what Rust is, some of those are core properties, others are accidents of our current state
    • example: notion of a non-goal for "we are not going to stop making Rust", i.e., I think there are languages that continue to evolve and languages that are dead. Rust is in the former camp.
    • but also not a goal to meet every goal every one ever has
  • niko: something I noticed is communities, seems like identifying our community, intersecting, communites, and how we bridge between them is important, I noticed you brought it up Ernest
    • e.g, rust org, tokio, rfl, interest groups
  • Ernest: purpose of this doc
    • I know it's another recommendation – but in the doc where it speaks about application domains –
      • are we going to also look at more generalized domains like aerospace, game development, automotive
      • one thing I've always come across is how well respected the Bevy community is
  • niko: one thing I wondered about is how to describe our users, I think grouping by level of adoption is good
  • JT: we should use this as a way to build bridges to other communities
    • one key difference between evolving languages is whether people treat them as an immutable fact of nature or as a living thing that people look for ways to involve
    • I don't want people to show up, run into issues, talk about "well, I guess that's just how Rust is"
    • most people who show up to C++ treat it as a fact of nature, but I don't want people to treat Rust that way, a thing we can do is to say we want to grow with you, please never treat us as immutable
  • Nadri: is governance of the project in scope?
  • nikomatsakis: I think it is
  • nikomatsakis: I wonder whether/how we should talk about our inclusive ethos, e.g. reputation within queer community has been strong (hopefully deservedly) and has meant we gain lots from people coming in
  • JT: I think it's important to write down that it's a goal to preserve values, to avoid regressing to the mean of the tech industry as a whole
  • Nadri: related point in my own notes, I would be interested in taking the time to acknowledge the values we already have in place, not all of which are explicit
    • e.g., we obviously favor beginners, but I don't know whether it's ever been stated
    • the fact that we use crater to detect big breakage, says that we treat open source projects as the things we really don't want to break
      • private codebases exist but we don't go out of our way to fix it
  • nikomatsakis: two points
    • I think that we would like to get access to private codebases, but I also think crates.io is foundation for everyone
    • good case
  • JT: interesting property of crater is that it's a 2-way conversation
    • sometimes we say "oh that breaks thing, we shouldn't do it"
    • other times we will say, let's send a PR, once that is merged, let's do it
    • imp't for two reasons, we are willing to have that conversation,
    • also, like GREASE (Generate Random Extensions And Sustain Extensibility) for TLS 1.3, keeps the extension points real
      • e.g. TLS will sometimes make up extensions and test whether people test for that
      • nikomatsakis : OMG SO BRILLIANT
    • stability is important but so is allowed breakage

"people" / "data we should gather" / stories

nikomatsakis

  • company tech leads
    • "FAANG"
    • start-ups that have opted for Rust from the beginning
    • companies that converted to Rust
  • companies that want to like Rust but don't, or who have come to stop using it
  • Rust adopters from different ecosystems ?
  • Rust trainers
    • what are the experiences you see, what have you learned
  • professors at universities
    • what does it take to get Rust taught?
  • DARPA / CISA / EU / alpha omega / people
    • who is driving this push for memory safety? what about supply chain?
  • open-source orgs
    • tokio
    • bevy
    • RFL
    • …?
  • Rust meetup communities
    • I'm curious about Rust in Asia and Africa especially
  • For non-people data…
    • I'd be curious to look at the number of widely used projects that have single maintainer or don't have security policies, that sort of thing
    • Can we assess "onboarding time" to the Rust compiler?

santiago:

  • Rust for Linux people
    • Maybe C Linux people that hate Rust :)
  • Universities or maybe just with Bart Massey
  • Big companies about their usage and adoption

Ernest:

  • Global Rust community leads
  • AeroRust and other sub-domain communties
  • "Mid-sized Enterprises" 500 - 700 people (it depends on your definition of mid-sized)
  • People who don't want to adopt Rust.

nadri

  • questions to ask them about
    • do we uphold our promises
    • opportunities to do better?
    • the paths they took on their way to rust, away from rust, learning, stumbling blocks etc
    • their view of our governance: pace, transparency, accessibility
    • what do you love about rust
  • rust teachers
  • rust project members obv
  • I want to hear stories of people approaching the rust project with intent to contribute
  • one I have some access to: researchers in formal methods/reliable software
  • python users with perf/scalability constraints (because I think the python+rust story is delightful)
  • game engine people
  • companies that seriously considered rust, whether they said yes or no

jon

  • (Obviously) Rust interop users, especially C++, but also other languages (Python, Java, other domain-specific leaders)
  • Non-English speaking users
  • Other systems language users who do not use Rust, to understand why it doesn't meet their needs or if they just don't know/understand what Rust offers
  • Individuals in positions of governance for other successful languages

Josh:

  • We should very clearly establish, as early as possible, a consensus on "who is this document for". Before we start talking to people, we should all be in agreement on what problem we're trying to solve here. After we've done that:
  • Rust project people. We should make sure that people in the project are at least somewhat aligned with the problem we're trying to solve here. That doesn't mean everyone in the project has to agree with the vision, but it means nobody should be going "wat" or "absolutely not" about it.
  • People attempting to introduce Rust into existing codebases (with various languages and tooling). Right now there are best-known methods, but there's a baseline activation cost. What would it feel like to make that activation cost zero?
  • People whose first impression of Rust is not what we might expect. Not the kinds of people who hate it (that's not the audience we should listen to), but anyone who thinks "not for me" or who has misconceptions about it.
  • People using other languages who prefer those languages over Rust, to understand why. I don't just mean people who think they can't use Rust, I mean people who think they could but they don't want to, for what they feel are reasonable reasons.
    • Zig users
    • Python users in particular domains (e.g. numerics)
    • Communities around any newer-than-Rust language; let's look forward and not just back.

JT: decide what document is for (goals) first, get consensus on that among the people working on it, before we start talking to people etc.
jon: who gets to decide (e.g. approve this document)
nandini: how is this doc feeding into project goals
nandini: Talk with people in the project, make sure this

homework:

  • niko to send out lettuce meet
    • people to assess their availability
  • write out your take on the mission
  • write out what questions you might want to ask and to whom
    • focus groups, people sometimes don't talk, you get a leader who will talk more
  • find people with experience on the nuts and bolts of how to do it
  • Note your various affiliations (e.g. employer/client/etc), so that we can assess whether we have too few of those and that might impact legitimacy

top-line goal:

make sure this is, and is perceived as, legitimate – in the sense that everyone whose input "should" be in it actually has a good opportunity to supply it

Last changed by 
 
Niko Matsakis
0
296
Published on HackMD