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

121–130 of 150 posts

Re: A half-hour to learn Rust

#121

Post by AnimalMuppet »

kzrdude wrote: post #114
runarberg wrote: post #106

Earlier quoted context omitted.

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.

Well,

  drop(x);
is a lot clearer than

  x;

Re: A half-hour to learn Rust

#122

Post by jerf »

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 think there's a good chunk of it that's just nerd-sniping.

Some it was just a sort of stand-alone complex, too; people started writing monad tutorials because people writing monad tutorials was the thing to do. In the Go community, there was a run for a couple of years of people making stupidly overoptimized HTTP routers, even though there's very few websites where that's actually the problem and even fewer where the answer was to create a fancy router. Why? Because other people were making stupidly overoptimized routers. It was a smaller instance of the same thing and ultimately damaged the community less than I think the overfocus on monad tutorials did for Haskell, but it was not the best thing for Go.

Monad tutorials did have a particular problem, though, which is that rather a lot of them were wrong, too. I made my own list of issues here: http://www.jerf.org/iri/post/2928 That particular post is in the context of people trying to implement "monads" out of Haskell, but the misconceptions I list tended to come from the lower quality Haskell tutorials in the first place. Then, as is the way of things, the wrongness spread around the world before the correction had its boots on, as the saying goes.

Re: A half-hour to learn Rust

#123

Post by dmitriid »

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 correct way is to write > int arr[4]; > and to interpret it as "arr[4] is an int"

No. The "interpretation" is "arr is an array of ints", and that is its type.

The complexity of this declaration is evidenced by the fact that you spend another page of text "randomly" adding characters and delimiters around variable declarations to change its type:

  int arr[4] // array of ints
  int *arr[4] // array of pointers to int
  int (*arr)[4] // pointer to array of ints
These are all changes to type. Yet, instead of changing the type declaration, a bunch of stuff is added all around the variable. And you have to come up with ridiculous explanations like "arr[4] is an int which makes arr an array of ints".

That's exactly why most languages said: "if we're changing the type, we're going to reflect this in the type". In a better world the examples above would be something like

  int[4] arr; // array of ints
  *int[4] arr; // array of pointers to int
  *(int[]) arr; // pointer to an array of ints

Re: A half-hour to learn Rust

#124

Post by rcfox »

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?

When I was learning C 20 years ago, it felt like the C tutorials were really hung up on how scary pointers were, in a very similar way to Haskell's fixation on monads. It got to the point that I questioned my understanding pointers because I didn't get why everyone spent so much effort on explaining them.

Re: A half-hour to learn Rust

#125

Post by vajrabum »

dmitshur wrote: post #115

I really enjoyed this, and it also inspired me to try a quick experiment: what would the same blog post look like for Go? I tried it and wrote https://dmitri.shuralyov.com/blog/27 . It was a fun exercise to go through.

I did enjoy the article. It was quite clear but it made me wish for a bit more. Unlike the Rust article I didn't see any thing that suggested how golang might be special. I did see your suggestions for further reading though. I'll check them out.

Re: A half-hour to learn Rust

#126

Post by bschwindHN »

jokoon wrote: post #32
bschwindHN wrote: post #14

Earlier quoted context omitted.

How about `let x = 42` and let type inference do the work? I used to do a lot of C-style variable declarations in other languages but I'm warmed up to Rust's really fast because most of the time I don't need to explicitly name the type.

"let" should be removed, and it doesn't change that the type should be placed before, not after with a colon.

lol okay, how about you just stick with C then since you like it so much.

Re: A half-hour to learn Rust

#127

Post by bogomipz »

dmitshur wrote: post #115

I really enjoyed this, and it also inspired me to try a quick experiment: what would the same blog post look like for Go? I tried it and wrote https://dmitri.shuralyov.com/blog/27 . It was a fun exercise to go through.

Thanks for sharing. I enjoyed this. Could you elaborate on your closure example though? This was the only one I didn't understand. The explanation is a bit terse = "Closures are just variables with a function type with some captured context." Are these anonymous functions? What is calling the anonymous function if so in main? Cheers.

Re: A half-hour to learn Rust

#128

Post by da-x »

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.

There's a difference between

    let _ = ;
and:

    let _x = ;
The first one drops ownership over the variable right after `let`, and the second drops in the end of the scope where the `let` is contained. It was mentioned in an open Rust github issue, but I can't seem to find it.

Re: A half-hour to learn Rust

#129

Post by da-x »

galfarragem wrote: post #62
talkingtab wrote: post #50

This is the most useful introduction to a language I have ever read. Often language introductions produce a "Wall of Complexity" and I failed in my last two attempts learning Rust failed because of that. This is just great. Be warned, the "half hour" part is probably a bit like "99 cents" as a price tag. I've already spent more than that, but it is time well spent. Thanks for writing this!

You might like this: https://learnxinyminutes.com

I wish this could be extended to "Learn X in Y minutes coming from already knowing Z". However this (X,Z) matrix is hard to maintain...

Re: A half-hour to learn Rust

#130

Post by pandaman »

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?

You can write useful C programs without ever using bitwise manipulation. It's quite hard in Haskell without monads since the standard I/O library is a monad. You are limited only to evaluating values with REPL unless you use a monad. And, because the I/O is a monad, you cannot just say "use this function to read input and this other function to print output" so you need to explain the whole monad situation early into the language study.
Post reply on HN