Not quite. On Linux (and other Unices), there’s an “executable” permissions flag for every file on the filesystem. If that flag is set for you, the file is executable. The location of the file makes little difference, except that /bin and /usr/bin are on the default search path when the user doesn’t specify a full path to the program.
2 Likes
Sorry, I may have been a bit over-zealous.
Still, you don't need .exe on Windows either, it's just a convention. I would argue that all executables being installed into **/bin locations, at least on most LInux distributions, is a similarly strong convention.
Linux executables function without being in **/bin locations, but all package managers I know of, and even most independent downloadable have bin directories in which the executables are located. I'm not arguing it's a 100% required practice, only that it's a convention equivalent to the exe convention on Windows.
1 Like
Using Visual Studio for Windows, there is the convention of putting all generated executable files, both programs and libraries, in an "obj" or a "bin" folder. The "obj" folder is for intermediate files, the "bin" folder is for final files. This is because even compiled libraries (both ".lib" and ".dll") are binary files, albeit not executable. Instead, for Cargo and Rustc, "bin" excludes binary libraries.
I'd much rather see the things based on POSIX and the FHS, than a single company's proprietary OS, i.e. MS Windows.
bin is for executables
lib is for libraries
1 Like
We seem to have strayed away from the topic of why the current defaults were chosen into what they should be. As such, I’ll throw my hat into the ring and say that they should stay the way they are: The inconsistency of having some crates use a new convention and other crates using the old one will probably cause greater confusion across the developer community than any of the choices that have been presented.
A basic tenet of group decision making is to not revisit decisions until there’s been a change in circumstances that might render the previous arguments invalid. In the absence of such a change, rehashing the previous discussion just distracts the group from addressing all the things that haven’t been decided yet.
17 Likes
+1 to OP for noting the terminology that might confuse newcomers unfamiliar with the historical context, but I agree with post above that we should simply embrace the decision and roll with it to avoid confusion. Most programmers won't get hung up on the semantics of the already overloaded term "binary".
My preference would be to use pure hierarchical workspaces with clearly specified crate types, instead of a convention like src/bin, but everything is work in progress.
1 Like
No, that is not true. All executables may not always be placed into <somewhere>/bin and it is not necessary that all files in <somewhere>/bin is an executable. An executable is have the executable bit set which makes it an executable, not necessary being in <somewhere>/bin.
Personally, I think src/bin is as clear as my future. 
src means source code and bin means executable, having both means the source code of an executable. I find it very intuitive and I understand it at first glance, but this may not be true for people coming from windows.
Same for what other people think "obj" and "exe" and "app", I don't understand what they means. I probably cannot guess the meaning if it appear, "obj" means object? "exe" means executable? "app" means web app? IMHO "bin" is clearer than any of those coming from *nix.
So I would say, it depends on the people background. But probably I wouldn't care as much even if it was named "xxx" as first when people are already used to it, changing it does not seemed to provide much benefit other than clarity, I rather wish for feature like out-of-bounds free or faster incremental compilation time.
1 Like
No, we can't do this 
(or at least I will call it that way when I find appropriate)
The terminology is used to describe an abstract idea.
It greatly depends on the person you're talking to, what you're trying to describe and at what level (from code abstractions, ideas, implementations, architecture and many more).
Talking to children that have the concept of "app" or older people that are not so familiar and far far faaaar from programming 
is also something you need to account for.
Is that ageist, stereotyping myth still going around?
I don't get to meet so many young people now a days but in my experience, unless I'm dealing with a software shop, the youngsters I meet have far less idea about what a computer is and about programming that a lot of my generation. We were weened with computers in our bedrooms and were soon fluent in BASIC and often assembler.
Heck, even my father who was well into his retirement in the early '80's started programming in BASIC, he had never seen a computer in his life!
There must be something in the code of conduct here about this 
Happy apping
3 Likes
Let me clear this up: I was referring to the fact that it depends who you're talking to. I like to explain stuff to people that don't understand programming, share my knowledge, and one of the things you should account for is age as well.
Don't take this personal, because I am not referring to you in any way.
PS: I've been subject to ageism as well.
1 Like
No worries.
I do get your point about context and the audience one is addressing.
1 Like
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.