Comments by "" (@diadetediotedio6918) on "Async Rust Is The Bane Of My Existence | Prime Reacts" video.

Oh, regarding sync/async code variations, I think a look on the "generic keywords innitiative" post on Rust-lang blog would be a good read, it is a pretty interesting and I would say novel idea of bringing compiler-generated variations for sync/async code (and other types of discriminative keywords as well).
15
@pureconex Why "no"? It literally solves the problem
3
Go has not such a big perf impact, but the runtime does come with a cost. But Rust is trying to solve this, I recommend to look into 'keyword generics initiative'
2
I don't think they "sidestep" the problem, they rely on a runtime and/or different constructs to do the biddings
2
Surely @youtubeenjoyer1743 would know better that threads are the final solution than all language developers that are actively developing async/await and alternative solutions to threads. Maybe you should talk to Project Loom and say to them that fibers are overrated anyway so they should just use threads.
2
It does not deal tho, because you still need suspend in functions and it still propagates.
2
["There is no reason to ever consider writing blocking code when you have async out of the box"] Literally, I can ensure you there is. Async code has perf implications, heavy ones if you're writting code that do not need so much concurrency, that's why most of the games don't use async/await in their loops for example. It definitively <has a serious cost>. And for a native async runtime for std, it would not matter, the problem is function coloring and not the runtime.
2
I don't think it is a "safe C++", Rust is an easy language if you take it easy.
1
Nah, the reason is that the product is already done, so it is easier to port, that's why virtually all languages have thousands of ports.
1
What "same function names" bro, this does not even apply here.
1
@xeamek99 Bro, you understand that the question is not about arguments, but function unmatchable signature, right? What I'm saying here is that this does not make sense, there is no "null" to pass on, in any language at all. C# <has> function overloading and still have the same problem literally because the compiler cannot magically infer these things, when a compiler with function overloading matches a function it matches based on arguments, the actual function modifiers would still be a problem.
1
I started tp think lately that there is no "uncolored function" at all in any language, you will be compromising yourself either with a runtime or with some distinction between the "worlds", it is this way for Rust, Go, C#, Kotlin, all languages.
1
@dealloc And my question is: What is the solution to this problem them? It just sounds to me like a compromise between performance / low-level control / syntax coloring And I think you cannot achieve all of these at the same time reasonably, because all solutions will end up clashing at some point. Even if you use raw threads you will still be needing to handle synchronization primitives manually and this will blow up in the code as you need to access values that are locked behind them. So, I think this is more of a "no free lunch" problem that the big monster people usually say about colored functions.
1
@vasiliigulevich9202 Except that threads are not cheap and golang went for a seamless coroutine-based way of handling it's concurrency
1
@vasiliigulevich9202 Fibers are modeled to behave <like threads>, but they do not work in the same way. Threads are usually tied to the operating system and operating on them involves many costs (for creation, synchronization, destruction) and cares (like keeping them the most 1:1 with processor threads as possible for the most performance possible). While fibers and other similar constructs are a language/runtime thing, they don't exist outside the environment they are running in and just simulate the behavior of threads while still being lightweight. And of course, there is a catch on this: usually constructs like these are not as performant as raw 1:1 threads because of context switching and runtime verifications/allocations to support them, but when you need a bunch of concurrent activities you have a marginal gain in performance in relation with system threads because they have diminishing returns in relation to processor threads (while virtual threads and async/await, even with their runtime costs, are capable of simulating inner program work stealing and keeping the processor at it's best use all times while it can also lock other virtual threads).
1
@marcs9451 Async/await is not an inherently bad idea as well, there are many languages that don't suffer so much from function coloring like C#, and Rust is developing a solution for this with their 'keyword generics initiative', so it is not a dead-end problem without plausible solutions.
1
@vasiliigulevich9202 now I'm sad... my coments where deleted... I literally wrote a whole text explaining this but anyway, I will "resume", fibers are a virtual construct, and normal threads are tied to the OS, they are expensive while fibers just simulate native threads.
1
@aftalavera Sure, @aftalavera. After all you are the guy everyone should rely on, because you're such a big reference in the programming industry.
1
@vasiliigulevich9202 ["it’s not really about OS threads specifically"] Sure, it is "obvious" that he was not talking about native threads or anything. After all, Rust and most of the languages do have virtual threads.
1
@jongeduard Literally. People tend to stick with one programming language like it was their unique options, they don't understand that the more languages you now the better your brain will be at being language-agnostic (much like real speaking languages).
1
This is an interesting take, but also very bizarre as async-code comes with a cost and most of the code we write is actually sync.
1