Live data from Hacker News

A half-hour to learn Rust

fasterthanli.me

111–120 of 150 posts

Re: A half-hour to learn Rust

#112

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…

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.

The "spiral rule" doesn't get at the heart of declarations. It's just by some guy that tried to figure it out on his own, and what he discovered was basically not declarations but the precedence rules of C expressions ;-)

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

Actually most languages don't let the user do what C declarations let you do. For example, in Java (almost) everything is an object, and you can't just create a triple-indirected pointer. So, these languages can afford a declaration syntax that is less potent.

And then there are other more systems-oriented languages that chose to not copy C declarations. They come with their own gotchas. As examples I will pick D and Rust.

In D, you create a multi-dimension array like this: int[5][10] arr; Leading you to believe that you can use it as arr[4][9]; Wrong. That's an out-of-bounds error. You need to write arr[9][4]. Now, was that totally not confusing? The alternative is to expand these types systematically to the left, i.e. write [10][5]int, and maybe move the type to the right of the variable name, as in "let arr [10][5]int;". Honestly I don't like that either.

I've never really used Rust (either), but its downside, in my opinion, is that it has much more distracting syntax / punctuation.

I would love if there was a uniformly better way to declare things than the C way, but I still think C has the best tradeoffs for my practical work. The next time that I toy with language design I might try to simply go with C declarations, prefixed with a sigil or "let" or something, to remove the need for the lexer hack.

Re: A half-hour to learn Rust

#113

What does `type Output = Self;` for the `std::ops::Neg` trait mean? It wasn't explained on the page.

IIRC that's called "associated type" and is mostly used for shortening the function declaration inside the trait through using e.g. "Self::Output".

E.g. the definition of the real std::ops::Neg trait: https://doc.rust-lang.org/std/ops/trait.Neg.html

Re: A half-hour to learn Rust

#114
post #87

Earlier quoted context omitted.

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

Right, so drop is useless :) We can drop things fine without it. Since of course it's scope/ownership based and not something that's explicitly called.

Re: A half-hour to learn Rust

#116
This is fantastic! Using it, I was finally able to write my favorite toy-problem in Rust (scoring a boggle board). Rust solution came out 25% faster than my (I thought) highly-optimized C++ solution, wow...

Re: A half-hour to learn Rust

#117
post #52
post #39

Earlier quoted context omitted.

Meh, 123_i32 seems like a big improvement to me, but with the others, I just can't immediately grok it - it's having numeric digits as part of the type name that throws me. I realise of course that not everyone will feel the same.

C99 has effectively identical types in the standard library (uint8_t ... uint64_t, and ditto for int8_t ... uint64_t). There are very few modern C codebases where I haven't seen these used (personally I use them because it's much easier than remembering what is the minimum guaranteed size of unsigned long). The Rust ones have just slightly more terse names (which it's understandable to dislike, though I personally fi…

Sorry, I should have phrased that better; it's more like, having numeric digits as part of the type name that immediately follows the value throws me.

So something like this (rust):

`16i32`

Compared to something like this (C#):

`16i`

Re: A half-hour to learn Rust

#118
This is so good. I would love this kind of "learning" for every language. It's definitely not beginner friendly but for anyone that already knows a language this is a super introduction and quick start, maybe even tipping point to start using the language.

Only remark: If I had anchor tags at specific points creating a reference would be easy, this is referenceable material.

Great job though, I am amazed at the quality of this. Hell yeah!

Re: A half-hour to learn Rust

#119
post #113

What does `type Output = Self;` for the `std::ops::Neg` trait mean? It wasn't explained on the page.

IIRC that's called "associated type" and is mostly used for shortening the function declaration inside the trait through using e.g. "Self::Output". E.g. the definition of the real std::ops::Neg trait: https://doc.rust-lang.org/std/ops/trait.Neg.html

It’s not about shortening things, it’s actually about semantics! Choosing to make something have a type parameter vs an associated type depends on what you’re trying to accomplish.

Re: A half-hour to learn Rust

#120
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…

So how far can I go in Haskell without "getting" monads? I C that would be pretty far without bitwise operators.

Very. You just read the type signatures to see when you need to use the monad version of functions or syntax, and just get on with it. The whole system will naturally guide you anyhow. After some practical experience, you'll have enough understanding to use it perfectly fluidly. If you then feel like coming back around and reading one of the better explanations, you'll get the theoretical side better, and may be able to write your own if you are so inclined, but, you are reasonably likely to never want or need to.
Post reply on HN