Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Guide

doc.rust-lang.org

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Rust Guide

#51

Post by phloxicon »

I think it reads well but I would prefer if the examples given were correct first time around and then talk about what might go wrong, whereas right now, it describes what might go wrong and then how to do it correctly.

For example, in the testing section, the first example code generates an error because it's scope is private. The section then shows how to fix this. I would prefer he showed the correct way first and then how to fix common errors.

Also, I didn't see file IO but i probably overlooked that.

Other than that, it's excellent. Very thorough and reads like a book.

Re: Rust Guide

#52

Post by Ygg2 »

easytiger wrote: post #49
mercurial wrote: post #44

Earlier quoted context omitted.

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/pars…

     Why? Why the optional number of #'s?
Code generation. You can nest raw literals within raw literals.

     Boxes are just plain confusing on first sight.
They are special way to allocate values. They are verbose so that programmers won't use them as often. Think of them as a speed bump.

Re: Rust Guide

#53

Post by djur »

easytiger wrote: post #49
mercurial wrote: post #44

Earlier quoted context omitted.

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/pars…

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.).

Re: Rust Guide

#54

Post by jeremyjh »

the_mitsuhiko wrote: post #27
SideburnsOfDoom wrote: post #15

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.

Null is not a type either, and you cannot reference it in a definition. I think void is a closer match.

Re: Rust Guide

#55

Post by k__ »

ZeroGravitas wrote: post #6
axaxs wrote: post #2

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…

This seems to be fundamental problem with programming texts. I was reading a couple of javascript books recently (eloquent javascript and javascript allonge) and I was struck by the sheer amount of background knowledge you needed to have. Most of that I've picked up over the last 20 years, but not all of it (or else I wouldn't be reading the books) so I constantly felt like I was having something I knew explained to…

I see this problem too, when teaching people.

I tell them stuff and leave out the things that seem obvious to me. They can tell me, what is the missing bit.

Re: Rust Guide

#56

Post by bjz_ »

matthewmacleod wrote: post #39
eik3_de wrote: post #16

leaving aside the first-mover advantages like community, docs, stdlibs, api stability, where do you see rust's advantages over go?

The languages (to me at least) seem to have little overlap. Maybe a better question would be "Why are there so many comparisons between Rust and Go"?

Superficially, they both have curly braces, they are both being supported by prominent internet companies, and due to some mixed messaging, the public perception is that they are both systems languages. So it's not surprising that these questions are being asked, but I do hope that the message will get through to folks that despite surface similarities they are actually quite different.

Re: Rust Guide

#57

Post by bjz_ »

hippiehippo wrote: post #24
simias wrote: post #14

Earlier quoted context omitted.

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…

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

> The shortnaming choices aren't really consistent

It's historical. Rust's keywords used to be far more short on average - I think the rule was no more than 5 characters.

Re: Rust Guide

#58

Post by general_failure »

antocv wrote: post #7

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…

Not sure why you are getting downvoted. I find it very annoying as well.

Why not use brk, cont as well? Somethings are abbreviated, some things are not.

Re: Rust Guide

#59

Post by bjz_ »

djur wrote: post #53
easytiger wrote: post #49

Earlier quoted context omitted.

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/pars…

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…

> it seems unnecessary to me, too.

It is important for syntax highlighters.

Re: Rust Guide

#60

Post by Pxtl »

matthewmacleod wrote: post #39
eik3_de wrote: post #16

leaving aside the first-mover advantages like community, docs, stdlibs, api stability, where do you see rust's advantages over go?

The languages (to me at least) seem to have little overlap. Maybe a better question would be "Why are there so many comparisons between Rust and Go"?

They both billed themselves as "modern C" but Go failed to deliver on that so instead it's now light/modern/ Java. Rust hopes to succeed as a "modern C" where Go failed.
Post reply on HN