One of the reasons i find it so hard to use non-Rust languages is how ugly they typically are by comparison. “fn” instead of “function” is such a great example of saving key presses where they’re most needed. And you get very used to seeing compact abbreviations. Idk if that’s what you’re talking about though.
“fn” was just one example. There’s also other abbreviations like “pub”, “impl”, “extern”, “mut”, “ref”, “bool”, “u64” And it’s true that some of these keywords are only relevant in Rust, however other langues have their own specific keywords, and they tend to be longer. In languages like Java (which is the worst example I can think of), you see things like “private static boolean” as function definition. In c++, you have to type “unsigned long” or even “unsigned long long” to represent “u64” (depending on data model).
C++ is even worse, due to templates and the so-called most vexing parse. Initializing with {} mitigated the latter somewhat, but came with its own set of woes
To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a bool, but rather the element that you removed, so like this:
I believe that it is useful in a few places. cppreference.com mentions templates as one case:
Trailing return type, useful if the return type depends on argument names, such as template<class T, class U> auto add(T t, U u) -> decltype(t + u); or is complicated, such as in auto fpif(int)->int(*)(int)
The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.
Additionally, the scope of the return type matches the function meaning that you can do
Ooh yeah, overall coding culture is definitely not affected by the preferred nomenclature for identifiers. The person who’s habituated to fn over function will absolutely never name their functions in the vein of chkdsk. The two are completely disconnected in the brain of the programmer who read too much K&R in their childhood and was irretrievably traumatized by it for life.
I’d say it’s much more influential the names of the identifiers of the standard library.
A language with function keyword that names it’s stdlib functions strstr and strtok will inspire way worse naming than on that has fn keyword with stdlib functions str::contains and str::split.
We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.
One of the reasons i find it so hard to use non-Rust languages is how ugly they typically are by comparison. “fn” instead of “function” is such a great example of saving key presses where they’re most needed. And you get very used to seeing compact abbreviations. Idk if that’s what you’re talking about though.
Rust:
fn getofmylawn(lawn: Lawn) -> bool { lawn.remove() }C:
bool getofmylawn(Lawn lawn) { return lawn.remove(); }With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.
“fn” was just one example. There’s also other abbreviations like “pub”, “impl”, “extern”, “mut”, “ref”, “bool”, “u64” And it’s true that some of these keywords are only relevant in Rust, however other langues have their own specific keywords, and they tend to be longer. In languages like Java (which is the worst example I can think of), you see things like “private static boolean” as function definition. In c++, you have to type “unsigned long” or even “unsigned long long” to represent “u64” (depending on data model).
Honestly, the Rust way of doing things feels much more natural to me.
You can read it as
getoffmylawn,Lawnargument namedlawn,boolWhereas the C function is read as
bool? Could be a variable, could be a function, could be a forward declaration of a function,getoffmylawn,(, so all options are still on the table,Lawnargument namedlawn, that returns abooltypes in C are pretty weird
int *acan be read as*ais a intais a pointer tointint *a, bis read as*aandbareintais a pointer tointandbis aintbool getofmylawn(Lawn lawn)getoffmylawn(Lawn lawn)is aboolgetoffmylawnis a function that takes aLawnand returns aboolAnd then you have function pointers
bool (*foo(int a))(float b)(*foo(int a))(float b)is abool*foo(int a)is a function fromfloattoboolfoo(int a)is a function pointer fromfloattoboolfoois a function that takes aintand returns a function pointer fromfloattoboolreally weird in my opinion.
C++ is even worse, due to templates and the so-called most vexing parse. Initializing with
{}mitigated the latter somewhat, but came with its own set of woesMore like getRidOfMyLawn
So that’s why people like C-style return types. That actually makes a lot of sense. I do too now.
To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a
bool, but rather the element that you removed, so like this:fn getofmylawn(lawn: Lawn) -> Option<Teenager> { lawn.remove() }And then with such a more complex return-type, C-style means that you can’t see the function name right away:
Option<Teenager> getofmylawn(Lawn lawn) { return lawn.remove(); }I also really don’t think, it’s a big deal to move your eyes to the
->…Amusingly, modern C++ allows you to copy the rust signature nearly 1:1:
auto getofmylawn(Lawn lawn) -> Option<Teenager> { return lawn.remove(); }Huh, did that emerge out of unrelated design decisions or did they just figure
I believe that it is useful in a few places. cppreference.com mentions templates as one case:
The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.
Additionally, the scope of the return type matches the function meaning that you can do
auto my_class::my_function() -> iterator { /* code */ }instead of
my_class::iterator my_class::my_function() { /* code */ }which is kinda nice
Very interesting, thanks! 🙂
Yeah, the most beautiful code is where all variables are just letters of the alphabet.
Keywords aren’t variables
Ooh yeah, overall coding culture is definitely not affected by the preferred nomenclature for identifiers. The person who’s habituated to
fnoverfunctionwill absolutely never name their functions in the vein ofchkdsk. The two are completely disconnected in the brain of the programmer who read too much K&R in their childhood and was irretrievably traumatized by it for life.I’d say it’s much more influential the names of the identifiers of the standard library.
A language with
functionkeyword that names it’s stdlib functionsstrstrandstrtokwill inspire way worse naming than on that hasfnkeyword with stdlib functionsstr::containsandstr::split.We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.
Tell me this is sarcasm