I'd go as far and say that all of it is, by definition, idiomatic.
I guess I'm saying, you could reasonably change the book's title to "Idiomatic Rust".
I'd read that first and then look into what bits it doesn't cover. That could be worth a blog like the one this is about.
you gotta work on this more before putting it on hacker news
Not very idiomatic to not use the builtin code formatter...
Is there anything more than part 1?
OP, this is just feedback and I hope that you'll continue documenting your rust journey even if it's just for yourself.
I've recently started learning Rust, and I'm finding it incredibly interesting! However, I'm also encountering a wealth of new syntax, built-in functions, and concepts that are unique to Rust. To solidify my understanding and create a useful resource for myself (and hopefully others), I've been diligently documenting these discoveries.
I've decided to share these insights by starting a blog, where I'll delve into the idiomatic Rust behaviors I'm learning. I've already compiled a substantial collection of examples and plan to discuss them in detail. My goal is to maintain a regular posting schedule, reflecting my ongoing learning journey.
I'd love to hear your thoughts on this project. Additionally, I'm eager to learn about your favorite idiomatic Rust patterns. If you have any specific behaviors or concepts you'd like to see covered in my blog, please share them! Thanks in advance for your feedback and suggestions.
I hope some of these are unique to Rust. Let me know!
As someone else said, I would like to see a TOC instead, personally.
I've addressed the mobile viewing issue. I'll also be working on adding a Table of Contents.
As I'm new to Rust and unfamiliar with unconventional programming paradigms, I understand that some of the concepts I'm exploring may not be idiomatic for experienced programmers. My hope is that this series offers something new to everyone, and I'd be happy if it introduces even just one new concept to someone. That would be my contribution to the community.
What parts in this article do you think are unconventional?
I was struggling to think of a time I'd ever given a type annotation to an integer local variable - because normally the place the variable ends up dictates the type.
Local variable becomes part of struct? Struct dictates type. Passed into function? Function dictates type. Multiplied by other variable and then that is passed to function? The type is determined by the function.
The technical arguments for one or the other option are available in a bunch of places, but no good guidance on an idiomatic default.
Rust
simplifies
numerical
variable
initialization
by
allowing
type
annotation
directly
within
the
value
assignment.