[Blog post] Rustacean principles

community
1

New blog post…

Rustacean principles

As the web site says, Rust is a language empowering everyone to build reliable and efficient software. I think it's precisely this feeling of empowerment that people love about Rust. As [wycats] put it recently to me, Rust makes it "feel like things are possible that otherwise feel out of reach". But what exactly makes Rust feel that way? If we can describe it, then we can use that description to help us improve Rust, and to guide us as we design extensions to Rust.

Besides the language itself, Rust is also an open-source community, one that prides itself on our ability to do collaborative design. But what do we do which makes us able to work well together? If we can describe that, then we can use those descriptions to help ourselves improve, and to instruct new people on how to better work within the community.

This blog post describes a project I and others have been working on called [the Rustacean principles][RP]. This project is an attempt to enumerate the (heretofore implicit) principles that govern both Rust's design and the way our community operates. The principles are still in draft form; for the time being, they live in the nikomatsakis/rustacean-principles repository.

Would love to hear what folks think!

24 Likes
2

First things first -- adorable blog re-design :heart:

A related past discussion is Goals and priorities for C++, where we looked at one proposal for C++ principles. Diffing that with with Rust principles, I have the following thoughts:

I love that supportive is a separate, explicit goal -- the secret power of Rust is people (well, and the borrow checker sometimes helps), so it's important that we have a people goal of the list of language principles.

I am of two minds about versatile. Historically, I've always felt it's a shame that we don't have a "better implementation of OCaml", so that Rust can have a laser-focus on systems programming niche. But recently, I come to appreciate the "one language to rule the all" sentiment more -- today's software is big, and big means that it will necessary span all the layers, it will be both high-level and low-level. And, if you can do both in one language, that simplifies the system greatly. Over the last couple of years, I've migrated my scripts form bash to python to Julia to Rust. Rust is supposed to be the worst language for shell scripting, but, given that I get to re-use libraries, IDE support and my own knowledge, it ends up the most productive (but definitively more verbose in the number of lines of code).

I am slightly cautious in that I don't see a value that directly corresponds to "both software and language evolution" from the C++ list. To put it in other words, "don't do breaking changes" is something we very much do, but I find it hard to attribute it to a specific principle. It kind of is about productivity and reliability, but it also kind of isn't, at lest not in the specific way that principles are elucidated.

For the "how to rustacean", I feel that one thing is missing, which seems important to me at least. I'd put it as "you don't have to be perfect". That's a bit hard to explain; Rust is an open source project, and a lot of it is driven by volunteers, out of intrinsic motivation. Such mode of operation creates excellent results -- if you work on something because it makes you happy, and not because you have to, you make 10x impact, even if you spend 0.1x time. For many people, one of the easiest way to suck the happiness out of the work is to start thinking "gosh, I really could have done that better" or, worse "I should have done that better". It's important to show path to become a better rustacean, but I think it's important to make this strictly optional.

To give an example, let's say I maintain a project and I get an issue report before my first cup of pu'erh that makes my blood boil and makes me want to leave a curt RTFM response. If I score A+ on being kind and bringing joy to the user, I should proactively step in, emphasize with the reporter, diffuse the tension and get to the actual problem. However, by blood's boiling, so I chose to say nothing instead.

Now, if the values say just that I need to be kind and bring joy I might starting to hate myself for not being a perfect rustacean, or I might force myself to pretend to be one, and feel uncomfortable afterwards. I'd love to have an explicit allowance to drop the balls on the floor in the values -- I think I've been very successful at that, but it was a non-trivial deduction for me to realize that not being perfect doesn't make me a bad maintainer.

Here's another example. Let's say you send some PR with an improvement, and then maintainer asks you to change something. You say "I'll do that on the weekend", but you don't and postpone until the next one. Two weeks later, you still haven't done what's "promised", and you now want to reply "hey, I don't have time for this after all", but you should have done this a week ago. So you postpone not only the work, but that comment as well, and next week the situation is even worse. (that was the story of my very first PR to an open source project). I think it should be explicitly OK to just disappear from the PR, without notice. This actually makes leaving the notice easier, as now you don't have to, you just can, if that makes sense. This second example is "it's OK to not follow through".

That being said, that's more nuanced than just making the value optional. Some things you just shouldn't do, and, in the first example, leaving a mean response would definitely be a no go. Except that it's even more nuanced than that: people make mistakes, and it's OK to make them sometimes, if you acknowledge it.

So, yeah, I'd love to see something explicit along the lines of (but toned down quite a big):

You don't have to be perfect. These are the values which we think make the Rust community better. But it doesn't mean that you need to make the community better in every possible way, your personal happiness is more important. If you feel that some of these values don't align perfectly with the way you prefer to work, that's fine, as long as you follow the code of conduct.

35 Likes
3

Love this. Thank you. <3

11 Likes
4

I must admit I haven't read the whole thing, so please feel free to disregard. Sorry if this has already been addressed.

Meta-thought: principles need to rely on something measurable. It's too easy to convince oneself that you and the community around you is virtuous if the virtue is not really grounded in something you can see and do daily with your own eyes and hands. So ideally the principles will read less like a set of commandments and more like a how-to manual.

Not a critique of Niko's work, just an instinctive reaction to principles as a concept :slight_smile:

2 Likes
5

So— @matklad, I’m thinking about the concern that the "How to Rustacean" section is going to stress people out. I'm pretty sensitive to that. It's certainly not what I hope for, but I can imagine it having that effect, and in that case I think it would be a bad thing.

It seems clear that no actual, fallible person can embody all these behaviors all of the time. I know for sure that I don't. I see this as us trying to be clear about what we are striving for: a goal, not a minimum bar. I’m wondering how that can be better communicated and if you think that doing so might help, or does this seem like an inherent danger of having listed principles?

On a related note, one thing that I was thinking after reading your post was that we should have “be gentle with yourself” and “be gentle with others” as the first two principles.

5 Likes
6

One way to illustrate those characteristics as a goal or ideal is to attribute them to a fictional character. It could be presented something like, "What would Ferris do?"

8 Likes
7

That’s interesting!

8

It’s pretty important to me that the principles not be abstract. I was figuring that examples, stories, and quotes would be the best way to make that things concrete. I don’t know how much we’ll be able to find measurable quantities for everything.

2 Likes
9

On the meta I do think that even having principles creates an opportunity for there to be an explicit in group and out group. A yard stick that you can hold up and say "That's Not Rustacean" or "you're not Good Enough to contribute." While that can be used to curb undesired behaviour, I worry it can be used to exclude more than help.

Which is why it's surprising not to see Inclusivity (yes, with the paradox of tolerance caveat) as one of the core values of these principles. Imo that is one of the strongest values of the community, and it's not quite captured by "Be kind."

Principles are well and good for projects (read: tangible outcomes in the product), like the first section is aiming at, but I am less convinced of utility for communities (abstract and vague, about people rather than things), as does the second section. Maybe it's a bit redundant with the CoC?

I'd also like to see some scoping for those principles, too (not necessarily in the text). The preface is a start, but it's unclear where the principles should start and cease to apply. Are they about the Rust Language project, projects under the umbrella or purview of Rust teams and WGs, projects contributing to "the Rust experience" even outside of these (I don't recall names but there are a few contributor crates mentioned in The Book, for example, maybe pin-project, that kinda thing).

While not directly related, it could be worth to state or restate the mission statement for Rust, not just a foil to present the principles, but as an overarching "this is what we're all working towards, and these principles guide us on the journey" kinda thing. Perhaps every principle should hark back to it, eg "do X, because it works towards The Goal" but that feels a bit overdone.

The case studies make exemplify that every outcome is "a delicate balance", but that "not everything is required" should really be bold and upfront. At the same time, what threshold should there be? Is something that is average in every aspect but very positive in one valid?

More on the concrete side of things, there could also be examples of, say, "wrong moves." Maybe some examples of "red flags" that indicate something isn't quite right, and a design or interaction should be reconsidered.

2 Likes
10

What exactly is a "Rustacean" ? Is it someone who's involved in the rust-lang projects? Or is it someone's who's involved in the broader global rust community? To me it's the latter, but as I read your blog post it seems to read in the more narrow former case. That said, these "How To Rustacean" principles seem to be ones that we would like to foster in the wider global rust community, and I personally have enjoyed and benefitted from others embodying these principles as I wander through the rust world.

7 Likes
11

I agree with the idea that inclusivity is missing. I’m thinking a bit about it — one of the things I was trying to do in the first part is to create a kind of “cascade” of themes. The overall goal (“empowerment”), the feelings or qualities of a design that create that (“reliability, etc”) and mechanisms that engender those feelings (“type safety”).

The “How to Rustacean” section doesn’t have that structure, but I think maybe it should. I suspect that the overall goal is the same — empowerment (of people to contribute and shape Rust’s direction) — and “included” or “inclusive” is one of the ways that we create that result.

1 Like
12

I am also inclined towards the broader definition. A guide for how a wider community is expected to behave (should they choose to get involved) is important and helps to establish positive behaviors and good practices.

At the risk of seeming judgemental, no man is every-man and therefore what they contribute is necessarily limited by their experience. I guess that's why diverse and inclusive teams are so important.

1 Like
13

Yes, this is a good question, and I was deliberately somewhat ambiguous. It may be that it would be good to retool the page to be more narrowly tailed, but I’m not sure!

As you said, I think it would be great to have principles that “set a tone” for the broader community. I’m reminded of how Apple publishes Human Interface Guidelines and other things that help 3rd party app developers create things that feel more harmonized with the platform as a whole (caveat emptor about whether Apple follows its own guidelines etc). Something like the libs team’s Rust API Guidelines have a similar effect.

So I guess my hope is that I think we should create principles that are primarily driven by the Rust project’s needs, but that I would like to think that others may find inspiration in them. Even within the Rust project, to be honest, I see the role of this page not as something “proscriptive” (thou shalt do this), but more like something inspirational and aspirational.

The other thing I’ve pondered is that there’s such a continuum between “Rust user” and “Rust team member”. Is someone who posts on twitter a “Rust developer”? Who comments on internals? Who comments on an RFC thread? Who opens a PR? Who writes a blog post? I feel like any one of those things could be an interaction that ultimately leads to someone becoming a really influential part of Rust’s direction, and so I would like to think that we could create guidelines for how to engage with poeple that are useful to all of them, even if they become more and more relevant the deeper you get in the project.

Thoughts?

3 Likes
14

(Heh, re-reading I see that you were suggesting more or less the same thing that I did. I think this is a good idea, yes.)

1 Like
15

This makes a lot of sense. I think the page could benefit from some explicit text to this effect. This also touches on the point you made later:

Agreed, this is interesting to think about. The broader rust community itself is a bit like a collective member of the rust team, since the core rust team depends on them for so much (bug reports, PRs, RFC comments, all the things you mentioned).

1 Like
16

One point that was raised that I’m thinking about:

  • The first set of principles are kind of a “contract” between Rust and its users (using Rust, you’ll get reliability, performant, etc)
  • The second set of principles is kind of a “contract” between Rust team members and contributors.

Perhaps it’s confusing to combine them in the same document, or at least they should be more clearly separated.

I was toying yesterday with restructuring the second section so that it had a similar “feel” to the first one:

I’m curious what people think of this direction. I kind of like it, but I have to experiment more with the right set of adjectives, and it may be that we can’t always find a single adjective to describe the thing we are going for.

1 Like
17

Makes sense

18

It seems to me that these two remarks don't make sense together. Personally I don't like it when the distinction between Rust team members and other ecosystem contributors gets emphasized, because I don't think team membership is, in the large, a very important characteristic in terms of contributing to our ecosystem. So in that sense, I feel that the very notion of "Rust team members empowering contributors by being inclusive" is not inclusive.

Which is not to say that the second section is not valuable, I just think the distinction you're aiming for is more between what is laid down in code vs what is in human interactions.

19

I agree with this too =) There is a tension there that I’m trying to unravel. Partly this gets at what is the role of a team member in the first place. I thought @mara made an interesting point in her RustConf talk about the primary role of teams being empowering contributors. I feel like we sometimes paint teams as being “the people who do the work” and we sometimes pain them as enabling. I tend to think it’s correct to think of the role of a team member being guiding, both in terms of setting direction but also in terms of helping mentor folks, provide reviews and feedback, etc. Of course many team members also contribute, but they are playing a different role in that case (e.g., when I write a PR, I am acting as a contributor, not a team member).

3 Likes
20

One possible context to unify these two is: "When you sign up for rust, this is what you get". Meaning you get all this stuff from the language (reliability, type safety, etc), and you get all this stuff from the community (inclusiveness, respectfulness, etc). This is probably a bit of a stretch, since someone "passively" using rust is not going to interact with the team in the same way a contributor would. But maybe there's something to be said about a "passive" user still might be an observer in some way that relates to the team/contributor interaction.

I'm not sure how strongly I believe this, but perhaps it's an interesting point for discussion

1 Like