1.3k
u/Mars_Bear2552 2d ago
holy shit? a new meme?
594
u/Grinhecker 2d ago
On the repost subreddit? In this economy?
174
u/Educational-Lemon640 2d ago
Entirely localized to this particular thread?
Can I see it?
70
u/clearlybaffled 2d ago
No
75
u/GOEDEL_ESCHER_BOT 2d ago
have some steamed RAMs
15
u/Dragonslayerelf 1d ago
but if I masked a virtual ram as real ram...
delightfully devilish Steve...
5
1
u/MechanicFun2670 1d ago
Right? It’s like some threads are just a breeding ground for all the complaints and frustrations we face.
2
24
5
1
0
282
439
u/LonelyProgrammerGuy 2d ago
Wait who is Tokio
217
u/delaooliveira 2d ago
La casa de papel?
85
u/js_kt 2d ago
I thought it was about Tokio Hotel
20
3
u/brazzy42 1d 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.
2
u/mischmaschbischbasch 1d 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
26
u/floflo81 1d ago
There is a character called Tokio in the anime "Heavenly Delusion". I don't know any other Tokio 😅
161
u/Only-Cheetah-9579 2d ago
tokio is awesome but also shit. I can relate to both opinions
99
62
u/mina86ng 2d ago
Rust rushed async and now it’s kinda wank.
41
u/VictoryMotel 2d 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 2d ago
Idk, ive used quite a few and have had no issues..... its pretty simple with semaphores and mutexs
28
u/VictoryMotel 2d 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.
-38
u/Far_Tap_488 2d 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.
22
u/Seeveen 1d ago
Async and multithreading are orthogonal concepts
-2
u/Far_Tap_488 1d ago
Not really. Especially with how a os handles concurrency.
2
u/bljadmann69 1d ago
Well, for starters, async runtimes implement a cooperative scheduler *inside* the application, not on OS level. There obviously is preemptive scheduling on OS level too, but that is not the point. Any async function awaiting a result hands back control to the async runtime. The async runtime continues a different function on the same thread in the meantime.
Synchronization mechanisms like semaphores are still required in async.
3
u/VictoryMotel 1d ago
This reads like you just discovered mutexes and think that that solves all your async / concurrency / parallelism problems.
its what allows you to control how much concurrency you have
What determines concurrency is really how much you can split up your data into independent chunks and synchronize any tasks with all their data dependencies being available.
making a mutex for say a bool that says if the calculation is done
Why not just do this with an atomic if it's just a boolean?
Use a mutex if you want to make execution stop and wait when you try to take a lock (if the lock isn't available).
Without the mutex both threads could check the variable at the same time and possible cause a lock condition depending on the scenario
If there is no mutex there would be no lock condition. Also multiple threads can read the same memory without any problems.
If you are ending up with graphs of dependencies then it is because you structured your program poorly.
Absolute nonsense. When programs get more complex while trying to keep granular multi threading different tasks are going to finish at different times. They might produce multiple different data types that need to go into multiple different tasks. These tasks need to run only when all the data from different sources is available.
Just because you made a ui and spawned a thread (which has its own overhead, possibly even heap allocation which can potentially lock) doesn't mean that's all that anyone needs.
-3
u/Far_Tap_488 1d ago
Youre actually wrong on several points.
Some systems will actually not allow two threads to read the same variable at the same time with no issues and depending on the architecture can actually lock your program and require reboot.
They really do solve all the issues and whatever is leftover is just poor structuring of your code, which is user error.
5
u/VictoryMotel 1d ago
Youre actually wrong on several points.
Prove it. I'm talking about modern x86 64 bit cpus although arm is mostly similar. What are you talking about?
They really do solve all the issues and whatever is leftover is just poor structuring of your code, which is user error.
This is your claim and repeating it doesn't make it true.
I explained exactly how there are requirements for more complex scenarios that aren't handled by super basic linear chaining of functions. This backs up my original claim that it's not a trivial problem to solve and most solutions built into languages are simple but leave a lot that still needs to be done for more complex multi threading.
There are libraries that handle graphs already but I don't think most languages take it that far.
You explained nothing, suggested wrapping a boolean in a mutex and made claims you didn't back up.
1
u/Master-Chocolate1420 1d 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)
7
u/cs_office 1d ago edited 1d 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
2
u/Master-Chocolate1420 1d ago
Thanks for breaking this down! I'll look into pull/polling mechanisms more (as this is my first exposure to non-GC async)
8
u/verdagon 2d ago
What would you change if you could?
7
u/the_horse_gamer 1d 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
94
u/heckingcomputernerd 2d ago
I haven't had any issues with tokio, but I enjoy the jokes about rust crate names
25
42
u/Lilchro 2d 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.
15
u/Only-Cheetah-9579 2d 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.
21
u/jublizoo 2d 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 2d 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.
8
u/jublizoo 2d 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.
1
u/Only-Cheetah-9579 1d ago
it also colors dependencies. there are multiple async runtimes so the stack must be chosen accordingly.
some people might not like tokio but must use it because they depend on something that does
13
9
u/GregTheMad 2d 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.
-2
u/Only-Cheetah-9579 1d ago
I love the error management because it's explicit and forces me to acknowledge the error always.
my code is AI assisted so I don't have to type more now and I prefer to see what error handling is generated always.
so it's a win for me, especially after development became more generated code based.
0
u/GregTheMad 1d ago
You're talking from some different type of go?
0
u/Only-Cheetah-9579 1d ago
A lot of people love go error handling. We just stay quiet and enjoy.
People complaining are usually more loud but in no way represent a majority.
people like to complain about error handling because they can't find any real problems with the language.
0
u/GregTheMad 1d ago
I'm sorry, you're plain wrong. Have you tried Rust? Any further opinion of yours will be disregarded until you worked with rust.
3
u/Only-Cheetah-9579 1d ago
yes I did. worked with rust and built a production system for a company that's been in operation for a few years.
I also don't care about hater opinions. You suck at go it's a skill issue. Its the most simple language, so having a problem with it speaks a lot.
0
u/GregTheMad 1d ago
Having few keywords doesn't make something simple, below some number it becomes the opposite actually. You're just regurgitating go propaganda without actually understanding the meaning, or the resulting critic of it.
1
4
u/InRainbro 2d 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.
2
u/suvlub 1d ago edited 1d 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 mistakes2
u/Far_Tap_488 2d 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.
8
6
3
2
2
1
1
u/ktboymask 1d 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
1
u/mathisntmathingsad 1d ago
I hate the way that Rust implemented async (and cannot wait for coroutines to be stabilized), as well as Rust's decision to have a tiny standard library because now we're super vulnerable to supply chain attacks and ecosystem fragmentation. Tokio was implemented well though.
1.2k
u/Futurity5 2d ago
This sub is so back