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

51–60 of 150 posts

Re: A half-hour to learn Rust

#51

Post by kuon »

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"

I worked with C for nearly 20 years, and it is everything but simple. It is complicated, not "low level" as many thinks, full of weird edge cases, compilers will happily compile non standard code, fragile (hard to refactor), full of implicit conversion you didn't expect...

Rust has a good design, it still have a few rough edges but the syntax is great and improving.

Re: A half-hour to learn Rust

#52

Post by cyphar »

GordonS wrote: post #39
labawi wrote: post #35

Earlier quoted context omitted.

AFAIK, syntax is: let variable_name [: type] = value[(i|u|f)bits]; In rust, 123l is written 123i64 or 123i32 (also 123_i32, or 1_2_3i32), depending on what 123l actually means. I don't actually use rust, but it seems very clear and obvious to me (obvious once you know the syntax above).

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 find the endless _t suffixes in C type names to be a bit annoying as well). And Rust's usize is basically uintptr_t.

Re: A half-hour to learn Rust

#53

Post by whatshisface »

esjeon wrote: post #44

Nothing related to the tutorial itself, but I've seen many Rust basic tutorials recently, and this sorta remind me of Haskell - especially its Monad. The Haskell community once was flooded with Monad tutorials[1]. People kept trying to put meanings on this mathematical construct, and had come up with tons of different ways to describe it. The problem is, this simple thing can fit into so many different places, so peo…

The dust is settled and the fight is over. Which monad tutorial won "best monad tutorial?"

Re: A half-hour to learn Rust

#54

Post by crazyjncsu »

fasterthanlime wrote: post #46
GordonS wrote: post #17

Earlier quoted context omitted.

C# has a similar feature, but it's less verbose, e.g. "16l"/"16L" is a long (64-bit integer), "16u" is an unsigned, 32-bit integer etc. I find the rust syntax a little difficult to read. Take "16i32" for example - it's not immediately clear which part is the actual value.

One neat thing Rust let you do is put underscores in number literals. It's great for readibility: 0xFFFF_FFFF // easier to count than 8 Fs And you can use that with type suffixes: let a = 255_u8; Although in that case, you'd probably either omit u8 entirely, letting the compiler infer the type of 'a' from usage, or use a colon to give it ane explicit type. Type suffixes are especially useful for arguments to generic…

C# 7 (2017) and higher also allows underscores in number literals.

Re: A half-hour to learn Rust

#55

Post by jerf »

whatshisface wrote: post #53
esjeon wrote: post #44

Nothing related to the tutorial itself, but I've seen many Rust basic tutorials recently, and this sorta remind me of Haskell - especially its Monad. The Haskell community once was flooded with Monad tutorials[1]. People kept trying to put meanings on this mathematical construct, and had come up with tons of different ways to describe it. The problem is, this simple thing can fit into so many different places, so peo…

The dust is settled and the fight is over. Which monad tutorial won "best monad tutorial?"

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 just a part of the language that you'll pick up over time. Not a perfect metaphor but close enough.

Re: A half-hour to learn Rust

#56

Post by GordonS »

fasterthanlime wrote: post #46
GordonS wrote: post #17

Earlier quoted context omitted.

C# has a similar feature, but it's less verbose, e.g. "16l"/"16L" is a long (64-bit integer), "16u" is an unsigned, 32-bit integer etc. I find the rust syntax a little difficult to read. Take "16i32" for example - it's not immediately clear which part is the actual value.

One neat thing Rust let you do is put underscores in number literals. It's great for readibility: 0xFFFF_FFFF // easier to count than 8 Fs And you can use that with type suffixes: let a = 255_u8; Although in that case, you'd probably either omit u8 entirely, letting the compiler infer the type of 'a' from usage, or use a colon to give it ane explicit type. Type suffixes are especially useful for arguments to generic…

You can do the same thing with C#, which is great for groupings, e.g. "2000000" becomes "2_000_000".

As a rust noob, I didn't realise rust supported the same syntax, or that you could use it to separate the type from the value (which in rust's case, I find really helps readability).

Re: A half-hour to learn Rust

#57

Post by cormacrelf »

fasterthanlime wrote: post #18
cormacrelf wrote: post #13

Earlier quoted context omitted.

I’ve seen this guy’s posts a few times lately, he needs to learn to edit things down. What he’s saying is good, but it is extremely digressive, and the digressions never seem to return to the original point. I’m not the audience for this so I don’t have that much time to spare reading it, but I can’t imagine that style working well for an introduction to a language.

I respectfully disagree but - can't make everybody happy. There's plenty of introductory articles to Rust in the style you desire :) edit: To expand a little bit, the digressions aren't just about me "getting distracted" while writing - they're very much on purpose. I always try and write pieces that expand in many different directions, because there's so much to discover, always. Some folks come to an article wonder…

I think I'm talking more about your Mr Golang piece, but now that I have your ear, I guess may as well. I am less concerned with the existence of digressions than the way they're introduced. When I say needs editing, I mean that because I cannot navigate the piece properly, it takes longer to understand what you're getting at if I want to, so it seems like it's too long. Editing down is only one solution to that.

An example of this is when I was really confused reading about path extensions and non-UTF8 paths. I was promised by Cool Bear that you had a point to make using an example about a stat call, but you were no longer talking about stat, and yet you were still writing as if it was central to your stat discussion. So instead of expanding, I thought you just couldn't express what was wrong with the stat call. I nearly gave up waiting! And I was surprised that, in the end, you could (and put it quite well). Unfortunately, there are thousands of thinkpieces out there that never make the point they promise to, instead just dumping information at you and hoping it hits you like it hit them. So I am trained to close the tab when that is happening.

It might help to state why you're going to digress before you do, with a promise to return, so that people who are hooked can be confident you'll eventually make your point (and may skip back and forth to digest your argument again without interruption). If nothing else, you are making a promise to yourself to structure things in a way that is friendly to the reader.

Rather than making the piece less exploratory, adding signposting helps get the reader into the mindset you describe in the last sentence there. Otherwise, they are not sure whether to be interpreting what you're saying as a core argument or some side discussion. It hurts both the exploratory and the argumentative qualities of the writing if one is confused for the other. Without making it clear, the argument runs like my first para above: unnecessarily long-winded and questionably relevant, with no exploratory levity. With good signposting, you get to nail both. It's about two sentences' and two headings' difference, maybe a little shuffling around.

Hope that helps, looking forward to your next one.

Re: A half-hour to learn Rust

#59

Post by fasterthanlime »

cormacrelf wrote: post #57
fasterthanlime wrote: post #18

Earlier quoted context omitted.

I respectfully disagree but - can't make everybody happy. There's plenty of introductory articles to Rust in the style you desire :) edit: To expand a little bit, the digressions aren't just about me "getting distracted" while writing - they're very much on purpose. I always try and write pieces that expand in many different directions, because there's so much to discover, always. Some folks come to an article wonder…

I think I'm talking more about your Mr Golang piece, but now that I have your ear, I guess may as well. I am less concerned with the existence of digressions than the way they're introduced. When I say needs editing, I mean that because I cannot navigate the piece properly, it takes longer to understand what you're getting at if I want to, so it seems like it's too long. Editing down is only one solution to that. An…

The Golang piece is definitely subpar, it was quickly thrown together in half a day, didn't expect it to be spread so widely haha.

For other articles there's usually a few days of research, and 1.5 days of writing and editing, then a lot of touch-ups in the following weeks/months responding to feedback.

Thanks for the more detailed criticism though - I agree with the general sentiment, and haven't solved the navigation problem yet!

Re: A half-hour to learn Rust

#60

Post by watmough »

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 did wonder about this, due to consumption of ... values / refs (terminology?) ... in Rust.

Thanks for adding this important detail.

Post reply on HN