Hacker News Reader

Comment by easytiger | Hacker News Reader

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.

This is why I like 'head'/'hd' and 'tail'/'tl' from ML/Haskell family more than Lisp/Scheme family's car/cdr.

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

     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.

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

> it seems unnecessary to me, too.

It is important for syntax highlighters.

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.

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

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.

Yes! This is what drives me the most crazy about rust:

    fn foo<<W<>W>G<>GGW>>>F<<D>F>>A>(bar: AJK<<<DUoSJK><<>S>>>){
    ...
    }

Okay, I'm probably being a jackass, but I find Scala's use of [] for nested type annotations to be much easier to parse.

I initially thought you were writing brainfuck

I'm biased, but I'm partial to Myrddin's syntax:

    const foo = {bar: @a, baz : asd(@a,foo(@b, bar(@c,@d),int))
        ...
    }

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

  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.

There are some proposals to make that syntax go away. ::<> is certainly something we're not happy about.

Well, you'd make type synonyms in this case.

Reply on news.ycombinator.com