this post was submitted on 17 Dec 2025
429 points (96.7% liked)
Programmer Humor
27920 readers
1657 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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:
C:
With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.
So that's why people like C-style return types. That actually makes a lot of sense. I do too now.
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 abool"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).
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