> And here's a toilet closure: |_| () > Called thusly because |_| () looks like a toilet. Pure poetry! Real talk though, this is a great introduction.
I often use the "owl" , usually in Result.
A half-hour to learn Rust
51–60 of 342 posts
Re: A half-hour to learn Rust
#52A half-hour to learn Rust Jan 27, 2020 · 51 minute read · rust maybe the site's reading time estimator is broken? sarcasm intended. But seriously, it is good to have people writing things like this.
Programmers don't read, they skim in half the time, then auto-complete in their mind with false assumptions!
That would explain so many of the comments you read on HN and Reddit!
Re: A half-hour to learn Rust
#53Reminds me of this also: https://cheats.rs/
Re: A half-hour to learn Rust
#54That is the best article on Rust I've ever seen. Better than the Rust book. I've been saying that Rust needed a book that wasn't written by the designers of the language, who are too close to it. Now we have one.
But it only covers the very basics. Disclaimer: I've only scrolled through it, but the code snippets are all small. It does show an admirable amount of Rust's syntax, but it's not very discoverable, whereas the book is reasonably well structured (although not for novices, who have forgotten a specific term). The link also doesn't deal with larger programs: there's not an Rc on the page, let alone something like an Ar…
It's your opinion and I'm not arguing: a lot of people love the Rust book, but some (including me) simply can’t read it because of the style of writing and cases when you discover some interesting and deep topic but the author just gives 1 example in 5-10 lines of code and that's all. I think that things like Mutexes or Boxes are deep enough to have 30-50 pages dedicated to them, and I can say this not only about Mutexes and Boxes. When explaining some powerful things, one need not only explain how they work, but also what kinds of real tasks they can solve - ways of usage are obvious for you when you know it and have experience of usage them, but absolutely opaque and not obvious when you reading about them for the first time.
Re: A half-hour to learn Rust
#55Re: A half-hour to learn Rust
#56Re: A half-hour to learn Rust
#57A half-hour to learn Rust Jan 27, 2020 · 51 minute read · rust maybe the site's reading time estimator is broken? sarcasm intended. But seriously, it is good to have people writing things like this.
Programmers don't read, they skim in half the time, then auto-complete in their mind with false assumptions!
And then try to write a GUI in Rust.
Re: A half-hour to learn Rust
#58It's a great resource. I like such easy list approach, because many times new language just needs a translation from concepts you already know.
I have a problem understanding how temporaries work in Rust. At least from what I see there is a difference between a temporary inside a vec that I bind somewhere to then pass it somewhere and a temporary inside vec constructed inside method invocation. I asked on SO [0], but did not receive satisfactory answer, or I'm too dense to understand it.
[0] https://stackoverflow.com/questions/64705654/why-i-get-tempo...
Re: A half-hour to learn Rust
#59This is great!
You probably want to add feeling_lucky: bool as an argument to fair_dice_roll()
Re: A half-hour to learn Rust
#60Earlier quoted context omitted.
I often use the "owl" , usually in Result .
Why use a Result whose error type is empty?
I should have said :) I am writing backtracking algorithms (think something like a Sudoku solver where we fill in values by guessing), and an 'Error' is when we can deduce the Sudoku cannot be filled in, so we have to backtrack.
I find Rust's ? notation gives a very natural way of writing such algorithms. I don't care "why" filling in the Sudoku failed, particularly because the solver will typically fail millions of times a second, so I definately don't want constructing the error to be expensive in any way.