What did you do lol

@jestdotty Looks pretty good honestly. I don't really know what in that code you're complaining about

I guess if you're complaining about having to "flip-flop" messages with new_messages: Instead of the .drain you could use a VecDeque: https://play.rust-lang.org//...

@whimsical You have defeated me, I kneel

@whimsical Besides rust which she is obviously whining about again :P

@jestdotty What langs do you typically use?

@Lensflare Except for functional ones

And now take a guess why you have never heard a singular product built with one...

Not really, actually the opposite to be honest

The who?

Im on now, where are you? :P

How are you measuring the leak? Mem allocators are generally pretty lazy about giving memory back so a reasonable increase in memory over time might be normal behaviour

Oh

Oh no...

@jestdotty Okay how do you not understand this 😭

You pass things up the call stack

No global variables

If you want your function to have the data of your program you pass it via a reference

@jestdotty Yeah but no kinda

I almost never use macros. What I'm saying is: Do what makes the most sense

A lot of what you are complaining about is easily solved with a function or macro. Why is it a problem if it can be solved that easily?

@jestdotty Global vars bad, local vars that you borrow to functions good

At least when doing Rust

@jestdotty slotmaps! Instead of each nodes doing the logic on their own, have a function which evaluates the logic *for* a node. That function gets passed &mut Context, which contains all the slotmaps for different entities. When you need one you query it from the context object

@jestdotty Yeah but you see how this simple macro made the "if error log and exit" thing so much nicer? Its about pragmatism! A little bit of complexity can make your life a whole lot easier sometimes

@jestdotty Rust is a serious tool for serious programs

Rc<RefCell<>> doesn't work. Don't use it. Its a crutch if you don't know how Rust works

Think about the ownership and how it naturally flows via borrows. Think in a tree-like way where the seed is in the main function on the stack and you delegate things down the call stack instead of having a bunch of autonomous global objects which do their own thing

It's not always easy (the downside of memory safety in a systems lang) but it does work very well

But you have to divorce yourself from the typical Java-like grug programming style. You can't program Rust like a junior level webshit who only produces spaghetti

Its a serious tool which has to be wielded with serious thought how to use it

@jestdotty Check out the Rust playground link I posted, I didn't write that code just for fun

Honestly makes me think you don't even try to understand my comments and then you cry about how rust is bad even after I showed you specific solutions to you problem

>.>

@jestdotty Obviously just calling other cli tools in a bash script is easier and shorter than writing it yourself in a programming language. That's why the command line rules!

But also: There are areas were Rust can be annoying but CLI tools are absolutely perfect for Rust

Input -> Processing -> Output, all very nicely tree-like starting from the stack. No global variables, long running subprocesses, async, etc.

That's the one thing where Rusts ownership model works *very* well. If ya can't make *that* work in Rust that's really just on you

@jestdotty Yeah, to be fair that exact pattern has also frustrated me in Rust

But if you just return Result<(), anyhow::Error> from your main function then `let x = y.context("oh noes!")?;` just works

If you really don't want Results (or cant) you could also write a quick macro to avoid the double indentations of a match: https://play.rust-lang.org//...

Rust is so flexible, you can always find a solution

@jestdotty let x = y.map_err(|e| *can touch error*)?;

or better yet with anyhow just

let x = y?;

if you don't need any special error handling

You can! You just have to learn the damn language

What part of the `?` operator is not concise? It's one character. Don't overengineer your errors for no reason and just use anyhow

I swear you're creating so many problems for yourself that don't have to exist

@antigermanist Lets settle on bayrisch because it sounds funny

@Lensflare Just trolling ostream :P

Obviously they should all be in german since it's the better language

@jestdotty Ah got it

A table-like approach can actually be pretty good if you use the slotmap crate (e.g. one slotmap/"table" per entity), that's how I'm storing stuff in my compiler! I really don't like Rc<RefCell<>> at all. With slotmap(s) you can keep your ownership in one place and give it out via &mut instead of having to lock the refcell everywhere. Much cleaner in my opinion! (but of course also no silver bullet...)

I understand your frustration with JS interop... it can definitely suck trying to map such a dynamic language to a super static one like Rust

dev.to is kinda gay (literally) but I guess you'll have bigger audience there

I'd make my own blog with a static site generator though, that's a lot cooler

Just don't use lifetimes and don't use mutexes

Spawn "single threaded" tasks which communicate via channels. If you need shared data use immutable lists/maps from the`im` crate. I think that would fix like 90% of your issues with Rust

Like I know you're doing mostly async and async can be challenging but from what I understand you mostly do web based stuff. It *really* shouldn't give you that many issues to write a http client with a bit of data processing

@antigermanist I mean, just don't miss the seat then or don't just throw your body down without feeling the seat with your butt

This doesn't seem like that big of a problem

Don't know if trolling or not...