I find it confusing that there is a directory called src/bin. A "binary file" is the compiled code, not the source code.
Something like src/app would be more reasonable.
1 Like
This name is used elsewhere in Cargo in --bin and [[bin]], so changing it would be very disruptive and just create more inconsistency.
On macOS app means something else than a CLI binary, and Cargo lacks features required to build actual macOS apps.
1 Like
It's the source that produces a binary.
If it were src/app, you could just as well complain that an application is the compiled code.
2 Likes
The bigger issue is that libraries also get compiled into a binary format. Also binary being the base system used by everything. They're executables.
2 Likes
I understand the rationale.
The reason this is confusing is that the word "binary" essentially means "not human readable", so the adjective is basically saying "not the source code".
When I write C++ code, I usually have two separate directories: src for the source code files, bin for the compiled object files and executables.
Yeah, that a library isn't considered a "binary" is also confusing.
I guess the language has evolved in this strange fashion -- a "binary executable" has been shortened to "a binary".
I'm just pointing out how confusing this is unless you're already used to it. I'm not sure I have a better naming scheme.
2 Likes
To be fair, the word binary is a highly overloaded homonym:
- The mathematical number base for which only 2 symbols are needed for representation of numbers
- File encodings that make use of point 1
- Executable files that make use of point 2
- Defined as an antonym to the property of human-readability
Those are just off of the top of my head. It matters because everyone will likely think of a different subset of the points above when taking about binary/binaries.
8 Likes
I don't think we can avoid such kind of "alternative" interpretation of the directory name.
If we have src/SOME_PRODUCT that contains the source code that compiles into SOMETHING, then some will think "hey src/SOME_PRODUCT/foo.rs is not SOME_PRODUCT itself!"
src/bin, src/app, src/exe, src/command, etc. are in this category.
On the other hand, if we have src/SOURCE_ITSELF, then it would be redundant or totally useless.
For example, src/source_of_foo_command is redundant since it is in src/ directory, or src/rust_src is... of course useless!
And if we give up using such dedicated explicit directory names for the source code of executables, navigating the source would be bothering. We cannot know whether src/foo/bar.rs is part of the source of an executable or not, until we check the existence of src/foo/main.rs or main() function!
So, I don't think there are perfect solution or even there is no better solution to this problem, and I believe the current src/bin way is reasonable choice. Other src/SOMETHING will also be reasonable, but it won't be worth introducing big changes to the ecosystem.
The reason this is confusing is that the word "binary" essentially means "not human readable", so the adjective is basically saying "not the source code".
Calling executables bin is very popular terminology especially in *nix world (but not limited to it). /usr/bin contains bunch of shell scripts (of course they are plain texts) and http://.../cgi-bin/foo.cgi might have been a Perl script in the old days, which is also plain text.
3 Likes
I disagree.
For example, if it was src/program/tic_tac_toe.rs (or src/command, or src/app), what is inside really is a program. It is written in Rust, but that is a valid way to describe a program.
target/release/tic_tac_toe is the same program in machine code. Both are valid ways to write the program, one is just a translation of the other into another language (Rust to machine code).
Whereas when you say bin, that rather strongly suggests it is something in a binary format rather than in text format (i.e. machine code qualifies, Rust doesn't).
1 Like
On Windows "program" may mean the built form (there's Program Files), and "command" can mean binaries too (.com files).
OTOH on most unixes /bin contains many programs in a textural/source code form (bash, perl, python).
In npm, source code for programs is in bin/.
The term "bin" has just been diluted, and is used to mean CLI programs in general too.
When I write C++ code, I usually have two separate directories
Every C++ project is different. Make will build executables in the same dir as the source file, so I've seen projects that build src/compiled.exe.
2 Likes
In OCaml, the sources (ml, mli) go into 'bin', libraries into 'lib' and the binary is in '_build'.
One "explanation" for the source to be in 'bin' was "You are building a binary".
I quit giving OCaml a try about a month ago.
My guess is one comparison point for this design was the bin field for npm packages, which similarly declares what gets added to your path (to handwave it a bit)
If you think of "bin" as meaning a bin (container for storage), then the oxymoron vanishes.
On Windows, "executable" is the generic term for referring to files containing, well, executable code (this term of course stems from the MS-DOS era 40 years ago), so we have .exe files that are in PE (Portable Executable) format. "Program", then, is (usually) an executable plus its supporting files (if any), ie. something that traditionally has its own folder in Program Files and is installed or removed as a single unit.
Seems to me we should have defined this recursively.
When I build a program I find its source in my_prog_name/src. Specifically my_prog_name/main.rs and other files beside it there.
So when I have some kind of nested program it would be natural to find it in
my_prog_name/src/my_sub_prog_name/src where there would be my_prog_name/src/my_sub_prog_name/src/main.rs and friends
In this way those subprograms get a main.rs of their own. Which is consistent with the main main. If you see what I mean. And each subprogram gets its name from the subdirectory it is in, which is consistent with the main program gets it's name program.
So we have:
my_prog_name/src/main.rs
my_prog_name/src/sub_prog_name_1/src/main.rs
my_prog_name/src/sub_prog_name_2/src/main.rs
...etc
Let's not use "app". I don't write apps. I write programs.
1 Like
Many people are doing the rust development on a unix-like machine, and in the context of a directory in a unix-like file system, bin most definitely means the directory that contains the executable files (that some executable files, e.g. perl or python programs, are human-readable rather than binary is not relevant, they are executable by having a #! interpreter).
There is (at least) one project for creating executable rust scripts, by using a specialized cargo wrapper as an interpreter. Such rust scripts would indeed be apropriate in a bin directory. But the rust sources typically found in the bin directory of a rust project are not executable and should not be in a bin directory of a unix-like file system.
So @tczajka very much have a point that bin is not an optimal a somewhat surprising name. Unfortunately, @kornel also have a very valid point that changing it would be very disruptive by now, so I guess it will have to remain. Maybe a section explaining the historical accident would be a good addition to the rust (or cargo) book.
5 Likes
Yes! I started to get sick of this term.
In that case, can't we all just be honest with ourselves, and call it \src\bugs or \src\technical_debt? 
8 Likes