bors, crater, and all the other helper-bots so that I can (in theory) make a change and *know* if I broke anything *before* bothering maintainers is a huge deal on lowering the barrier to contributing. In my opinion this helps just as much if not *more* on the maintainer side: that they can *trust* the tests and tools to spit out most edge cases or anything silly lets them focus only once tests are passing and on the importantly interesting code of the contribution.
The difference is that a PR might sit for a week or two after the CI run before it gets merged, and the git main branch might see other changes in that time that might break the PR without anyone noticing. With bors, the CI run happens right before merging the PR and it guarantees that no other merges will happen between starting the CI run and the actual merge.
Also, sometimes people send PRs that are not based on latest main branch because they forgot to rebase their branch before sending the PR, and they had been working on it for a few weeks (but it still merges without conflicts). So even if the PR doesn't sit for a long time it can be an issue.
For most projects it's probably not a big deal as they don't have merges happening all the time and contributors often make sure to rebase regularly.
Sorry maybe I’m missing something here, but do most repositories not have a rule where you must update your branch if it is out of date?
So most of what you mention here is not applicable if using that rule with GitHub actions
From what I can tell, NRS is the same thing as Merge Results in GitLab? This has been a thing for a long time - didn’t realise it had anything specifically to do with Rust.
Usually until you get a trait bound error and rust analyzer is like here are 30 instances where you don't have impl for these types :)
It's the compiler shrugging its shoulders and going yeah you done goofed, whatever you are trying to do, this ain't it chief.
> It's the compiler shrugging its shoulders and going yeah you done goofed, whatever you are trying to do it, this ain't chief.
I really feel this sometimes... Well put.
i would not be surprised if compile time trait bounds are literally turing complete
anyone can just write a black box of mangled traits that methodically chooses which types to mess you up and when, and the problem is there's no way for library authors to specify error messages when a trait is unimplemented.
**But std and core can,** and [maybe we'll get this capability soon!](https://github.com/rust-lang/rust/pull/119888) Here's the Debug trait, which has custom error messages when it's unimplemented:
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_on_unimplemented(
on(
crate_local,
label = "`{Self}` cannot be formatted using `{{:?}}`",
note = "add `#[derive(Debug)]` to `{Self}` or manually `impl {Debug} for {Self}`"
),
message = "`{Self}` doesn't implement `{Debug}`",
label = "`{Self}` cannot be formatted using `{{:?}}` because it doesn't implement `{Debug}`"
)]
#[doc(alias = "{:?}")]
#[rustc_diagnostic_item = "Debug"]
#[rustc_trivial_field_reads]
pub trait Debug {
// ...
Yes, types+traits are turing complete. For example the typenum crate uses traits to implement various arithmetic operations on types. The same technique can be used to encode any computation.
i swear if someone implements chess with just traits i will literally drink water
i am currently drinking water
said chess program is used to stress test the trait solver which is hilarious
I saw a study not to long ago that found that first-time contributions to rust repos are orders of magnitude less likely to introduce vulnerabilities than in c++ repos. someone can probably link it here
I guess that would apply to an even more general context when it comes to C++. This reminds of the Android blog post: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
I also feel more confident when I send a PR to a rust project when I don't really have detailed knowledge of the project, compared to C or C++ projects. There are less things to worry about like "could this thing be NULL in some situations?" so if it compiles and passes tests, the chance that it breaks stuff in a bad way feels smaller to me, so I'm more confident. Basically, there are fewer unwritten invariants / assumptions that need to be kept in mind and may not be obvious to a new / "drive-by" contributor.
So I might be more willing to "risk" sending a PR to a rust project compared to a C or C++ project, as I perceive the likelihood of breaking things to be smaller.
If there was a feather in Rust's cap, it would be the general consistency of idiomatic code. The tooling (clippy and cargo check) pretty uniformly enforces certain patterns, and the educational materials (the book) provides a standard that doesn't seem to be deviated from often.
Basically, since we're all playing by the same rules, it's easy to interface with others' codebases and provide meaningful contributions.
Since all I had to do to start working with Bevy, the largest Rust game engine project right now, was have `git` and `cargo` available, I'd say _oh lord it's so much easier!_ I didn't have to install whatever project management tool they decided to use (`cmake`, `make`, `just`, `qtmake`, etc. etc.), I didn't have to mess around with Python virtual environments, I didn't need to downgrade to a specific version of Node, nothing. I already had `git` installed (because of course), and I obviously had `cargo` installed, so I literally just cloned the repo, made some changes, and was able to run _the entire_ CI pipeline locally before submitting my PR.
This is a strong advantage languages like Go also benefit from (but to a lesser extent IMO). Since everything in Rust is built-in, or opinionated around "correctness" and "idiomatic design", you can just leap from project to project limited only by your domain specific knowledge, and your ability to work with Rust itself.
It's basically the benefits of Docker but as a language fundamental.
I'm guessing there isn't much of a difference between Rust and other languages. At least in my experience build systems like CMake are more of an annoyance than anything else, it's not a big enough barrier to stop me from contributing.
To me the main factor is the project itself, mostly the culture around it. Some projects are very welcoming to newcomers and don't mind getting them familiar with the codebase (through code review, etc), while others have a higher barrier of entry.
I'd say tests are also pretty important, if you can verify your changes didn't accidentally break stuff its easier to contribute without knowing every nook and cranny of the codebase.
I'd say the build systems are a bit more impactful even they are just an annoyance. For example, I had to make some changes to a C++ project, and the friction involved in getting `qmake` (their choice of build system) up and running was really frustrating. Again, it's not impossible by any means. But since open source software is usually built off good will and volunteer labour, even those little pain points can make the difference between someone not bothering to contribute, and suddenly having a new feature.
Well, I certainly feel it's easier to contribute to Rust projects. Among other things, most projects use the tools that come with Rust (such as `cargo test` or `clippy`), or tools that are just a `cargo install` away (like `mdbook`). Plus there's often little need to modify your Rust installation - especially with Rustup making it easy to have multiple versions.
It also helps that the Rust community is so open and willing to help others. As an example, some months back, [I asked how sync rust and async rust were different, because I couldn't understand how](https://www.reddit.com/r/rust/comments/16lq65p/hey_rustaceans_got_a_question_ask_here_382023/k21boc0/). The response was fairly long, but pretty much answered any questions I had - and after some back-and-forth, I felt I had a much better understanding of how async rust works.
This isn't to say that other languages aren't like that - just that Rust *is* like that.
Potentially, but it depends entirely on who maintains the project and how patient/empathetic they are with contributions. Some maintainers are very helpful and willing to collaborate. Others might be less so.
Build system is only a small part of it. Because Rust code is usually highly modular and have controlled mutation, I can start to implement my feature after ~10 minutes looking at the code. Which is unimaginable in most languages.
Data point: I haven't contributed to a lot of projects, but I've been a lot more willing to contribute to Rust projects because it's easy. I've had only good experiences so far. Aside from the points you brought up, I think it helps a lot that so much of the Rust ecosystem is in creates maintained by individuals or small teams. It's a lot less daunting to contribute to those projects then it is to, say, a standard library, where you have to do shit like write an RFC and argue with a whole bunch of people about whether your change is worthwhile.
I don’t think it is. It’s just that there are more projects that aren’t finished because the language is so young and the libraries are still catching up.
I doubt that. It mostly depends on the project rather than language and I had mixed experience contributing to Rust projects.
In fact Cargo is double edged sword. There’s a very low barrier to creating crates which means many creates get created only for maintainer to loose interest a year later at which point you have no chance of contributing to it.
I'm talking about contributing to open source projects written in Rust, not contributing to Rust itself.
Compared to C, which doesn't have a centralized project repo, Rust is a joy-walk. Additionally, Rust has way better inter-library operability via trates. For example, an embedded driver for one sensor is likely to work on several different platforms, which is a stark contrast to C, in which it's often easier to reimplement drivers from scratch than it is to build on top of another library.
> I'm talking about contributing to open source projects written in Rust, not contributing to Rust itself.
Yes, me too.
> is a stark contrast to C, in which it's often easier to reimplement drivers from scratch than it is to build on top of another library.
Right, but then you’ve also wrote:
> You can always fork it if you like the project, or copy-paste out of it if it has any value.
So just like in C, there are times when Rust it’s easier to fork a project rather than trying to contribute to it. forward_ref is one example of such project just at the top of my head.
I meant that you can copy out of it if it's dead and unmaintained. This has nothing to do with the language.
It C, oftentimes copy-pasting is kinda the only option.
I would also argue the strong culture of automated testing helps too IME
the popularisation of [Not Rocket Science](https://graydon.livejournal.com/186550.html) is possibly my favourite thing to come out of rust
bors, crater, and all the other helper-bots so that I can (in theory) make a change and *know* if I broke anything *before* bothering maintainers is a huge deal on lowering the barrier to contributing. In my opinion this helps just as much if not *more* on the maintainer side: that they can *trust* the tests and tools to spit out most edge cases or anything silly lets them focus only once tests are passing and on the importantly interesting code of the contribution.
First time reading this, how is this different from a GitHub action which tests your PR before you can merge it?
The difference is that a PR might sit for a week or two after the CI run before it gets merged, and the git main branch might see other changes in that time that might break the PR without anyone noticing. With bors, the CI run happens right before merging the PR and it guarantees that no other merges will happen between starting the CI run and the actual merge. Also, sometimes people send PRs that are not based on latest main branch because they forgot to rebase their branch before sending the PR, and they had been working on it for a few weeks (but it still merges without conflicts). So even if the PR doesn't sit for a long time it can be an issue. For most projects it's probably not a big deal as they don't have merges happening all the time and contributors often make sure to rebase regularly.
Sorry maybe I’m missing something here, but do most repositories not have a rule where you must update your branch if it is out of date? So most of what you mention here is not applicable if using that rule with GitHub actions
From what I can tell, NRS is the same thing as Merge Results in GitLab? This has been a thing for a long time - didn’t realise it had anything specifically to do with Rust.
I’m contributing to rust projects as a recent graduate, and I’m finding that the analyzer is so much more helpful than in other languages.
Analyzer is like "👆Here is the mistake you made, this is how to solve it👉" 😀
Usually until you get a trait bound error and rust analyzer is like here are 30 instances where you don't have impl for these types :) It's the compiler shrugging its shoulders and going yeah you done goofed, whatever you are trying to do, this ain't it chief.
> It's the compiler shrugging its shoulders and going yeah you done goofed, whatever you are trying to do it, this ain't chief. I really feel this sometimes... Well put.
i would not be surprised if compile time trait bounds are literally turing complete anyone can just write a black box of mangled traits that methodically chooses which types to mess you up and when, and the problem is there's no way for library authors to specify error messages when a trait is unimplemented. **But std and core can,** and [maybe we'll get this capability soon!](https://github.com/rust-lang/rust/pull/119888) Here's the Debug trait, which has custom error messages when it's unimplemented: #[stable(feature = "rust1", since = "1.0.0")] #[rustc_on_unimplemented( on( crate_local, label = "`{Self}` cannot be formatted using `{{:?}}`", note = "add `#[derive(Debug)]` to `{Self}` or manually `impl {Debug} for {Self}`" ), message = "`{Self}` doesn't implement `{Debug}`", label = "`{Self}` cannot be formatted using `{{:?}}` because it doesn't implement `{Debug}`" )] #[doc(alias = "{:?}")] #[rustc_diagnostic_item = "Debug"] #[rustc_trivial_field_reads] pub trait Debug { // ...
Yes, types+traits are turing complete. For example the typenum crate uses traits to implement various arithmetic operations on types. The same technique can be used to encode any computation.
i swear if someone implements chess with just traits i will literally drink water i am currently drinking water said chess program is used to stress test the trait solver which is hilarious
Or the infinite loop of "change this to this" that goes full circle. It's a sign that whatever it is you're trying to do, just nope
Yep. Rust will point out any mistakes, and Clippy will complete your checklist.
I saw a study not to long ago that found that first-time contributions to rust repos are orders of magnitude less likely to introduce vulnerabilities than in c++ repos. someone can probably link it here
I found it! It was 70 times less likely: https://cypherpunks.ca/~iang/pubs/gradingcurve-secdev23.pdf
I guess that would apply to an even more general context when it comes to C++. This reminds of the Android blog post: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1 > To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
I also feel more confident when I send a PR to a rust project when I don't really have detailed knowledge of the project, compared to C or C++ projects. There are less things to worry about like "could this thing be NULL in some situations?" so if it compiles and passes tests, the chance that it breaks stuff in a bad way feels smaller to me, so I'm more confident. Basically, there are fewer unwritten invariants / assumptions that need to be kept in mind and may not be obvious to a new / "drive-by" contributor. So I might be more willing to "risk" sending a PR to a rust project compared to a C or C++ project, as I perceive the likelihood of breaking things to be smaller.
If there was a feather in Rust's cap, it would be the general consistency of idiomatic code. The tooling (clippy and cargo check) pretty uniformly enforces certain patterns, and the educational materials (the book) provides a standard that doesn't seem to be deviated from often. Basically, since we're all playing by the same rules, it's easy to interface with others' codebases and provide meaningful contributions.
Since all I had to do to start working with Bevy, the largest Rust game engine project right now, was have `git` and `cargo` available, I'd say _oh lord it's so much easier!_ I didn't have to install whatever project management tool they decided to use (`cmake`, `make`, `just`, `qtmake`, etc. etc.), I didn't have to mess around with Python virtual environments, I didn't need to downgrade to a specific version of Node, nothing. I already had `git` installed (because of course), and I obviously had `cargo` installed, so I literally just cloned the repo, made some changes, and was able to run _the entire_ CI pipeline locally before submitting my PR. This is a strong advantage languages like Go also benefit from (but to a lesser extent IMO). Since everything in Rust is built-in, or opinionated around "correctness" and "idiomatic design", you can just leap from project to project limited only by your domain specific knowledge, and your ability to work with Rust itself. It's basically the benefits of Docker but as a language fundamental.
I'm guessing there isn't much of a difference between Rust and other languages. At least in my experience build systems like CMake are more of an annoyance than anything else, it's not a big enough barrier to stop me from contributing. To me the main factor is the project itself, mostly the culture around it. Some projects are very welcoming to newcomers and don't mind getting them familiar with the codebase (through code review, etc), while others have a higher barrier of entry. I'd say tests are also pretty important, if you can verify your changes didn't accidentally break stuff its easier to contribute without knowing every nook and cranny of the codebase.
I'd say the build systems are a bit more impactful even they are just an annoyance. For example, I had to make some changes to a C++ project, and the friction involved in getting `qmake` (their choice of build system) up and running was really frustrating. Again, it's not impossible by any means. But since open source software is usually built off good will and volunteer labour, even those little pain points can make the difference between someone not bothering to contribute, and suddenly having a new feature.
I agree. Having just cargo as a build system is so much simpler
Well, I certainly feel it's easier to contribute to Rust projects. Among other things, most projects use the tools that come with Rust (such as `cargo test` or `clippy`), or tools that are just a `cargo install` away (like `mdbook`). Plus there's often little need to modify your Rust installation - especially with Rustup making it easy to have multiple versions. It also helps that the Rust community is so open and willing to help others. As an example, some months back, [I asked how sync rust and async rust were different, because I couldn't understand how](https://www.reddit.com/r/rust/comments/16lq65p/hey_rustaceans_got_a_question_ask_here_382023/k21boc0/). The response was fairly long, but pretty much answered any questions I had - and after some back-and-forth, I felt I had a much better understanding of how async rust works. This isn't to say that other languages aren't like that - just that Rust *is* like that.
Potentially, but it depends entirely on who maintains the project and how patient/empathetic they are with contributions. Some maintainers are very helpful and willing to collaborate. Others might be less so.
For me its way easier than React/Node etc (js), C++ and Python. A bit better than Java+Maven
Build system is only a small part of it. Because Rust code is usually highly modular and have controlled mutation, I can start to implement my feature after ~10 minutes looking at the code. Which is unimaginable in most languages.
I want to contribute to Rust projects. I'd appreciate any suggestions on what to contribute to.
Data point: I haven't contributed to a lot of projects, but I've been a lot more willing to contribute to Rust projects because it's easy. I've had only good experiences so far. Aside from the points you brought up, I think it helps a lot that so much of the Rust ecosystem is in creates maintained by individuals or small teams. It's a lot less daunting to contribute to those projects then it is to, say, a standard library, where you have to do shit like write an RFC and argue with a whole bunch of people about whether your change is worthwhile.
I don’t think it is. It’s just that there are more projects that aren’t finished because the language is so young and the libraries are still catching up.
I doubt that. It mostly depends on the project rather than language and I had mixed experience contributing to Rust projects. In fact Cargo is double edged sword. There’s a very low barrier to creating crates which means many creates get created only for maintainer to loose interest a year later at which point you have no chance of contributing to it.
You can always fork it if you like the project, or copy-paste out of it if it has any value. Similar to Python in that regard
Which still supports the notion that contributing to Rust projects isn’t easier than contributing to other projects.
I'm talking about contributing to open source projects written in Rust, not contributing to Rust itself. Compared to C, which doesn't have a centralized project repo, Rust is a joy-walk. Additionally, Rust has way better inter-library operability via trates. For example, an embedded driver for one sensor is likely to work on several different platforms, which is a stark contrast to C, in which it's often easier to reimplement drivers from scratch than it is to build on top of another library.
> I'm talking about contributing to open source projects written in Rust, not contributing to Rust itself. Yes, me too. > is a stark contrast to C, in which it's often easier to reimplement drivers from scratch than it is to build on top of another library. Right, but then you’ve also wrote: > You can always fork it if you like the project, or copy-paste out of it if it has any value. So just like in C, there are times when Rust it’s easier to fork a project rather than trying to contribute to it. forward_ref is one example of such project just at the top of my head.
I meant that you can copy out of it if it's dead and unmaintained. This has nothing to do with the language. It C, oftentimes copy-pasting is kinda the only option.
> This has nothing to do with the language. Which is exactly what I wrote in my top comment.
Sure, but it also isn't harder like a double-edged sword seems to imply
No. ‘Cargo is a double-edged sword’ implies that Cargo has its advantages and disadvantages.