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

101–110 of 150 posts

Re: A half-hour to learn Rust

#101

Post by dmitriid »

This is very good but... Description of traits suddenly dumps references, mutable references, reference bindings, dereferencing with zero explanation:

--- start quote ---

Trait methods can also take self by reference or mutable reference:

  impl std::clone::Clone for Number {
    fn clone(&self) -> Self {
        Self { ..*self }
    }
  }
--- end quote ---

What? What does this even mean? What is self, and why?

Too many questions, not nearly enough answers.

Re: A half-hour to learn Rust

#102

Post by clarry »

I want books written like this. I've had too many books where I die of boredom over and over again in the first 150 pages and then I never read them again. It's like there's some rule saying books must be super wordy.

Re: A half-hour to learn Rust

#103

Post by krebs_liebhaber »

Sharlin wrote: post #43
jokoon wrote: post #12

> let x: i32 = 42; I'm sorry but this notation will always make me scream. C is so much simple: int x = 42; not "let", no colon, and no ambiguous "i32 = 42"

You mean, like when declaring an array: int[4] arr; // oops, doesn’t compile Or a function pointer: int (*)(int) fptr; // oops, doesn’t compile So much for the simplicity of C declaration syntax.

I've been writing code in C and C++ since I was 12 and I still sometimes forget where the array size and brackets are supposed to go.

Re: A half-hour to learn Rust

#104

Post by bloomer »

jstimpfle wrote: post #65
Sharlin wrote: post #43

Earlier quoted context omitted.

You mean, like when declaring an array: int[4] arr; // oops, doesn’t compile Or a function pointer: int (*)(int) fptr; // oops, doesn’t compile So much for the simplicity of C declaration syntax.

One can make the argument that the C declaration syntax is simple, because the rule to make a declaration is to simply follow a type name by an expression where the declared variable is used. The fact that you write "int[4] arr" shows that you don't know how it works (which is not a criticism; it's just not well known how it works). The correct way is to write int arr[4]; and to interpret it as "arr[4] is an int" (wh…

http://c-faq.com/decl/spiral.anderson.html Is the rule I learned to understand C declarations and while the rule there is described as simple I think the examples even without argument types are actually fairly complex.

It also seems telling that no recent language has followed C’s example for declaration style, which is more implicit than explicit.

Re: A half-hour to learn Rust

#105

Post by taktoa »

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

You shouldn't be writing literal HashMaps in your code very often anyway; you should use a function that pattern matches on a string for the day-of-week-to-number example (returning Option of course). Most other cases where you might want literal HashMaps are well-served by either pattern matching functions or structs. The point of a HashMap is that it has keys that you don't know at compile-time; if you use a HashMap literal, that's basically saying that you do know the keys at compile time.

Re: A half-hour to learn Rust

#106

Post by runarberg »

kzrdude wrote: post #87
AnimalMuppet wrote: post #79

Earlier quoted context omitted.

But where is it moved to ? Who owns it now? Or is it just lost?

yes, it is dropped

Ahh, I remember a while back reading a blog where the author talked about `std::mem::drop` being their favorite standard library function because they used this effect. It is literately defined as:

    pub fn drop(_x: T) { }
https://doc.rust-lang.org/std/mem/fn.drop.html

Re: A half-hour to learn Rust

#107

Post by TheRealPomax »

clarry wrote: post #102

I want books written like this. I've had too many books where I die of boredom over and over again in the first 150 pages and then I never read them again. It's like there's some rule saying books must be super wordy.

That rule is usually called the publication contract, and it usually literally says how big the work needs to be, even if you can say it better in fewer words/pages/chapters/etc.

Re: A half-hour to learn Rust

#108

Post by will4274 »

jstimpfle wrote: post #65
Sharlin wrote: post #43

Earlier quoted context omitted.

You mean, like when declaring an array: int[4] arr; // oops, doesn’t compile Or a function pointer: int (*)(int) fptr; // oops, doesn’t compile So much for the simplicity of C declaration syntax.

One can make the argument that the C declaration syntax is simple, because the rule to make a declaration is to simply follow a type name by an expression where the declared variable is used. The fact that you write "int[4] arr" shows that you don't know how it works (which is not a criticism; it's just not well known how it works). The correct way is to write int arr[4]; and to interpret it as "arr[4] is an int" (wh…

> the rule to make a declaration is to simply follow a type name by an expression where the declared variable is used.

Not really. You can't just use _an_ expression, you have to use a specific expression. For example, * ppX is a perfect valid expression for a pointer to a pointer named ppX, as in:

    int **ppX;
    if (*ppX == NULL)
So you need to use an expression where the declared variable is used that results in a non-pointer type. And then, there's actually more to it... only certain types of expressions are valid. E.g. this isn't a valid declaration for a pointer, even though it's valid as an expression:

    int pX->;
I find that basically anytime somebody tells me that C rules are to "simply [...]", they've inevitably ignored a whole bunch of cases. Your post is no exception.

Re: A half-hour to learn Rust

#109

Post by estebank »

inferiorhuman wrote: post #26
csomar wrote: post #8

Earlier quoted context omitted.

I use it mostly if I'm passing arguments to another function. It serves as some sort of code documentation. > my_function( 44i32 ); That makes it clear from the code that function accepts an i32 and not any number.

The type signature of the function will also enforce that. You can also use generics to allow you to accept a wider variety of numbers, e.g.: fn takes_a_float_like_number (number: T) where T: Into { // Number will now be a 64-bit IEEE floating point object // for this scope let number = number.into(); } This will only compile if your type is small enough to fit into an f64. So takes_a_float_like_number(500_u32) will…

How would you improve that error?

Re: A half-hour to learn Rust

#110

Post by jstimpfle »

will4274 wrote: post #108
jstimpfle wrote: post #65

Earlier quoted context omitted.

One can make the argument that the C declaration syntax is simple, because the rule to make a declaration is to simply follow a type name by an expression where the declared variable is used. The fact that you write "int[4] arr" shows that you don't know how it works (which is not a criticism; it's just not well known how it works). The correct way is to write int arr[4]; and to interpret it as "arr[4] is an int" (wh…

> the rule to make a declaration is to simply follow a type name by an expression where the declared variable is used. Not really. You can't just use _an_ expression, you have to use a specific expression. For example, * ppX is a perfect valid expression for a pointer to a pointer named ppX, as in: int **ppX; if (*ppX == NULL) So you need to use an expression where the declared variable is used that results in a non-…

> So you need to use an expression where the declared variable is used that results in a non-pointer type.

I think you are wrong here, you can't even make something other than what "results in a non-pointer type". Because by definition, you're making the type to the left with the expression. (That could still be a pointer type if it is a typedef'ed type; such as "typedef int * intptr; intptr x;" but I don't think you meant that by "pointer type" [0]).

And your first example is perfectly syntactically valid (other than missing the conditional statement that must follow the if-condition).

And no, "pX->" is not a valid expression. Was that a typo?

And yes, only a subset of expressions are valid. Basically, the expressions that you can form by applying subscripts, (x[3]), dereferences (* x), and function calls. Because, a declaration like "int x + 3;" or even "int x + y;" just doesn't make sense. I don't see a problem there.

Btw. I'm not saying that C as by the current standards is super straightforward and pure. It's definitely not, and C does actually have a lot of historical baggage that makes our lives a little harder. I'm just explaining the underlying unifying principle, which IMHO is actually nice. And honestly it seems you, too, are still confused because there is just a lack of clear explanations about C declarations. That principle should be much more well-known, and almost all problems that novices have with declarations are unnecessary frustration that they wouldn't have if someone would have told them the trick.

[0] By the way, typedef is another thing that seems to be super obscure, while it is extremely simple: It's just a keyword that modifies declarations to declare an alias for that type, instead of a (named) variable of that type.

Post reply on HN