I think things like this are great, but you have to keep in mind WHAT they are good for. This is NOT going to teach you Rust. What it is going to do is very quickly get you familiar with the ecosystem and relate it to something you know already. This can be helpful as you are learning to help you feel less inundated by all the new concepts and crates. It also will give you a quick and dirty on how a basic concept maps between what you know (Python) and what you don't yet (Rust). In no way does this take the place of a good tutorial or book on Rust for learning the language, but instead I would equate this more with a reference book which you use for targeted inquiries, not ground up learning.
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'm mostly a Python programmer (10 years), and spent a night last week reading the first ~8 chapters of the Rust book, and working slowly through the rest.
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.
The stuff you mentioned are the key points, it is where Rust really diverges from other languages (also traits, enums, smart pointers).
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).
The book is really good, but unless you absolutely love reading technical material I contend you should not read it cover to cover. Read what you might need to solve your current issue and keep doing that until you no longer need it, sure. Anything more just kept sending me to sleep until I said "fuck it" and just started writing things that are useful.
I like "the book", but I felt more prepared for the real world after reading the O'reilly book, 2nd edition. That was sufficient for me to write any code I needed. If you want a deeper understanding, "Rust for Rustaceans" is a great book (disclaimer: I only read about half of it - too busy coding :-)
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)
Generally I don't care for these lists because the best way to learn something doesn't change depending on your background as much as people think it does. But I do like the list of roughly equivalent tools/frameworks.
Also not OP, but I find the best way to learn a new language is to attempt a project using just the documentation. In my mind, the documentation for the language should provide methods, paradigms, and patterns required to think in that language (and get the benefits). E.g., Starting as complete noob and following the rules as written by the language itself.
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.
Not OP, and probably also not the best way, but it works for me:
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.
not op, but i often see people trying to push their old mindset on a language they are learning, which is a bad approach. maybe i miss sth, but i don't see how any knowledge from python is applicable to rust. so it may be beneficial to clear your mind and go from zero.
It's not that different. You'll obviously have to learn about how Rust uses variables and how to do the error handling, but it's not like Rust gives you some freedom in how you do it. It either compiles because you did it right, or it won't compile. It's really strict about it. Of course reading about the differences is important since things like "move" don't exist in Python, but it's great if you have something which is working in Python and start coding a Rust version of it.
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.
It says the Org for it is Mozilla Research when its now the Rust Foundation.
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.
Anecdote: I find my Rust code doesn't resemble the syntax examples in the article. Why am I using Rust? Because it's fast, is good at interacting with hardware, and is suitable for certain domains where there aren't many alternatives (and it happens to have key advantages over the alternatives). Ie: Embedded, and computer graphics.
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.
This has been a great help to get started but was missing the "guide me through it" part for me. I wrote an article with some code samples for writing Rust code coming from a Python background (data engineering). It's great to see many "Pythonistas" getting interested / curious about Rust. I'm certain there is a lot of good things in both languages even though the onboarding experience is a bit more hands on with Python.
I am really curious about Rust after looking for API proxies (in particular Linkerd2 - https://github.com/linkerd/linkerd2-proxy). Can anyone share her/his experience on going from Python to Rust? (bonus point if related to API :lol:)
Drawbacks: the learning curve is steep, the compiler is not forgiving, the pre-debugging throughput is low, you start missing many APIs when you have to go back to Python, missing some useful niceties (keyword & default parameters, comprehensions, generators, ...), harder to do quick experiment or lookey (no REPL, no -i).
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.
Cargo docs is a bit of a curse for me. A lot of crates have docs only through that mean and think just having a few lines of intro is enough and then we'll good luck understanding the library.
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.
The good part is that it's built-in, and tests can be "whitebox" (inside the file they're testing and with access to everything) and "blackbox" (outside of the crate, and with only access to public APIs). They're also multithreaded by default, the reporting is OK, doctests of doc-comments are on and enabled by default. So the OOTB experience is mostly better than Python's unittest I think (though the reporting is not as good as it's missing the slew of dedicated methods and corresponding precise reporting).
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.
> They're also multithreaded by default, the reporting is OK, doctests of doc-comments are on and enabled by default
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 :(
Yeah I've not been too bothered about missing dict literals so far: in Python dicts act as quick structs, you throw a few items in and carry your unit around.
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.
Who said it’s for onboarding? It contains good resources, a quick overview of some crates and tools and shows some quick comparison examples - all good things for people who haven’t really touched rust. It won’t shape a developer for life, or even a week for that matter.
I thought the post is about an excellent iOS App - Pythonista, a Python IDE and at the same time a collection of Python wrappers over iOS APIs that gives you the possibility to create custom actions and automations right on your iPhone
I've always wondered... Do people really say these words out loud? I've never heard anyone describe themselves as a "Pythonista","Gopher", "Rustacian" etc IRL. But I also don't work a ton with those languages.
> Pythonista is what python developers call themselves.
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.
I heard it more often circa 2010 when I was active in my local python user group. Usage has definitely waned along with some more of the cute aspects of pythonic culture, like referring to pypi as the cheese shop. I think it's because more and more companies started hiring specifically for python, and it became something developers were forced to use, as opposed to something that people chose to use because they loved it.
I'm a big Python advocate. I'd never call myself a "Pythonista" if asked to describe myself, but I do see "Pythonista" as something that describes me.
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! :)
There isn't a productive -ista suffix in English; it occurs in loanwords, or words created to ironically mimic a foreign language in the Romance family ("fashionista").
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
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.
