I think the main issue Rust has in this space is that you're not really all that likely to stumble on an actor model as a solution. You're far more likely to try to run two functions at once and find out the borrow checker is upset but it gets less upset if you Arc (it likely even recommends this). The path you're pushed on is the hard path, and it's partly because of the types of projects that are using Rust in the large.

I'm not entirely sure what that abstraction is trying to say without context. Sound cool though

@@KyleSmithNH yeah, my take (and this might be what you're saying) is more that Mutex is more in line with Rust's raison d'etre. It exists to get as close to the bare metal as possible (as rust often does), so it kind of betrays that to enforce anything that adds overhead, even if its typically a bad idea to go without. Like, Lamborghini might strongly suggest you obey the speed limit, but they're certainly going to make it possible to speed feloniously. Probably. I don't write php.

Thanks, I thought the same! The article states Hoare and the solution to all the problems: channels! But then sh*ts about how async rust sucks using anything other than channels...

@@Psy45Kai The point is that Rust doesn't lead you down the path of using them naturally, therefore many make the mistake of not doing so. Whereas other languages make it much easier

That's the best explanation of parallel vs concurrent I have ever read. I'm stealing this.

Concurrency is simply what people call multi-tasking. Very few people actually do multiple things simultaneously for any consequential amount of time. They just rapidly (for a human) task switch.

​@@jacekkurlit8403No, I am stealing this explanation

Great way of simplifying a concept that people often struggle with for a while!

To the best of my understanding: Parallelism is a subset of concurrency. Concurrency just means running at the same time which includes parallelism. Parallelism implies concurrency, but concurrency doesn't necessitate paralelism. Concurrency is both one chef or many chefs. Single threaded concurrency is explicitly a single chef.

I feel seen 😂

concurrency is what everyone really does when they pretend to be "multitasking", except their brains have a very small amount of memory to store those tasks in the queue and a very slow single-core task runner whose limited attention is split among the tasks evenly

Without joining

Oh interesting that it's different.

Clearly dotnet wins the language competition

f# is so underrated

You'll have to relate the gains.

Python async is absolutely useless even if you use uvloop. Just using a huge threadpool always beats asyncio solutions in throughput AND latency.

@@youtubeenjoyer1743 if i'm not mistaken, python 3.12~13 will improve this.

@@mythbuster6126 I was talking more as getting a new perspective to the problem, surely I'll check Rob out. This was a very new take to me, thought it was very intriguing. I am still learning the craft, thank you for pointing in the right direction.

​@@mythbuster6126 actually, it makes sense. Pls, correct me if I am wrong. Two threads running concurrently on the same CPU core do not actually run at the same time or in Parallel. The OS scheduler decides which one in the ready state runs. Say it begins with thread A and for some reasons A is interrupted (timer interrupt) the CPU then becomes free and the OS scheduler begins executing thread B. B either runs till it finishes or itself is interrupted (another timer interrupt) and the OS continues to execute thread A till A finishes and it continues with B till it finishes. That's how concurrency works. Say these two threads were working on the same file(with critical sections) it would be easy to get into a race condition here. Hence the need for locks, condition variables, and/or semaphores.

I've been coding for 10 years and watching Prime's videos has made me rethink a lot

@@paulorubebe7308 ackchuwally, in CPUs with simultaneous multithreading (SMT, or hyperthreading, HT, if you're Intel) several threads running concurrently on the same CPU core do actually run at the same time or in parallel. Executing an instruction takes several "stages" and multiple stages can run simultaneously. They can process the instructions from the same thread, which CPU expects will follow one after another, or instructions from several threads could be interleaved: while finishing an instruction from thread A it could be starting an instruction from thread B and preparing the next instruction from thread A. On the next tick it would be finishing B, starting A and preparing B etc (here I imagined a hypothetical core with three stages - prepare, start and finish, in actual CPUs there can be more stages, so even more instructions from 1 or more threads may be processed simultaneously).

He's mentioned before that he uses Rust at his job in Netflix, so maybe he can't exactly show them to us lol

If there wasn’t a function coloring problem, we would be using the std library when doing async work yet thats not the case.

last sentence is absolutely on point, and why Rust is truly special

@@metaltyphoon I think I didn't manage to get my point across properly (that's on me); of course function coloring still exists, what I meant is that it's not a *problem* with Tokio. For example, Tokio's channels e.g. can send and receive messages in a blocking context, too. Let's say you have a worker thread (plain old std::thread::Thread somewhere) that's doing synchronous stuff. You can give that thread the receiver of a tokio::channel, and it will be able to call blocking_recv(), or vice versa, blocking_send() on a sender. You *can* therefore "go back and forth" between sync and async contexts. One just needs to learn how to do so. That's why I personally don't consider function coloring a problem. Now, my points are heavily relying on Tokio here; if I had to build my own runtime, I would have to build all of those facilities myself, which I admit would be a PITA. But that's why we have Tokio.

"the learning curve is steep if you really want to get to the spicy parts" But you honestly don't have to learn *that* much, for async to be very usable. I feel like people sometimes treat it as if they had to write their own runtime from scratch. Most of the time it's writing tokio::spawn instead of std::thread::spawn and using the async version of calls that would usually be blocking. And for some things it's even easier. Graceful shutdown (of the whole application, or parts of it) is a breeze with the tools tokio provides. And things like tokio-console are a godsent for taking a peek into a running program. "Async Rust doesn't hide anything from me, and that's exactly what I need." Eh, I personally think there is a bit too much magic involved. As with anything: If you understand the magic, it ceases to be magic. And to Rusts credit, at least it makes understanding said magic possible. But I do think there was room to be more transparent with the whole thing. I'd like to roll my own generators for instance, instead of having them perpetually locked away in nightly.

I feel the stuff about Arc is really exagerrated. I mean I've used it for init/config stuff but not like, talking to database, moving stuff over the network at runtime... I think if their program is spending a lot of time ref counting in Arcs it could be rewritten

sounds like you'd like go lol

@@himboslice_Definitely.

@@himboslice_ i love Rust and Go for very different reasons but they're both easily amongst the best programming languages in the world

That's a recipe for a slow code. With that approach it's better to just write Go instead and get faster performance.

@@vadzimdambrouski5211 I didn't explain my point very well. I apologize. What I think it is best to say is "Better to not try reinventing the wheel when coding in Rust every time. There is most likely a crate that does what you need. Whatever it is."

That's certainly a correct definition of parallelism, but I would constrain it to "executing more than one stream of instructions at a time". A CPU can definitely do fancy out-of-order and super-scaler stuff, but that only works as long as it ends up being sequential at the other end again. Of course a superscalar architecture, pipelining, etc. is a large part of what enables this (SMT), but I find that executing multiple streams of instructions simultaneously is usually what people mean when they talk about parallelism!

wat

They don't work in private browsing mode, so you have to write a conditional init logic (async ofc) for any function which can potentially interact with workers so it could work without them (potentially even after initialising with them). And don't forget interaction with workers incurs serialization/deserialization overhead, so you also want to write some sort of streaming logic on top. Which means you are going to write statically unoptimizable spaghetti and typescript makes it very painful to write cross-environment code like this. Good luck debugging all of that.

that happens to me a lot in rust, it's friendly enough that you don't really HAVE to think about some things that the language is doing, but if you do, you start understanding why it's doing it

I would rather say a kitchen. When you are making breakfast you can make a coffee while your wife makes a toast. Two people for two tasks. That's parallelism. The problem is that kitchen is small and you can't have many wives. Another problem is that when making a coffee the part of it is boil the water. While water is boiling you just sit and wait. The same goes for toast - while it's being heated your wife waits and does nothing useful. Here when concurrency comes to the rescue. You dont need a wife to make both coffee and toast concurrently - just load the toast, while heating boil the water, when toast is ready put a batter on it, then water is boiled so you switch there and finish coffee. Boom! TLDR; no wife no problem

People on a kitchen are CPU cores (processing unit), making a coffee (1) and making a toast (2) are tasks or jobs, loading toast/finishing coffee is computation, waiting for toast to heat/water to boil is waiting for IO, the toaster/kettle are OS/network.

@@viktorshinkevich3169this is the only explanation that actually made sense to me 👍🏼

its mentioned by all possible names in the article

serde and clap, all about the beautiful #[derive] macros

Go abstracts the difference - goroutines are both concurrency and parallelism. You can have 16 CPU cores, spawn 16 computing goroutines and benefit. You can also have 1 CPU core, spawn 16 IO bounded goroutines and benefit. Because GO hides away the difference.

@@viktorshinkevich3169 Thanks for the explanation. But how does it know when to do concurrency for io bound stuff and when to do parallelism for cpu bound stuff? And is there a way to set it manually?

@@crimsonbit You are welcome! So again that's the cool part about go - you dont nesseceraly need to know. You are computing 4 different unrelated values that take time on 4CPU core computer spawning 4 goroutines? Fine, go scheduler will try and map those 4 goroutines on 4 Threads on 4 Cores. And speeding up computation 4x times You are requesting 4 different websites with 4 URLs on 1 CPU core toaster? Fine, go scheduler run them concurrently on 1 Thread, switching from one goroutine to another while waiting for network call response speeding you program to the time of slowest HTTP call. Go does so because he can difference IO bound from non IO bound (+timers). If you spawn goroutine that just calculates something Go will know it should not be "async". If you spawn another goroutine then does Timer (sleep) or that makes an HTTP call or reading from a file - that goroutine know is "async" since Go scheduler knows that it could be easily put on "waiting" list since there is nothing useful it can do in the meantime - it just awaits for response. If it just waits for HTTP call to come back and forth across ocean thru 15.000Km for a sec or two - it's totally legit. For the programmer in Go, there is no special syntax to know it he writes async function or a regular one. In Rust, NodeJS, Java, C# there is.

Yes but the abstraction is significantly less powerful (and less dangerous) than a raw mutex. The programmer never needs to worry about shared memory, all of the messages sent and received are owned by one thread until they are moved/sent.

Yes, on the same line, control structures(loops, if statements and function calls) are also just glorified gotos and branches(and stacking)... they provide a structured interface which helps prevent foot guns. The deadlock condition on a correctly implemented queue is when there's mutual waiting because there are threads which want to consume while there is noone to produce(and the queue is empty).

@@bonsairobo Yes, I'm just saying, writing an ad-hoc channel is fairly trivial, particularly in languages like C++. And doing it is trivial, since you'll use a queue and a mutex that wraps the pushing and popping of values off of it. Reading off of a channel, is a blocking operation and as such, looks and behaves exactly like a raw mutex. And when writing your own solution, you can add a try_read that checks for content before reading, and just like that, you have implemented the mpsc channel in Rust.

@@matheusjahnke8643 That wasn't my point, or what I was implying though. What I was implying is that, writing your own ad-hoc channel abstraction is pretty trivial in languages like C++. Is it going to be *as general* as a channel from the standard library? Well, that depends on how good you are at writing templated generic code, but even with simple OOP-techniques it is extremely trivial.

@@simonfarre4907 What is your point? Because I read it as: "this thing is so simple ppl should just do it themselfes". Hopefuly it is clear why this is a weird statement to make, especialy in software.

Other reply said concurrent is 1 chef making 2 meals... Problem is both scenarios need additional constraints to be always true. E. G., 1 Chef can bake 2 simple dishes in parallel, 1 waiter can serve 2 side by side customers in parallel (this would be super unusual). After careful thought, I think the waiter analogy wins because serving 2 customers simultaneously is not typical.

It will survive, LOL.

It has the same problem as synchronous recursion (actually it's worse). If it's unbounded, you'll either get a stack overflow, or out of memory, depending if the recursive call is synchronous or asynchronous. Even if it's not unbounded, you could also get a stack overflow when the deepest task completes and starts to unwind the async call stack (.Net has special handling for such a situation, but it's an extremely rare case).

really? 😮

Just like monads

backend as in something that does HTTP + DB calls?

Why are you comparing to TS? That's garbage.

@@dn5426 No he meant a middleware which passes the values to a real backend. I'd also add FS on top, because it can get pretty spicy with all the multi-platform stuff, so I don't believe you can write a "maintainable" code in this context, especially if you need some custom storage implementation logic (multi-platform ofc).

Where can I find it?

Its not hell in golang, its not hell in elixir, why should it be hell here?

Async and all that color the function, and that coloring spreads to its caller. With channels, you don’t know if a function you call is shelling out to something else, and don’t have to refactor everything to use it

@@AnthonyBullard but if the called function is inherently asynchronous, how does the caller can not now this? So if the caller just cares about the value it will act as await, but if the caller needs async interaction it will invoke it differently and subscribe to its channel?

That's a specific implementation of an async runtime. The async language is more abstract, and it can run concurrent futures on a single thread.

Yes but how are you gonna use Tokio, except as a thread pool handler, give me an example where Tokio + rust is a good idea and you‘re not just using Tokio for a) internet or b) multithreading

Mommy Shark, doo-doo, doo-doo, doo-doo, doo-doo

Nice

Val uses a simpler borrow checking model, not a more advanced one.

@@steffahnbut the pipeline might be easier, since quering a computation in Val could be naturally async?

I don't know much about val to be honest, but from the few things I've seen about it in presentations on UKposts, it seems like they deliberately want to be simpler than Rust's borrow checker. I'm merely commenting on your statement that Rust's borrow checking model may not be "advanced enough" followed up by quoting val. Regarding the problem of scoped tasks in async Rust, as far as I know, the main blocker that prevents that has nothing to do with borrow checking anyways. The problem instead is that the relation scoped threads can enforce, that the spawning thread must wait for the spawned thread to finish (before it can drop any values the spawned thread can access), is impossible to enforce for Futures because nothing prevents someone from partially executing a future that spawns a task and then cancel it. As far as I remember, this may in particular relate to that Rust considers it safe to leak values, so you can cancel a future in a way that leaves no way for a scoped task API to notice it.

because Rust is designed to provide zero cost abstractions, Go is not, and what you said is as advantage as it is a disadvantage

You can in Go. I suggest you learn the language before commenting on it.

Asking the right questions

Is GrapheneOS still a good option for Pixels? Heard that the dev (?) has some... mental issues

@@privy15 he does, but a) paranoia probably isn't bad for a secure OS, b) he stepped down

@@mks-h He stepped down? Thats new. Thx

@@privy15 it's better than the stock Android full of Google. I don't think the devs even can do targeted attacks. But you can run Google things sandboxed (and even in a separate profile) for bank apps ect. Either way it is a good idea to use some FOSS Android without Google reading all of your messages and activity

@@TheGameMakeGuy yeah, I mean third-party reimplementations of std in general.

Certain parts of the async libraries that overlap with std are still experimental, but many things will eventually become standard.