From Pythonista to Rustacean
github.com
github.com
Rust is easy to learn by reading (in order to understand programming concepts unique to the language, such as the borrow checker and lifetimes), but Rust is hard to learn by experimentation alone (trying 100 different syntax variations to see what compiles).
If you want to understand what Rust is mostly about, perhaps watch the "Firehose of Rust, for busy people who know some C++" video[2].
I confirm that it's a great book, easy to read, even if reading isn't usually your style of learning. Or you can jump in and look at the Rust by Example book.
I wanted to read through at least the bits that would be totally new and confusing to me in Rust - ownership, variable lifetime, references, etc.
I'm finishing up Chapter 10 and probably getting to the point where I'll need to start actually using the language to learn it, knowing there will be gaps to fill in later. I think Rust is such a broad language that it's probably better to start coding and cementing the basics instead of trying to learn everything all at once.
I read those parts and started coding, and ended up coming back to later chapters (and re-reading stuff that I didn't get fully until I started coding).
Imo, it isn't possible to read a book and actually understand what Rust is like (as may be possible with a lower surface area language like Go or Lua). I am about a year in and I am still learning about how the safety features of Rust dictate the structure of your language (i.e. pure functions, not passing references around everywhere, quite anti-OOP, what std library traits to implement).
I came from Python/Java, and the first thing I did was try to code the same way (creating smart pointers everywhere). Actually coding in Rust helps you understand when these approaches aren't good.
I haven't actually read anything that really explores this aspect of Rust. When to use enums, when to use std library traits (From/Into, particularly), when to use smart pointers were also quite important for me (Jon Gjengset has a lot of interesting on this on YouTube, his book is also great).
First: https://www.oreilly.com/library/view/programming-rust-2nd/97...
If you want to go deeper after that: https://nostarch.com/rust-rustaceans
https://www.oreilly.com/library/view/programming-rust-2nd/97...
Its a very comprehensive book but takes some dedicated effort to get through. It goes through most (all?) important concepts from barrowing to iterator traits to some async. Give yourself a fair amount of time to read this and find small projects to do along the way to reinforce your knowledge.
I actually don't write any of these languages anymore day to day, but not by choice (doing a lot of Kotlin and Typescript, both are fairly decent languages IMO)
What do you consider the best way?
What does it even mean to "start from zero" if you've learned so much about programming, be it on using databases or sockets or merging downloaded map tiles.
Read the book? Yes, that should be done.
This is a different approach from: how do I turn some code I wrote in language X to language Y? Similar to transliterating a spoken language versus learning it from the ground-up. Going from Spanish to Italian, you can kindof get away with word-for-word replacement in the same order and get the gist. You can't really do that with, say, Japanese, where there are far more rules not just of grammar but of register and assembly which are nonexistent in romantic languages. In other words, you might learn some vocabulary, but you'll face a big challenge to learning the language with this approach.
Both approaches are completely valid, but you'll get further (farther?) with one than the other. You may also realize you are using the wrong language for the project in the process. For example, when I first started heavily using PERL in the mid-90's, and then switched back to C, I was really frustrated I couldn't operate with strings and regexes so recklessly like I did in PERL, but that's because I was using the wrong language (C) for something that should have stayed in PERL.
I started by picking the topic which interests me the most, where I have a lot of experience in. I searched for the most popular framework in order to not risk using something shady.
Then I implemented the rudimentary things (in my case a warp based websocket server), used the book to help me understand the things that weren't clear, started adding the features I use the most, like JSON parsing and object construction, datetime handling, adding a task with an interval timer to notify all clients periodically.
Then I went to the client side with a new project based on tungstenite.
Now I have a basic idea of what the language feels like and enough questions to read the book with motivation, knowing what it is I want to know and why the book tries to tell me about other topics which I should know about.
I'm also watching a lot of YouTube videos, specially from the really good channel "Let's get Rusty", which goes through every chapter of the book and adds some additional related information. Then also conference session with topics that could be helpful.
I wonder if rochacbruno will accept a PR.
It mentions cobalt for an SSG. While I'm flattered (as the maintainer) atm zola would be a better recommendation until I can find more time to devote to cobalt.
Those were from just a quick scan. Unsure what else there might be.
In the former, there's (by default, and often good reason to maintain this) no allocator, so the allocator-based-collections used as the backbone of the article don't apply. In the latter, there's still a lot of manipulating byte arrays etc, as that's the interface between CPU and GPU.
Related to both domains: The article is about data structure manipulation, but in general, when I choose Rust, it's to interact with hardware. That's the magic; that's where the language transcends syntax differences. Ie various MCU peripherals, communication lines and buses, passing data to a GPU etc. I think that would be an interesting comparison to highlight.
I'm not disparaging the text, but pointing out that its general title hides its narrow scope.
Might be helpful for someone, my small contribution to how to get started with Rust by "keeping it close to Python" https://karimjedda.com/carefully-exploring-rust/
Advantages: many APIs are stellar, way less runtime debugging (you actually get benefits from the unforgiving compiler), a sense of control, great performances
For APIs: Serde is an absolute banger.
Less clear: significant reliance on crates (third-party library). They're much easier to use than in Python (`cargo doc` in particular helps a lot as it provides a one-stop shop offline API documentation of all your dependencies as well as your own project) and there's more flexibility, but a 0-dep project is not going to be easy if that's your ideal. Then again if you're doing API stuff it probably is not as python's stdlib is quite crummy when it comes to web applications.
I love the docs in the Python ecosystem as a lot of them contain guides, examples on how to use the library is real world context. Rust library documentation often feels like if someone gave you a schema of all the components in your car, but not a driver's manual.
Rust's rules also make some of the complexities... not entirely necessary e.g. an object with a Drop can stand in for a setup/teardown quite nicely, thus standard packages like tempfile obviate the need for specific support.
However it's nowhere near the comfort of a pytest: while Rust doesn't have more overhead (a test function is just a function with a `#[test]` annotation)
- the missing scopes above "test" can be dear (especially because pseudo-globals like lazy_static and once_cell don't get dropped so there's no real teardown at the session level), though obviously some is understandable due to tests being multithreaded-by-default
- rust test-support-types are more verbose than fixtures
- the reporting is nowhere as precise as pytest's assertion rewriting
- the lack of parametric testing is annoying for reporting and addressing perspectives: "hand-rolled" table-based testing is OK, but the lack of subtests makes reporting less than ideal, and the inability to (re)run just one of the parametric tests can be frustrating
- it's missing a lot of the nice CLI options of pytest, especially about test-sets and run caches: marks, but also stepwise, exitfirst, last-failed, failed-first, new-first
The type system does compensate, to an extent, as it limits the test-space. Tremendously so if you purposefully encode your invariants in types.
A caveat here - doctests end up compiled into a separate binary for every test. I tried turning my unit tests into doctests, because they felt more natural there, but test iteration time went from 0.02 seconds to 14 seconds :(
Also there's a standard command for running tests in Rust but not Python.
Although I read there are crates to help with this, and it's indicative of bad programming styles...
In Rust that's not really an option because the types are so much stricter, and the loss of certainty on the other side makes things less convenient. Instead you'd use a tuple or throw a quick struct together (tuple or not). Defining structs is so habitual that it doesn't really feel unnatural or heavyweight.
It's like using dataclasses in Python, except the language also becomes helpful when you do that.
The -ista suffix in some European languages which have it is not universally feminine.
English Slovak Italian
(m) (f) (m) (f)
fascist fašista fašistka fascista fasciste
racist rasista rasistka razzista razziste
https://en.wiktionary.org/wiki/-ista
The -ista suffix from Latin, where it is a masculine, appearing in that form in a number of Romance languages, and in French as -iste, is masculine. The English -ist comes from the Latin -ista.
Just curious, where have you seen this exactly?
I think I heard it once in real life, over the last decade, used by a non-technical manager. I’ve only read it a few times, online, also mostly by non-python users. I’ve never called myself a pythonista, and I’ve never known anyone who has. But, I also have never been in a group with individuals that know, or identifies as, a single language.
In this sense, as someone who is casually interested in learning Rust, the title "From Pythonista to Rustacean" told me this repo is very relevant for me! :)