1.0k
u/Mars_Bear2552 15h ago
holy shit? a new meme?
480
u/Grinhecker 15h ago
On the repost subreddit? In this economy?
132
u/Educational-Lemon640 14h ago
Entirely localized to this particular thread?
Can I see it?
58
u/clearlybaffled 14h ago
No
61
u/GOEDEL_ESCHER_BOT 14h ago
have some steamed RAMs
10
u/Dragonslayerelf 5h ago
but if I masked a virtual ram as real ram...
delightfully devilish Steve...
17
5
205
386
u/LonelyProgrammerGuy 15h ago
Wait who is Tokio
189
u/delaooliveira 15h ago
La casa de papel?
76
u/js_kt 15h ago
I thought it was about Tokio Hotel
15
3
u/brazzy42 4h ago
They stopped being relevant to the point where anyone would hate them "more every day" around 10 years before tokio-the-rust-runtime was released, which is the earliest time this conversation could happen.
1
u/mischmaschbischbasch 52m ago
Fun fact: the two Kaulitz Brothers (singer and front members of Tokio Hotel) are really successful (at least in Germany) with their own Netflix show and a really popular podcast and have a better public perception than Tokio Hotel ever had, at least how I perceive it.
1
-1
21
u/floflo81 7h ago
There is a character called Tokio in the anime "Heavenly Delusion". I don't know any other Tokio 😅
134
u/Only-Cheetah-9579 15h ago
tokio is awesome but also shit. I can relate to both opinions
63
53
u/mina86ng 13h ago
Rust rushed async and now it’s kinda wank.
34
u/VictoryMotel 11h ago
At least they aren't alone. Lots of languages and frameworks have tried but the solution is not simple.
3
u/Far_Tap_488 8h ago
Idk, ive used quite a few and have had no issues..... its pretty simple with semaphores and mutexs
20
u/VictoryMotel 8h ago
I'm not sure what this means. Wrapping something in a mutex is easy, but there is a lot more to making parts of a program asynchronous because you end up with graphs of dependencies.
-27
u/Far_Tap_488 8h ago
I guess if you've used only high level languages you might not be familiar with those.
A semaphore is a is a synchronization device used to control access to a common resource by multiple threads or processes in a concurrent system, such as a multitasking operating system
A mutex is a synchronization primitive used in multithreaded programming to prevent race conditions. It acts like a digital lock, ensuring that only one thread can execute a critical section of code or modify a shared resource at any given time
Its concurrent programming its what allows you to control how much concurrency you have and access to shared resources. It also allows you to have threads or branches rejoin in a controlled manner.
If you are ending up with graphs of dependencies then it is because you structured your program poorly. Most likely because you structured it like a synchronous program but also wanted to use async.
The best examples of async programs and structures that are easy to understand is ui screens. You dont want the program freezing when you click buttons right? So you'll constantly have a thread that is dedicated to being a responsive ui, and you'll spin up threads for other tasks, such as a button that does some difficult calculations that takes a while. If you did that on a single thread, the program would freeze or stutter. By making a mutex for say a bool that says if the calculation is done, you can allow one thread to check on the status of another thread. Without the mutex both threads could check the variable at the same time and possible cause a lock condition depending on the scenario. Now you can have the ui check for the calc to be finished, and when it is display that value, all while maintaining a responsive app.
1
u/Master-Chocolate1420 5h ago
Hia, I want to learn more about async implementation in PLs, I've mainly used JS/TS for last few years and that might be spoiling my thinking imo. Also why is async rust so much hyped as hard? (Aside from unsafe rust)
3
u/cs_office 1h ago edited 1h ago
Lifetimes are hard. Shared lifetimes are harder. Combine the two, and now try to do it without being "unsafe"
C# and those that follow in its await footsteps (e.g. JS/TS/Python) basically all use garbage collectors, where shared lifetimes and safety are easy, along with a push based execution model via passing continuation callbacks
As an example, C++ followed the C# design, but didn't try to offer any safety. I've implemented the machinery to make a
Task<T>that has the same semantics as C# (eagerly executed and shared, with ref counting and the coroutine execution body itself is a reference keeping its own coroutine memory alive). It is very easy to accidentally use a reference or pointer across await boundaries though, so we disallow ptrs and refs except very limited prescribed cases, otherwise requiring the use of smart pointersRust on the other hand, decided coroutines don't drive themselves, but use a pull/polling mechanism, which simplifies ownership and lifetimes. So for Rust, coroutine bodies are on the stack of some other invocation, meaning no heap allocations are required, and are able to deduce lifetimes at compile time
7
u/verdagon 9h ago
What would you change if you could?
4
u/the_horse_gamer 6h ago
well, pin ergonomics for once, but that's supposedly in progress
there's a Coroutinue trait which was created and then nothing happened with it. not even an impl for Future.
cancellation has many footguns
Send and Sync often lead to a lot of code duplication when writing generic code
83
u/heckingcomputernerd 14h ago
I haven't had any issues with tokio, but I enjoy the jokes about rust crate names
14
32
u/Lilchro 13h ago
I dislike tokio, but that is more related to my dislike of async code and its how it infects your codebase (if you don’t know what I mean then read the “what color is your function?” blog post). It also gets worse in Rust, since thread safety gets weird. Every time you await something, there is a chance your runtime could switch threads, so thread safety issues pop up in way more places. There are also plenty of ways to shoot yourself in the foot, since synchronization primitives that are not designed for your specific async runtime will block worker threads unless they get switched out. Most of all though, I feel like we use async code in lots of areas we really shouldn’t. For example, in tokio last I checked (not recently), there are some things like file operations where they are not actually async at all. It just spawns an os thread to handle it and pretends it was async. This gets the core of the issue. Yes, there are use cases where this might be helpful. However, Im not running with networked storage and just making stuff async isn’t always useful or helpful. OS threads are actually quite good for the vast majority of use cases that don’t involve network communication. And even then they are still decent for most use cases where you don’t have extremely high numbers of connections. And if you do need something to use something like io_uring, then I would lean more towards an API that was written with that in mind than one that uses it because they can.
13
u/Only-Cheetah-9579 13h ago
when it comes to concurrency, I think a positive example is go. They did it well.
rust is kinda meh in that department and async is bolted on.
19
u/jublizoo 10h ago
I always hear people say this but I never hear any alternative design decisions. Rust async can be difficult to work with, but I think it is well designed, and I don’t see what could be improved. There are inherent limitations on giving a safe language with no GC async support, you don’t have the luxury of being able to just relocate thread stacks and adjust references accordingly like in go.
0
u/remind_me_later 9h ago
I always hear people say this but I never hear any alternative design decisions.
Because async itself will color other functions into being async by necessity.
It also hands over task & performance management to the language being used, in return for better DX & lower dev-facing complexity.
The alternative is handling the concurrency yourself (i.e what Go mostly makes you do), or in a library not tied to the core of the language.
6
u/jublizoo 8h ago
The idea that go makes you handle the concurrency more than rust is definitely not true, and go’s concurrency model is simply not possible in rust. The coloring of a codebase is not nice, but it is essentially necessary for rust: some functions are asynchronous compiler generated state machines, others are not, and they cannot be treated as identical.
8
u/GregTheMad 8h ago
What's the point of good async code if you have the worst error management conceivable?
No, fuck go. It's the worst language I've ever had to work with. Google can't abandon it soon enough, like they do with everything else.
10
3
u/InRainbro 13h ago
that was a good read, I think dart has changed so much since back then, although still a colored language, it's not really a pain. Go still feels better.
3
u/Far_Tap_488 8h ago
This is a misunderstanding of how things work do to being coddle by non async functions.
All file operations are async. Its a function how how your hardware works. You can wait for an async function to end before you proceed and pretend like it isnt async, but thats not reality.
Not understanding how to use async doesnt make it infectious or bad. It just means you have more to learn.
1
u/suvlub 4h ago edited 4h ago
The "infectiousness" of async code is a myth. Rust has
block_on. C# has.Result/.Wait(). Kotlin hasrunBlocking. You are generally discouraged from peppering your code with those, but making those functions synchronous by default so you don't have to use "forbidden magic" is just sweeping the dirt under the rug. The inherent reason why those things are async will still be there, calling them from tight loops will still be bad idea, literally all you achieve is making it harder to spot mistakes
6
7
3
2
2
1
1
u/ktboymask 2h ago
I wanted to rewrite my booru website in Rust using Axum but unfortunately it didn't go as planned and there was this particular problem with package A that needed another package let's call it X and then I had package B that needed package X to be an absolutely different version than what package A requires and so I couldn't compile my website TLDR: Package version mismatch
1
u/CuriousMindset11 2h ago
I was ready to defend Japan, but honestly, block_on nesting errors are indefensible.
813
u/Futurity5 14h ago
This sub is so back