31–40 of 147 posts
Earlier quoted context omitted.
In this case, "i" is a type suffix meaning "int". 5u would be an unsigned int; 5i32 would be a 32-bit int; 5f64 would be a double precision float, and so forth.
I understood that, but it's an unfortunate suffix.
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…
Variable declaration and type annotations in rust are the thing you should be confused/angry/sad about.
Honest initial impressions from my quick glance. This guide is confused. It reads at times like an informal conversation... lots of exclamations. That's pedantic, the real confusion comes from the target audience. As a programmer, I want as little cruft as possible. Get me to examples and how this differentiates from C. As a non programmer, teach me the basics of types and logic. From that thought, it's failing at bo…
If you want more details, less cruft, you probably like to read the Manual: http://doc.rust-lang.org/rust.html The Guide is fine as a tutorial and where does it not teach the basics? So your impression is definitely not mine. "Stop talkting to me informally" is also very subjective. I very much prefer the informal way.
Is there any place to read about the Rust design?
let x = 5i; so, integers are written like complex numbers?
There are lots of small things I would want to change about the guide, especially in regards to which sections should be more in depth and which ones should be skipped for another guide, but that's why it's a first iteration.
One stylistic nitpick / question. It says: > "We expected an integer, but we got (). () is pronounced 'unit', and is a special type in Rust's type system. () is different than null in other languages, because () is distinct from other types" Would it not be more accurate and more informative to compare the "special type" unit to "void" than to compare it to "null" ? The keyword "void" is a placeholder that says "noth…
The problem with void is that it's not a real type in C.
That's why I said void is "more or less like a type" and asked about "unit" as a "first class void" - i.e. a "void" that is a real type that works like other types.
Honest initial impressions from my quick glance. This guide is confused. It reads at times like an informal conversation... lots of exclamations. That's pedantic, the real confusion comes from the target audience. As a programmer, I want as little cruft as possible. Get me to examples and how this differentiates from C. As a non programmer, teach me the basics of types and logic. From that thought, it's failing at bo…
I'll admit right up front that there is a lot of subjective bias here, different people learn in different ways and you will never please everyone. So I'm not saying you are wrong, just that the guide appeals to me.
In terms of the A/B split on target audience:
A - Newbs) I'd argue that teaching people to code is way, way beyond the scope of any document like this, so the most logical starting target is someone who codes already but maybe doesn't have a ton of experience and maybe it is in a language very different from the one the guide is presenting. I think this guide hits that target pretty well as a straight-forward read. There are nitpicky things that maybe could be better, but luckily online guides like this can be expanded and iterated on.
Obviously a newb isn't going to understand something like what a "closure" is inherently, but they have the whole rest of the internet to tell them that when they see the term in this guide and then google it to fill in the blanks.
B - Non-Newbs) As an experienced programmer I think the guide is actually pretty great if you use the nicely presented ToC/index at the front as the primary interface to it. Click a concept and boom, you're looking at some nicely formatted example code along with some text that you can probably just skip over completely or skim because you already know what a closure is (for example) and just want to see the syntax for Rust.
I remain a diehard Go partisan for now, but I think this guide is actually superior in a lot of ways to the combination of the "Go Tour" and "Effective Go" which, cute mascot aside, are a bit too much on the dry/clinical side for me as introductory material to a language.
Earlier quoted context omitted.
You are not supposed to read programs aloud. What do you think it is, poetry? 'fn' is a symbol.
Well yeah, it should be poetry. Instead of, what, cryptic symbols to decipher? You dont read symbols?
Also, what's the problem with pronouncing 'fn' as 'ef-en'?
leaving aside the first-mover advantages like community, docs, stdlibs, api stability, where do you see rust's advantages over go?
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…