3
jestdotty
10h

rust is just... so unclean. sigh

what's the point of these stupid verbose features if they're incompatible with any sort of adaptability

like I wanna return a retry-after header value but if I do then I have to both rewrite the good result path and the bad result path... with a bunch of map_errs. this feels like java

Comments
  • 2
    "Just" scariest language out there ;P
  • 1
    Being forced to handle both the happy and the error path is whats makes rust great though
  • 0
    (btw the try operator can do type conversions if you have the right From impls, then you don't need to manually map_err)
  • 1
    @12bitfloat *distinct screaming noises in general direction*

    why can't it just be logical
  • 1
    @jestdotty I meeaaaaan depends on what you're doing

    Rust is plenty logical but some things can be a hassle sometimes

    Can't really say much more without knowing anything about your code
  • 0
    @jestdotty Can you post the snippet that annoys you?
  • 1
    @12bitfloat aaaahhhhh!

    well it was this retry thing but I decided on sending the whole proxy object into it as a solution:
    previous: https://gitlab.com/jestdotty-group/...
    changed: https://gitlab.com/jestdotty-group/...

    now I'm bugged by this instead:
    https://gitlab.com/jestdotty-group/...

    these are not snippets cuz I'm lazy and jumped to another project til some bright ideas strikes me

    type signatures are cursed things on top of it by god
  • 0
    @jestdotty I get what you mean with the and_then() + .ok().... Yeah it can be annoying. You could rewrite it into a single and_then with the two conversions followed by the ? operator, but that doesn't improve it much (https://play.rust-lang.org//... )

    For your new problem, yeah those signatures are cuuuursed :P

    Async rust can be hard

    Though I believe a lot of those 'static and Send bounds are required because tokio requires those. I've heard other executors are more lenient (but also only can run the future on the spawning thread)

    As for Arc<Mutex<T>>: I think this is pretty much always a code smell. As you probably notice in your code, it results in a LOT of .lock().unwrap() which is giga ugly and also just leads to deadlocks

    I think its best for async rust apps to do more of an actor pattern kinda like go, where many independent single-thread actors communicate over channels

    My 2 cents :P
  • 2
    @12bitfloat actor pattern what now

    got a rust sample of what that means?
  • 0
    @jestdotty Hit me up tomorrow im waaay too drunk right now :D

    Not sure if actors make sense though. But you NEED to do something about those Arc<Mutex<T>>. Those are killing your code, at least to some degree
  • 1
    @12bitfloat no clue haven't ran it yet 😭
  • 1
    Zig fan club, checking in 🦎
Add Comment