fritz posted:

Had a failure of intuition today.

code:

struct Dummy {
   pub data : Vec<f64>
}

let mut data : Vec< (usize, Dummy) > = Vec::new();
let mut table : HashMap< usize, Dummy > = HashMap::new();
// data gets filled somewhere along the way
for (i,j) in data {

   table.entry(i)
   .and_modify(|v| *v = j)
   .or_insert(j)
}

rustc errors at the or_insert because j is already moved in the and_modify. I'm confused because I would have thought that it wasn't possible for both code paths to execute, i.e. if it goes thru .and_modify, it won't go thru .or_insert, and vice versa.

gonadic io posted:

With stuff like that, ditching the functional constructs and using an explicit match is usually enough to fix it these days, because the borrow checker can see through them in a way it can't for closures . Or just clone or copy.

notwithoutmyanus posted:

Well I haven't seen any other languages using :: or <> like that. In that sense I was more used to JavaScript with function.thing

gonadic io posted:

Don't use actix web if you can help it imo
It's pretty abandoned. We still have the legacy of actix itself at work and it's painful every day.

Love Stole the Day posted:

Here's what I came up with. Please flame me, starting with the lack of unit tests and functional tests: https://github.com/wanderrful/myaxumserv

Readme has a sequence diagram to show the separation of concerns, along with sample curl requests to run, if you build and run it locally

prom candy posted:

This is cool! Not a Rust-specific critique but organizationally it kinda feels like there aren't clear boundaries between the responsibilities of Resources and Managers. If I was building a framework from scratch I'd probably omit Managers but provide examples of how to call encapsulated service-layer code if necessary. Just my two cents.

prom candy posted:

My thought is more that the Controller-type resource (actually Resource in this case) should be responsible for taking in a request and returning a response and anything beyond that is potentially overly prescriptive. A Manager pattern could be a recommendation ("Help, my Resources are doing too much!") but from my general experience working with web frameworks if I had to pick between one object or method that's doing a bit too much vs. two objects or methods that appear to be tag teaming the same simple task. That said I've been finding myself preferring longer functions in code in general lately and that may not be a majority opinion. A lot of the stuff that I took as gospel about programming from OOP gurus like short methods and SRP I've started to discover can actually just make it really hard to find where the actual behaviour you're looking for is.

Again just my opinion.

M31 posted:

Rocko Bonaparte posted:

I am late to the party, but I saw a lot of talk of stuff being "managers." That's always been a cringe sign for me that I don't know where my abstractions really are. I can't think of a better term but I know there's something in common, so it becomes a manager.

I still suck at the traits stuff and how abstraction is done in Rust, so I don't have any better thing to say about that. Even if I did, the situations are all contextual and independent of each other. I just wanted to flag a potential code smell.

The March Hare posted: