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

41–50 of 147 posts

Re: Rust Guide

#41

Post by georgemcbay »

gosub wrote: post #9

let x = 5i; so, integers are written like complex numbers?

AFAICT they only need to be written like that if you want to assign them to an implicitly typed variable or you can use the alternate explicitly-typed form (which the guide also shows):

let x: int = 5;

As far as i being an unfortunate suffix, I can't think of a better one when you consider there is already a pattern to such suffixes (being the first letter of the type) carried over from C/C++, et al.

I suspect mathematician programmers who are already used to * being multiply and ^ being bitwise xor (instead of, say, an exponent operation) can probably learn to deal with it, or just avoid it by avoiding implicit typing for ints.

Re: Rust Guide

#42

Post by bcj »

easytiger wrote: post #32
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…

fn & mod are fine. no worse than cdr & car. Variable declaration and type annotations in rust are the thing you should be confused/angry/sad about.

I would say fn and mod are a lot better than cdr and car. At least fn and mod are just abbreviations of the words they represent.

cdr and car requires me to know 60-year-old implementation details of Lisp.

Re: Rust Guide

#43

Post by mercurial »

antocv wrote: post #18
Vanzetti wrote: post #8

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?

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.

Re: Rust Guide

#44

Post by mercurial »

easytiger wrote: post #32
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…

fn & mod are fine. no worse than cdr & car. Variable declaration and type annotations in rust are the thing you should be confused/angry/sad about.

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

Re: Rust Guide

#45

Post by bsdshepherd »

Vanzetti wrote: post #38
antocv wrote: post #18

Earlier quoted context omitted.

Well yeah, it should be poetry. Instead of, what, cryptic symbols to decipher? You dont read symbols?

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.

Re: Rust Guide

#46

Post by ch »

It would be useful if the guide folded the Unix/Windows examples up into a single view (something like what the Spark docs do: https://spark.apache.org/docs/latest/quick-start.html#Basics)

And then, perhaps, used some platform detection to display the more appropriate form by default.

That way less space is used up by the parallel examples.

Re: Rust Guide

#47

Post by ben0x539 »

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

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.

Re: Rust Guide

#48

Post by antocv »

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.

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.

Re: Rust Guide

#49

Post by easytiger »

mercurial wrote: post #44
easytiger wrote: post #32

Earlier quoted context omitted.

fn & mod are fine. no worse than cdr & car. Variable declaration and type annotations in rust are the thing you should be confused/angry/sad about.

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

Re: Rust Guide

#50

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.

> Perhaps we could even reuse previous symbols

You do. The symbol is given meaning by context.

> who would have thought of such an idea.

That would be me.

> genius

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

Take care.

Post reply on HN