this post was submitted on 02 Jul 2026
-39 points (35.3% liked)

Programmer Humor

32197 readers
707 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 3 years ago
MODERATORS
 

BTW I think some anti-Rust people are more annoying than the worst Rust evangelists - seen some of them calling people not using Rust as "murderers", because "memory leakage can kill at the right time" - but that's due to them being evangelists to right-wing politics.

top 31 comments
sorted by: hot top controversial new old
[–] Anders429@programming.dev 6 points 6 days ago

Imagine thinking the borrow checker is just "worse GC." Please at least learn about a language before you try to spread crappy memes about it.

[–] verstra@programming.dev 86 points 1 week ago (1 children)

What? You list metaprogramming as a plus? And functional programming as a minus?

You should rewrite this meme in rust.

thinks functional programming = bad

[–] RustyNova@lemmy.world 23 points 1 week ago (3 children)

Tbh the borrow checker isn't a problem for 75% of cases. If you actually need the performance/memory optimization then yes you will have to deal with it... Otherwise just .clone()

And if you find the borrow checker annoying in async rust, that's mostly a tokio issue. Look into smol-rs as it offers alternatives

If you want real cons...

  • Compile times
  • easy build time arbitrary code execution
  • trait bounds spaghetti
[–] cjk@discuss.tchncs.de 7 points 1 week ago (1 children)
  • viral async
  • viral lifetime annotations

🫣

[–] RustyNova@lemmy.world 2 points 1 week ago (2 children)
[–] Anders429@programming.dev 2 points 5 days ago (1 children)

I've done quite a bit of async programming and I can't quite figure out what people are complaining about here. Best I can tell, they just don't understand what async functions actually are.

[–] RustyNova@lemmy.world 1 points 5 days ago

Most of the time, async tutorial makes you learn tokio, not async. If your program can run with only tokio::main, then you learned async. If not, you learnt tokio (except if you are spawning a future that should never stop)

For example, my pet project only uses tokio::main to do async stuff. The only instances of tokio::spawn is make sure some SQLite transactions get polled to completion. I do need to replace them with a proper mechanism now that sqlx supports smol-rs

[–] cjk@discuss.tchncs.de 7 points 1 week ago (1 children)

When people say "async is viral" in Rust, they mean that once you make one function async, that change tends to ripple through the rest of your code. Any function that calls it usually has to become async as well so it can await the result. In turn, the callers of those functions often need to become async too.

This propagation can continue all the way up the call stack until you reach your application's entry point. The main exception is when you introduce an explicit synchronous-to-asynchronous boundary, such as by using block_on, which drives the future to completion without requiring the caller itself to be async.

[–] RustyNova@lemmy.world 5 points 1 week ago (1 children)

Yeah but it's not really a problem with rust but how the language pattern is made. It's the same in JavaScript/typescript, and Python IIRC

[–] cjk@discuss.tchncs.de 2 points 1 week ago (1 children)

It is Rust implementing the pattern. So... :P

[–] pupbiru@aussie.zone 1 points 5 days ago

along with most modern languages… it’s the way we deal with async when you don’t want callback hell. it’s just a complex problem domain

like… what… JITs are complex so that’s a problem for V8 specifically?

[–] flamingos@feddit.uk 2 points 1 week ago (1 children)

And if you find the borrow checker annoying in async rust, that’s mostly a tokio issue. Look into smol-rs as it offers alternatives

This is great until you want to use a library which is tokio exclusive, which is most of them.

[–] RustyNova@lemmy.world 3 points 1 week ago (1 children)
[–] flamingos@feddit.uk 1 points 1 week ago (1 children)

Huh, that pretty cool actually. I need to play around and see if this works with gtk-rs, channels get fairly annoying if you need to use them a lot.

[–] RustyNova@lemmy.world 1 points 1 week ago (1 children)

Keep in mind that it doesn't remove tokio from the stack tho. Don't use this to try to improve compilation time

[–] flamingos@feddit.uk 1 points 6 days ago (1 children)

I know, I read the description. It just looks like a nicer syntax around setting up a tokio runtime and sending code between runtimes. It'd still be nice to have a non-tokio options so stuff could be single threaded.

[–] RustyNova@lemmy.world 1 points 6 days ago

A lot of the time it's not about options. It's about not messing up the async pattern.

If you have something that either:

  • requires a lot of CPU time
  • requires to run permanently, independently to the caller's future polling. Then you can spawn it on a global tokio executor.

If not, just use future polling tricks like the futures::join!() macro or a stream with .buffered(). It won't be slower. The bottle neck is IO. Not the program.

Personally I even try to replace the heavy reqwest library with ureq + blocking, and it works perfectly and compiles faster (you can see that in the api_bindium crate)

[–] cockmushroom@reddthat.com 1 points 1 week ago

A forbidden compiler

[–] one_old_coder@piefed.social 12 points 1 week ago

Compile time borrow checker is equal to runtime GC, right...

[–] Kolanaki@pawb.social 9 points 1 week ago

"Don't look a gift horse in the mouth"

No, you probably should look into that horse's mouth to make sure there are no Greeks hiding in it.

"Beware Greeks bearing gifts"

Again, no. You should be wary of gifts bearing Greeks.

[–] eager_eagle@lemmy.world 7 points 1 week ago

being annoying online

hmm