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

61–70 of 147 posts

Re: Rust Guide

#61

Post by bsdshepherd »

antocv wrote: post #48
bsdshepherd wrote: post #45

Earlier quoted context omitted.

> It could be ... Ξ Thank you. Somewhere, a transliteration vim plugin is struggling to escape. Based on user preferences it will display: def Σ(): print("LOL WUT?") Σ() -or- define sum(): print("LOL WUT?") sum() -or- Ξ Σ ⍋("LOL WUT?") Σ -or even- IDENTIFICATION DIVISION. PROGRAM-ID. Abomination. PROCEDURE DIVISION. DisplaySummary. DISPLAY "LOL WUT". STOP RUN.

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.

> And something that has completely evaded Rust designers.

“If you've been playing poker for half an hour and you still don't know who the patsy is, you're the patsy.” - Warren J. "Doc" Gates

Programmers are the patsy that businesses and universities use to keep growing ever larger heads of broccoli that consumers eat.

Note the similarities between GUI's 30 years ago and today: http://en.wikipedia.org/wiki/History_of_the_graphical_user_i....

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.

Re: Rust Guide

#62

Post by octo_t »

+1 from me for the `curl | sudo sh` disclaimer. Even if the only thing it does is stop people complaining about it :)

Re: Rust Guide

#63

Post by mercurial »

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

Re: Rust Guide

#64

Post by [deleted] »

general_failure wrote: post #58
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.

[deleted]

Re: Rust Guide

#66

Post by steveklabnik »

Hi everyone! I just woke up to find all this, and I'm speaking at a conference today where there's no laptops allowed, so we'll see when I get to read these comments. A few things:

1. Consider this a 'first draft.' I wrote this in sections, see [1], and now it's time to edit as a whole.

2. Because of that, there are still changes coming. There's even an active one in the queue right now. [2]

3. This guide is fairly long (The PDF is 80~ pages), tries to make little assumptions about systems programming knowledge, and will get you from 'I know nothing about Rust' to 'I'm an intermediate Rust programmer.' There's plans to make an abridged version for people who are already familiar with systems or want something faster with less explanation.

To expand on (3) a bit, one of the hard parts of teaching is that you have such varying background levels of skill in your audience. This means different people need different things, one learning resource will never fit all. I very specifically went for extra explanation and an informal tone with this piece, based on my years of experience teaching programmers new languages. You all here are generally much further along, know more programming concepts and features, and are just generally more advanced. I want to include _everyone_ with the introductory documentation I write, and that means spelling things out a bit more. And it also means you all may not like it. You'll probably prefer the abridged version.

Feedback very welcome. I'll read all this eventually, or just open some issues.

1: https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3As...

2: https://github.com/rust-lang/rust/pull/17155

Re: Rust Guide

#67

Post by bbradley406 »

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…

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.

Re: Rust Guide

#68

Post by dbaupp »

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…

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

Re: Rust Guide

#69

Post by mercurial »

bsdshepherd wrote: post #45
Vanzetti wrote: post #38

Earlier quoted context omitted.

I know that 'fn' defines a function. It could be 'def', 'funct' or 'Ξ', it doesn't really matter. Also, what's the problem with pronouncing 'fn' as 'ef-en'?

> It could be ... Ξ Thank you. Somewhere, a transliteration vim plugin is struggling to escape. Based on user preferences it will display: def Σ(): print("LOL WUT?") Σ() -or- define sum(): print("LOL WUT?") sum() -or- Ξ Σ ⍋("LOL WUT?") Σ -or even- IDENTIFICATION DIVISION. PROGRAM-ID. Abomination. PROCEDURE DIVISION. DisplaySummary. DISPLAY "LOL WUT". STOP RUN.

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.

Re: Rust Guide

#70

Post by izietto »

steveklabnik wrote: post #66

Hi everyone! I just woke up to find all this, and I'm speaking at a conference today where there's no laptops allowed, so we'll see when I get to read these comments. A few things: 1. Consider this a 'first draft.' I wrote this in sections, see [1], and now it's time to edit as a whole. 2. Because of that, there are still changes coming. There's even an active one in the queue right now. [2] 3. This guide is fairly l…

What is your opinion about this HN comment [0] (TL;DR the guide should be terse to a skilled profile, overly explanatory to a beginner)? I personally agree with him

[0] https://news.ycombinator.com/item?id=8306868

Post reply on HN