Hey all! Read a lot of good things about Rust and I was getting pretty bored and often annoyed with building new FastAPI apps. I’m just getting started, from my research Poem seems to be doing the same thing as FastAPI kinda and I’m using SeaORM for the DB.
So far I’m loving it, Cargo.toml looks a lot like Poetry in Python but in VSCode it magically shows me the latest versions of all dependencies. Debugging is really nice because I can just copy & paste compiler messages into an LLM or Google them. It was a bit of a hassle to get all dependencies to work together and to get the thing to compile at first but now it works and I’m happy.
That being said is there anything else I need to know? I still have a very limited understanding of the whole ownership thing but e.g. I understand the benefits of passing variables instead of copying them so I guess that’s a start?
Please read the book fully before starting any real project. It will save you headaches later
I would love to! But with the time I have at hand I won’t be starting a project in the next 2 years if I try to finish the book first. I started coding with Java, then did a lot of Python & TypeScript and now I’m here. I’m mostly building CRUD apps nothing fancy, any idea which chapters of the book I could prioritize to make sure I’m not missing anything that would lead me to making really bad, hard to refactor decisions?
I don’t agree with the previous poster. There’s nothing wrong with diving in and figuring things out as you go, especially if that’s a way that you commonly like to learn. Everyone has different learning styles, and Rust can fit all those styles.
The main thing to understand is you shouldn’t let compilation errors discourage you. You will get a lot of compilation errors. And I mean A LOT. That’s okay, it’s normal, and it doesn’t mean you’re dumb or that Rust is an excessively difficult language. It generally just means that there’s some new piece of the language for you to learn before you can take your next step.
When you run into compilation errors, just read the error message carefully and see if you can understand what the problem is. Often the error itself will tell you how to fix it, but you should take the opportunity to understand why the fix is necessary. In every case there’s a reason that the language is putting limitations on what you’re doing. It’s to protect you from bad habits that other languages used to let you get away with. So understand what’s bad about what you were doing and you’ll rapidly grow as a developer.
If you can’t figure out what’s wrong from the compilation error alone, that’s when it makes sense to turn to the book. The error messages will generally include a reference code which you can use to get more details on the nature of the error. Googling that will lead you to online discussions and maybe entries in the Rust book. Otherwise there isn’t a real need to read through the book from front to back unless that’s a way you like to learn.
Thanks a lot! Yeah I’ve been doing that and the compile messages are honestly awesome, sometimes I’m not sure if I should react to every warning because it’s a lot of extra work during development, but it helps me understand what’s going on. I’m still puzzled about some of the details of the language but the community seems very nice and there seem to be a lot of resources. Thanks for the encouragement!
Yeah, maybe should be added that Rust front-loads errors. It tells you about them at compile-time, so that you run into less weird errors during runtime. This is a good thing, but certainly needs some getting-used-to when coming from Python.
If you like hands on learning, check out rustlings. It’s an interactive tutorial.
Thanks! This seems exactly what I’m looking for
Reminds me to actually finish the thing. Also, it actually has references to book chapters included, so it’s easy to dive in and take in more in-depth knowledge.
I would say:
- Avoid async if you can. It’s way more difficult and error prone than non-async Rust. Unfortunately a lot of web stuff insists on async.
- Don’t be afraid to
.clone()stuff to fix lifetime errors. It’s not optimal but consider that in C++ everything is pretty much cloned by default, and nobody ever said C++ was slow. - Use
anyhow::Resultfor error handling. It’s the easiest option.
Thanks! One of the reasons for choosing Rust was actually concurrency. So I’m building a bunch of endpoints that connect with some microservices and I expect to have many simultaneous requests. I’m honestly not like super senior but for the Python backends we’ve been building we always made everything asynchronous so I kinda got the impression that that would be necessary for my use cases. Should I also be careful with async functions when using Poem?
Rust async has quite a lot of footguns that other async runtimes don’t have. There are some listed here:
- https://www.qovery.com/blog/common-mistakes-with-rust-async/
- https://google.github.io/comprehensive-rust/concurrency/async-pitfalls.html
- https://bitbashing.io/async-rust.html
- https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/
Honestly if you’re using an async Rust web framework (which they pretty much all are) it may be the path of least resistance to still use async. But in general I would strongly prefer scoped threads, channels, rayon etc.
many simultaneous requests
Unlikely to be so many that threads would be an issue.
Thanks! This is something I had no idea could be an issue. I just started standing up all the dummy functions for the different layers so I’ll take a step back now and review the resources you pointed me at. Also, in the Poem docs I don’t see them using async functions either. I’m very glad I asked.
I always recommend these tutorials to folks for learning about ownership, as they offer a very visual explanation: http://intorust.com/
You can skip the first two chapters.@echodrift there’s something funny going on here. I dunno what tho! Is this image hidden on your website somewhere? Didn’t see it in the post.
Honestly I have no idea wtf that is and luckily I don’t see that when I open the page! Seriously wtf
Uhm, yeah, that’s interesting. Programming.dev is a Lemmy instance, which is basically federated Reddit, so this could be any sort of user-submitted image.
Unfortunately, the screenshot you posted doesn’t make it to this side of the federation, so I’ll embed it for people here:
@Ephera ah, the fediverse, what can’t it make slightly broken? 🤣
Re: programming dot dev, that makes more sense - I didn’t look around much but as a reddit-a-like it surely has links to “nearby” content hanging out around the main body of the page, and whatever logic in Mastodon (or my client?) that seeks an image to embed must’ve reached a bit far.
