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

"Just" scariest language out there ;P

Being forced to handle both the happy and the error path is whats makes rust great though

(btw the try operator can do type conversions if you have the right From impls, then you don't need to manually map_err)

@12bitfloat *distinct screaming noises in general direction*

why can't it just be logical

@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

@jestdotty Can you post the snippet that annoys you?

@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

@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

@12bitfloat actor pattern what now

got a rust sample of what that means?

@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

@12bitfloat no clue haven't ran it yet 😭

Zig fan club, checking in 🦎

@12bitfloat

> actor pattern kinda like go

Or Swift, which has actors as first class language citizens.

@jestdotty
actors make sure that async calls don’t lead to data corruption due to concurrent mutation.
It‘s much nicer and safer than having do deal with mutex and locks.

@AlgoRythm what's zig? I love david bowie

@AlgoRythm seriously I was looking into writing audio, can it do sys programming?

@antigermgerm That's what it's for. It's essentially a way better C (and thus also without some of the higher level C++/Rust niceties like RAII)

Quite an interesting lang

@Lensflare what you're describing sounds like mutex

if I ask AI for a sample it writes me like 300 lines of redundant information and I'm bored

I'm on drugs that make me bored, so. you know. for the crazy everyone keeps insisting I have when it's just my personality and experiences

ok actors isn't even my problem here

there was an atomic arrays lib somewhere and that's far less architecture changes

I just wanted you be able to use a proxy generically and all the proxy management stuff be a method so I don't have to rewrite it every time

at least for now til I run into some other problem

@antigermgerm like others have said, it’s just an interesting spin on a c-like language.

It has a bit of syntax soup. It also has unorthodox ways of doing things. But once you get used to it, it’s very satisfying and interesting.

The compile times are also great compared to Rust