Is there any standard project layout for Rust? (like https://github.com/golang-standards/project-layout)
You should use cargo and it will set up standard project layout for you.
There's also a few other folders/files that Cargo will recognize that aren't generated by default - see the Cargo guide.
I meant the structure inside the 'src' directory, is there any guide (standard) about it?
please check the link I attached to my question which is used to start a Golang project
I don't see why it would be needed. The page you quoted says "As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state." I don't see how this could happen in rust. No dependencies within a crate can be hidden unless you use a
* import (which you shouldn't basically ever), and global state is hard to introduce (requires
lazy_static and a Mutex) and in any case has nothing to do with project layout. I'm not saying that there aren't judgement calls to be made, e.g. when it's worth breaking a bit of code into a separate module, and when to bother reexporting something to shorten the import path. But when these are important it is usually are a question of good API design rather than good project layout, and the two after relatively orthogonal, since it's not uncommon to have a private module for project layout that m and then to export a different structure for the API.
A regular project consists of internal modules, public modules (could be used in other projects), assets, build files, API files and so on, the link I mentioned provides a good guide for managing the layout of project. I am looking for a similar guide to manage these sort of files
there is a
cargo vendor subcommand that will copy dependencies into your src folder (I think). Then files with special meaning are
bin/*.rs. Where lib is a library, and the other 2 are binaries.
Apart from this, just organise your code how you want to. The way I do it is to not have any modules at all until I think things are getting hairy, then maybe refactor stuff out.