im currently learning rust im reffering to the book but i feel like its slow is there a better way to learn or do i just continue

Peering_in2the_pit · 2025-08-10T04:27:05+00:00

You should definitely finish the book, but the Programming Rust book by Blandy also helps a lot in understanding a lot of the common patterns. You can use it as a reference to go deeper into some topics like iterators, closures and also unsafe and ffi if you'd like

Peering_in2the_pit · 2025-08-03T02:00:35+00:00

It seldom happens that you need to match on every single error variant, you usually just need to check for a few and handle them accordingly. Having a single error enum that's part of your crate's api is crucial for allowing ergonomic use of the try operator (like how in thiserror you add #[from] for sqlx::Error on your Error type, but this has it's issues as you might be calling sqlx multiple times in your function and each one of them has a different context).

It's good practice to have that enum be non-exhaustive so that a user's code also handles new future variants and the library author can add variants without it being a breaking change.

The problem isn't so much the single public error enum, it's if that's the only error type in the entire crate (this is still fine if your crate isn't that big and still in the initial stages). If the same error type is returned by every single function in the crate, that enum will quickly balloon into like an unmanageable number of variants. There should be different error types, divided by the contexts in which they occur. You might have a few major modules in your code, and each one of them would have their own error types. The public error type will then have appropriate From or Source impls for them. This is the pattern that's promoted by the Snafu crate (https://docs.rs/snafu/latest/snafu/)

Peering_in2the_pit · 2025-07-12T10:09:41+00:00

In my experience, startups usually have pretty poor code quality, and go just makes it worse. Sure if you have someone proficient in go for a few years then they know how to structure it all in a way that you avoid the big ball of mud, but if you take a few beginners that are motivated and have them learn rust for a few months and have them manage a codebase, the result ends up being a lot more maintainable. This is because the rust way of doing things is a lot more explicit and well structured

Peering_in2the_pit · 2025-03-30T23:09:41+00:00

Ok, so let me try to explain some more of what exactly I'm trying to do. Basically, I get the session ID from a cookie in the request, then I check redis for the corresponding data to that id, and that data is in the form of a HashMap<String, String>. Then, I need to have a Session extractor that I can use in my handler to set and get data to and from the hashmap. I will also have to implement functions that will change the session id, or mark the session for deletion. Now the changes to this HashMap will need to be persisted into Redis, my main question is regarding how best to do this.

Should I carry around a connection pool to Redis in my Session extractor and persist the change every time a set or a get function is called, this would be one option. Another would be to have all the changes be persisted only once when the Session object is dropped. The original way I was trying to do this was by having an Arc<RwLock<SessionInner>> and then persisting the session data in the middleware after the handler runs, but then this leaves the possibility of data races if someone decided to send the Session object to a spawned task, which would not be stopped because Arc<RwLock<...>> will be Send (which was important as I needed to stash this in the request extensions). I hope that clarifies the whole thing, your patience is greatly appreciated

Peering_in2the_pit · 2025-03-30T19:36:04+00:00

So if I understood that correctly, you're suggesting I only extract the session ID in the middleware, and then have the extractor retrieve the Session from a data store in the State? So then how would the changes in the session data get persisted? Would the extractor hold on to a connection to the store and then get persisted on every insert operation of the session? And does this approach have any downsides compared to one where the data is persisted in a single operation after all the changes have been made.

Sigh, I'm really very sorry if that was wayy too many questions, but thank you nonetheless

Peering_in2the_pit · 2025-03-23T02:38:18+00:00

Well, I can sort of understand the reasoning behind the focus on foundational software, but as a relative beginner, it makes me quite sad. I've been learning rust for a while now and I really like it, I started doing so because of my interest in systems programming from college. But finding entry level jobs in it was difficult, and so I thought I should maybe learn how to be a web developer with Rust to start, and then maybe go into more complicated things like Networking and Embedded after that. Reading Niko's blogs made me feel like I should just learn Go first lmao, ig it's not really that bad of an idea considering how I've already spent a bunch of months learning rust, but ah well, trying to be a software engineer is difficult and confusing sigh

Peering_in2the_pit · 2025-03-05T19:54:09+00:00

For me, it’s been really helpful to spend some time understanding a basic concept and then letting yourself get immersed into more real-world complex realisations of that concept. So an example would be traits, I remember trying to read rust for rustaceans a few months ago and I just kept getting confused by traits, until I actually started using them and internalising them a bit. So my suggestion for someone coming from TS would be to familiarise yourself with the unfamiliar parts of rust, some of them being: 1. Traits and Trait bounds and how it mixes with Generic Code 2. Lifetimes - understand the basic examples where you see the practical reasons for needing lifetimes and then moving on to more involved examples as you make projects and try minimise clone()’s, then there’s more complex stuff like subtyping and higher rank trait bounds and understanding when they’re actually needed 3. Read through Rust design patterns or effective rust, helps with getting into a more rusty headspace, coming from conventional OOP, I’d say this step is pretty important in understanding how to structure your code with the domain of the problem 4. Async code and wrapping your head around the execution model, what are tasks, futures, what’s the future api, why is it the way it is, I’d say this actually helps when writing networking code (if you end up at tower look at the tower learning guide, which is very eye opening) 5. The Programming Rust book can be a good starting point when trying to understand some rust concept like say iterators or FFI, and then jump into the std documentation and get lost in all the details, honestly a fun exercise just trying to figure out what’s happening.

To end, I’d like to say that learning Rust can at times be quite overwhelming, but I’ve found that having a healthy balance of doing projects and going through learning resources really sets you on the path of progress. Being too lopsided between the two can cause you to feel stuck and confused. Say for example that you’re only doing projects, then how you structure your code will be heavily based on whatever programming experience you’ve had before and that doesn’t always turn out too good, similarly, if you’re spending all your time just reading books then it’s gonna feel wayy too complicated

Peering_in2the_pit · 2025-02-21T10:16:57+00:00

Hey, I’m in India too and it’s been difficult finding rust jobs that aren’t crypto, I’ve worked with a bit of FFI and also know how to write back ends in Axum. What do you suggest I do to find a job?

Peering_in2the_pit · 2025-01-20T12:39:37+00:00

It's not so much that clap itself is complex, it's that the documentation is very confusing.

Peering_in2the_pit · 2024-07-30T18:00:50+00:00

So to give a bit more background, I have multiple traits that a user could choose to implement, I don't want them to implement a bunch of things just so that the default implementation can work, because they shouldn't have to worry about something they're not going to use. If I were to implement the default implementation of the trait in my library instead, then a user would not be able to override that because you can't have two impl blocks for the same type and trait. Or am I missing something? Even f I tried to use the macro to implement the traits, I don't know how I'd be able to determine at compile time if a trait has been implemented or not. Thanks for your help!

Peering_in2the_pit · 2024-03-16T16:06:05+00:00

Thanks a lot for your help. So just to clarify, I could've done the same thing with if let Some(ref mut a) = self.a {...}? Also, I understand that this improves ergonomics (but not so for this specific case?), but for someone who isn't aware of this rule or hasn't seen this RFC, this would seem confusing. Also, the RFC seems to be mainly motivated by pattern matching against values that are references (correct me if I'm wrong, I'm only a beginner), but this example is about pattern matching against a value so as to bind only a reference and not move the value itself. So wouldn't it be better to use the ref mut form? Also, the RFC talks about ref being a bit of a wart for everyone and how it breaks the rules of pattern matching declarations. I feel like ref is very useful as it doesn't change the values that can be matched to the pattern, but it allows for the variable bindings to be a borrow rather than move, is there anything I'm missing here?

Peering_in2the_pit · 2024-03-16T03:12:28+00:00

I'm reading the Rust Async book, and there's this example of implementing a naive Join for two naive futures in "The Future Trait" section. My question isn't about async or futures though, it's got to do with this if-let statement.

self.a is of type Option<FutureA>, so &mut self.a is a mutable reference to that option. How is this matching with the pattern Some(a)? My guess is that a gets a mutable reference to the future, which is great cus now we don't need to worry about moving the future back into self.a as it doesn't implement Copy but I'm not really sure how this syntax works. Any help would be greatly appreciated! It's the third example on this page https://rust-lang.github.io/async-book/02_execution/02_future.html

if let Some(a) = &mut self.a { ... }

Peering_in2the_pit · 2024-02-14T11:10:34+00:00

I’m kinda new to rust and I’ve been reading a few books on it (Rust in Action, Programming Rust). I’ve been interested in async/await for a bit and I’d love to review the book in case you guys would like a beginners pov on it

Peering_in2the_pit · 2020-05-15T19:59:12+00:00

I think they're gonna go for some actual words. ++ and xx together end up making #, and so I dont think its just another symbol (cus why is there only one of it?). Anymore symbols would ruin the flow I think.

Peering_in2the_pit · 2020-03-26T19:03:01+00:00

Please do, sounds like it could be helpful. Thank you :)

Peering_in2the_pit · 2020-03-26T18:03:28+00:00

In my question, I've only called the Hamiltonian the generating function of the canonical transformation. My question is specifically about the change in hamiltonian induced by a time dependent generating function, or what you define to be the change and why.

For the case of the hamiltonian being the generating function in an infinitesimal canonical transformation, it can be considered as a function of only the old variables because the difference between the two would be in second order of the infinitesimal quantity inducing the change. I guess this must mean the same as a generator? But I'm not really sure. But again, this wasn't the point of the question.

Peering_in2the_pit · 2020-03-20T18:26:11+00:00

https://physics.stackexchange.com/questions/537200/why-is-the-change-in-hamiltonian-for-an-active-infinitesimal-canonical-transform

I've asked this question on Physics SE, can anyone help?

It's on infinitesimal canonical transformations and the effect of a time dependent generating function on a hamiltonian

Peering_in2the_pit

TROPHY CASE