Please Rust-lang, why, oh why, do you choose to name function 'fn' and module 'mod', dont you expect to read any of the programs you write!?
How is anyone supposed to read fn main(). Fun main? Fen main? F of N? Is it related to ln in println?
Ive tried rust, but it just doesnt parse well in my mind. More time is spent for me parseing out the bullshit terse keywords than the meaning of the program.
Ada gets this right, there you have to write exactly what you mean, end begin, if then. Simple clear.
Terseness, shorts and abbrevations, thts now hw you wrt anyng.
Come on, that's a complete bikeshed and I'm sure you know it. If you have to read code aloud you can just say "fun" or "function" and "mod" or "module", obviously. And since those symbols are used everywhere in the source code I really doubt anybody is going to forget what they mean.
I know it's trendy to remove all non alnum characters and make everything super verbose but there's a compromise to make here. Because some languages went overboard with symbol soup doesn't mean all symbols/abbreviations are bad.
This is the kind of reacting any newcomer to a language makes. You start with lisp? "omg all those parens!" You start with python? "omg significant whitespace!" You start with C? "OMG all those semicolon at the end of lines!" You start with perl? "OMG!" You start with APL? "O|▼".
Also I think making basic language constructs overly verbose doesn't help legibility because it drowns the actually interesting bits in a lot of boilerplate. VHDL comes to mind, but it's probably not what you were talking about...
Bikeshed or not, he's not the only one who doesn't like "fn" choice. The shortnaming choices aren't really consistent. IMHO, "fun" would be better.
as box break continue crate else enum extern false fn for if impl in let loop match mod mut priv proc pub ref return self static struct super true trait type unsafe use while
I like fn a lot more than fun. fns are serious business! (and personally I have a hard time dealing with abbreviations that are themselves actual words, fn stands out more)
fwiw, continue and return used to be cont and ret, match used to be alt, crate used to be not a keyword iirc.
fun would have been better:
- ML heritage for named functions (fn was anon)
- muscle memory with the leading part of javascript function
- the other abbreviations take the leading part of the word
I dont read code aloud, but when reading it I have to make the sounds in my head. Makes sense?
fn calculate() does not lead my brain/mind to discover everything there is it already knows that is function and what it means in this specific context, but instead if I read it as fun it takes me to fun times calculating tip at college with friends.
mod means modification. Modulus. Or module. Why oh why, cant they just write freaking word module?!
Thats what programming is about - kill assumptions, define stuff, and Rust is flowing with assumptions and tersness.
Ada is what I am talking about - a very fine verbose language. Even Java is better than rust.
I think if Mozilla designed Java, it would look like this
You better get over that problem because, depending on the language and context, you will find function written as fn, func, def, ->, lambda and many more. Some languages even don't offer a keyword for it.
In Rust, the function keyword is written 'fn', there're no assumptions or ambiguity there. You just have to learn "in Rust fn means function". It's as capricious as any other keyword, including function.
As a non-native English speaker I find this amusing because for me it's very clear that keywords are magic incantations for the compiler or interpreter, they aren't meant to explain anything. You just learn how to use those keywords and deal with it. For me, it's not clearer to write function instead of fn because in my native language you write it 'función'.
In my experience, it's not rare for Spanish-speaking programmers to ommit the t in function as it is the clearest and most natural way for them to write it. Then, when the program doesn't work, they have to add the missing ts. I feel fn is an improvement with regards to this, as it's not so English-centered. Let's stop pretending that programming a computer is a mixture of Logic, Math and English.
I agree with the core of what you're saying. fn vs function vs whatever is simply a way for the compiler to read your program. However, I feel like it's a mistake to say natural language has nothing to do with programming.
The most powerful metaphor I use when I explain to newer developers how to write clear code is simply "tell a story." Of course you're telling a very constrained story, and some parts need a little comment to explain them, but I strongly believe that even if you're using english keywords, you should be telling a story in the development team's native language if possible. Not everything is a binary choice, even in computing. ;)
You should try Haskell for size before complaining about Rust. IMHO, it's really a matter of taste, and something which most people get over with quickly if they find it an issue. Actual semantics are much more important than a small number of language keywords. Libraries, on the other hand, should definitely use easy-to-understand symbols.
You already have the 'conceal' feature in vim, which in vim2hs is used to replace \_ with a λ_. No need for plugins. I think the vim Rust plugin has support for it, but you need to set an option.
Yes, exactly, we can make translations of symbols so that it is actually easier for human readers to decode the meaning and message of the symbols. Perhaps we could even reuse previous symbols and meanings to convey what we want to convey instead of offering ambiguity.
I just wonder, who would have thought of such an idea. That is genious. And something that has completely evaded Rust designers.
Weed, caffeine, and sleep deprivation. Staring at Harris mainframe assembly language core dumps on reams of green bar paper... does things to a man. ;-)
HTML5 and Unicode are wonderful toys. Go play. My notes and early efforts on this go back to 1979. Anyone is welcome to them. It does take quite a bit of effort to transmit, so patience is a virtue here.
(P.S. Don't overlook color.)
(P.P.S. Or animation.)
---
Edit: You'd be surprised how easy input becomes. It removes a huge mental load from context switching (e.g. hitting the same button to get Control F4, Control W, Apple W, Alt F Alt C, etc.).
Use a few touchpads which can change the symbols based on current context, and baby - you got a stew goin'.
Try to wrap your head around how many API's, tools, training materials, releases, updates and so forth have been done in thirty years which are effectively redundant.
The iWatch will contain regurgitations of the same todo lists, logging, sticky notes, etc. as the Palm Pilot, but without AAA batteries.
Maybe you shouldn't spell out every abbreviation (and acronym) when you read? Otherwise it can be "fun" when you read HN comments about the HTML5 WebGL API and the low FPS CSS animations that eats too much CPU power.
Both your comment and OPs comment have no place. The article itself is a newly published guide to Rust. OPs comment derailed the entire thread- perhaps 2/3 of the discussion is in response. Ideally, if this comment merited discussion, it would be submitted as its own thread (where it would quickly go nowhere). After all, the assertion, fn is a stupid name, is a bikeshed- a triviality offering a safe opinion for everyone. Rust isn't going to change the token. Please refrain from bikeshedding in the future.
What do you find wrong about variable declaration and type annotation? Most variable declarations are like 'let foo = ' with the type auto-inferred. I admit that the diamond notation for type parameters is a bit aggravating, but it's not the end of the world. On the other hand, the little rust I've seen had a large number of as_slice() calls...
Ultimately I need to spend some more time with it. I'm sure it's fine, I just find it jarring. One major issues is the official tutorial doesn't explain all possible variances of syntax for declaration in one place so my brain wasn't given a chance to compare them side by side.
Also i'd much rather live without type inference, so I guess rust gives me that option. I'm just too neurotic (low level networking code/parsers/etc) to not specify types.
let mut monster_size: int = 50;
I'd really really just like the type to be first.
let mut int monster_size = 50;
But wait, there are yet more options:
let monster_size = 50i32;
Boxes are just plain confusing on first sight. They make pointers look like a lucid breath of fresh air.
let owned = box 10i;
let borrowed = &20i;
let sum = *owned + *borrowed;
I find options in a language quite distressing (see also perl). I'm also not sold on the mut keyword and i'm likely to become confused when one gets to complex types.
Don't get me started on the automatic dereferencing. That's seriously confusing.
Is there a rule of thumb for when I am meant to use which of these? can i use the type annotation anywhere i use a number as a literal?
Raw string literals:
> They are written as r##"blah"##, with a matching number of zero or more # before the opening and after the closing quote
Why? Why the optional number of #'s?
Syntax extensions? !
Why is print a syntax extension? why isn't it in the library? if it is a macro why are we running around putting ! at the end of them... why does it matter? Why do that?
I prob don't know what I'm talking about but that's my initial impression from last week
The "let monster_size : int = 50"/"let monst_size = 50i32" is an example of special cases for numeric values. For other types, only the first style is available. I would imagine that it's a shortcut to let you specify easily what kind of representation you want for a numeric value in a less noisy way (since numeric values don't have explicit constructors).
Boxes and lifetimes get a bit used to, but comparing Perl and Rust is, I feel, quite unfair. Rust's syntax is much smaller than Perl's, and from what I've seen the team has taken pains to make it smaller and more regular.
As for println!, it's a macro which gives you compile-time checks on your format string (same as OCaml), which is very nice.
The variable number of #s is in case the string contains some number of #s.
print is a macro so it can be strongly typed and checked by the compiler. As far as I know, "!" is just a convention to make macros obvious -- it seems unnecessary to me, too.
Putting the type of a variable at the end is common in new C-likes. Go does it too. In the case of Rust, I'm pretty sure it's inherited from ML. It avoids a lot of the problems and complexities caused by C's type keywords (see: typedefs of pointers to functions; const pointers to values and pointers to const values; etc.).
> As far as I know, "!" is just a convention to make macros obvious -- it seems unnecessary to me, too.
No, it's very necessary, as macros actually take arbitrary token sequences as an 'argument', so there's no guarantee that the contents will parse as Rust code (e.g. https://github.com/huonw/brainfuck_macros), furthermore, macros can transform this argument into arbitrary code.
Hence it's nice to have an in-source marker to avoid humans and compilers having to work out if a certain name has strange semantics (particularly for compilers, to avoid having to intertwine parsing and name resolution: makes this simpler).
While this isn't exactly the same, the convention of appending "!" in scheme/racket to denote a function that mutates a value is helpful in my opinion. You don't absolutely need it, but reading through your code and easily identifying where your values can change is nice.
I'm wondering if it would be more readable with actual angle brackets rather than less than and greater than signs.
from_str::<Option<uint>>
vs
from_str::‹Opton‹uint››
Hmm. Those are a little lightweight, are actually angle quotes, not angle brackets. Actual angle brackets aren't available on my keyboard, but would look like:
from_str::⟨Option⟨uint⟩⟩
Jeez, why does Unicode have so many different variations on angle brackets? The above are "mathematical left/right angle bracket", but there's also:
from_str::〈Option〈uint〉〉
Which uses "left/right-pointing angle bracket" and:
from_str::〈Option〈uint〉〉
Which uses "left/right angle bracket"
At least in the font I'm typing this in, the "left/right-pointing angle brackets" look the best to me. It would be really nice if now that Unicode is ubiquitous, we could standardize on keyboard layouts that get you access to more punctuation like this, so that people didn't have to keep fighting over a fairly limited amount of punctuation to use as technical notation in programming languages.
How is anyone supposed to read fn main(). Fun main? Fen main? F of N? Is it related to ln in println?
Ive tried rust, but it just doesnt parse well in my mind. More time is spent for me parseing out the bullshit terse keywords than the meaning of the program.
Ada gets this right, there you have to write exactly what you mean, end begin, if then. Simple clear.
Terseness, shorts and abbrevations, thts now hw you wrt anyng.