5 ms·

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.

bcj 12y ago
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.
- kyllo 12y ago
  This is why I like 'head'/'hd' and 'tail'/'tl' from ML/Haskell family more than Lisp/Scheme family's car/cdr.
mercurial 12y ago
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...
- easytiger 12y ago
  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
  - Ygg2 12y ago
    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.
  - djur 12y ago
    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.).
    - bjz_ 12y ago
      > it seems unnecessary to me, too. It is important for syntax highlighters.
    - bbradley406 12y ago
      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.
    - dbaupp 12y ago
      > 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 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).
saosebastiao 12y ago
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.
- andypants 12y ago
  I initially thought you were writing brainfuck
- ori_b 12y ago
  I'm biased, but I'm partial to Myrddin's syntax: const foo = {bar: @a, baz : asd(@a,foo(@b, bar(@c,@d),int)) ... }
- lambda 12y ago
  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>> vs 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.
  - steveklabnik 12y ago
    There are some proposals to make that syntax go away. ::<> is certainly something we're not happy about.
- mercurial 12y ago

bcj 12y ago

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.

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

mercurial 12y ago

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

easytiger 12y ago
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
- Ygg2 12y ago
  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.
- djur 12y ago
  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.).
  - bjz_ 12y ago
    > it seems unnecessary to me, too. It is important for syntax highlighters.
  - bbradley406 12y ago
    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.
  - dbaupp 12y ago
    > 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 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).

saosebastiao 12y ago

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.

andypants 12y ago
I initially thought you were writing brainfuck
ori_b 12y ago
I'm biased, but I'm partial to Myrddin's syntax: const foo = {bar: @a, baz : asd(@a,foo(@b, bar(@c,@d),int)) ... }
lambda 12y ago
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>> vs 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.
- steveklabnik 12y ago
  There are some proposals to make that syntax go away. ::<> is certainly something we're not happy about.
mercurial 12y ago