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

A half-hour to learn Rust

fasterthanli.me

Post reply on HN
Print view View original

81–90 of 150 posts

Re: A half-hour to learn Rust

#81

Post by blub »

isoprophlex wrote: post #74
jerf wrote: post #55

Earlier quoted context omitted.

None of them. The concept is fundamentally flawed. It's as if everything you ever read about C was all about bitwise manipulation operations, on and on and on about bitwise manipulation, to the point not-C programmers think the language is primarily about bitwise manipulation and people start porting bizarre misunderstandings of bitwise manipulation into other languages and claiming they're just like C now, when it's…

However, the c community never felt like going on and on and on about bitwise manipulation... Anyone have any idea why people get so hung up about explaining monads?

I've seen that some programming communities focus on writing software, while others focus on talking about software.

C and Haskell are two good examples of this dynamic, although C is used in so many different projects that "community" only loosely applies.

Re: A half-hour to learn Rust

#82

Post by svnpenn »

Has anyone struggled with the lack of HashMap literal?

https://github.com/rust-lang/rfcs/issues/542

I just cant bring myself to doing something like this:

    let m1: HashMap = [("Sun", 10), ("Mon", 11)].
    iter().
    cloned().
    collect();
https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

Re: A half-hour to learn Rust

#83

Post by fluffything »

jstimpfle wrote: post #76
fluffything wrote: post #49

Earlier quoted context omitted.

C is the opposite of simple. If you want to create a binding in C, you need to learn multiple, unnecessarily complex rules. Sure, creating a binding to an int is easy: int foo = 42; but doing the same thing for pointers to arrays or function pointers is not: void( foo)(int) = bar; // function pointer int ( foo)[N] = baz; // pointer to array OTOH in Rust you just need to learn one rule: bindings are created with the g…

But that's just not true. There is a single principled way for C declarations, and it's as easy as "a binding is a type name followed by an expression and a semicolon". And while small inconcistencies have been introduced over time, it was entirely consistent when C was conceived. The problem is just that the simple rule how to read declarations is not well-known (I don't understand why). See my other comments.

> "a binding is a type name followed by an expression and a semicolon".

I find this hard to grock. Do you have a link to the actual grammar and production rules that apply to all cases ?

When I see:

  int a = 3;
I don't see a "type name followed by an expression and a semicolon", but rather the grammar "TYPE_NAME NAME = EXPR;". However, that's not correct, since TYPE_NAME cannot be any type (e.g. a function pointer won't work). When looking at

  void (*foo)(int) = expr;
  int (*foo)[N] = expr;
or at how the keywords "struct" and "union" are part of the type name in some contexts, but not others, I see quite different grammar rules.

I've tried to find literature about this, since I hack on a toy C parser every now and then, and those could simplify it, without much luck.

I've never thought of these as "CDECL = EXPR;" or similar, since that does not work either (e.g. a function declaration would be "void foo(int);" but that's not exactly the same as "void (*foo)(int) = expr;").

Re: A half-hour to learn Rust

#84

Post by monocasa »

kzrdude wrote: post #11

Underscore is not exactly "throw away" but rather it is exactly "don't bind to variable". The difference becomes evident with the statement: let _ = x; This is a no-op and the value remains owned by the variable x, and is not thrown away.

I guess I always viewed that as dropping a reference which is a noop, but still dropping.

Re: A half-hour to learn Rust

#85

Post by j1elo »

Close to the beginning there is a phrase you'll want to review:

> If we we really we wanted to annotate the type of pair, we would write

Ok understood, we're us and we're all together in reading this! :-)

Re: A half-hour to learn Rust

#86

Post by dmit »

svnpenn wrote: post #82

Has anyone struggled with the lack of HashMap literal? https://github.com/rust-lang/rfcs/issues/542 I just cant bring myself to doing something like this: let m1: HashMap = [("Sun", 10), ("Mon", 11)]. iter(). cloned(). collect(); https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

Would a macro work ok for you, like the inbuilt vec! one? There's a crate for that named maplit: https://docs.rs/maplit

    let map = hashmap!{
        "a" => 1,
        "b" => 2,
    };

Re: A half-hour to learn Rust

#88

Post by j1elo »

svnpenn wrote: post #82

Has anyone struggled with the lack of HashMap literal? https://github.com/rust-lang/rfcs/issues/542 I just cant bring myself to doing something like this: let m1: HashMap = [("Sun", 10), ("Mon", 11)]. iter(). cloned(). collect(); https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

I assume it must be a common finding. I have too wanted to initialize a map value with a literal, only to find that one needs to juggle around their absence. Very weird thing to miss in such a great language, really.

I guess that the syntax proposal would get too complicated with all the different possibilities (like what happens if you want to store one ref, now you need to add lifetimes and such), but overall for the novice it just looks like a strange thing to not have.

Re: A half-hour to learn Rust

#90

Post by isoprophlex »

blub wrote: post #81
isoprophlex wrote: post #74

Earlier quoted context omitted.

However, the c community never felt like going on and on and on about bitwise manipulation... Anyone have any idea why people get so hung up about explaining monads?

I've seen that some programming communities focus on writing software, while others focus on talking about software. C and Haskell are two good examples of this dynamic, although C is used in so many different projects that "community" only loosely applies.

Interesting, maybe the Sapir Whorf hypothesis is much more relevant for programming languages than for natural languages; maybe the language shapes the things a human can comfortably express, and this shapes the communities

https://en.m.wikipedia.org/wiki/Linguistic_relativity

Post reply on HN