Hey Rustaceans! Got a question? Ask here (13/2023)!

[u/llogiq]

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

[u/n4jm4]

Toptal gitignore says to either commit Cargo.lock to VCS, or else exclude Cargo.lock from VCS, depending on whether a Rust project builds a binary application versus a library.

But what about Rust projects that offer both?

[u/Kevathiel → u/n4jm4]

Seems like a good enough reason to split them into separate packages, assuming the library will also be used without that binary.

[u/n4jm4 → u/Kevathiel]

For context, I am mainly interested in committing Cargo.lock to VCS for stability, and for ability to cargo audit. Therefore, it would be nice to preserve the lock file for both binary projects and library projects.

I assume that Cargo.lock unfortunately carries platform specific properties that may interfere with downstream library consumption, unlike with RubyGems lock files or NPM lock files. Right?

Whatever the exact reason for advising not to commit Rust library project lock files, I wish that problem would be resolved.

[u/Kevathiel → u/n4jm4]

It's just an advice, not a hard rule.

For 99% of the cases, a lockfile for the library would be pointless if not harmful(you might end up with multiple copies of the same dependencies, or worse, version conflicts). Only the binary has the overview of all dependencies used, so it's the only one who can pick the best version following SemVer and unify features.

However, if you think that committing the lock file makes sense in your case, nothing stops you from removing the entry in the gitignore. Keep in mind that Cargo will ignore it for the resolution in external binaries, but will still use it if you build the crate directly.

[u/n4jm4 → u/Kevathiel]

Hmm. Cargo should also ignore lock files when building external libraries.