Async Rust Is A Bad Language | Prime Reacts

Async Rust Is A Bad? Sir have you seen C++ co routines? Those are atrocious, worse than bad!

The fact that there is this perpetual need to re-explain and argue about concurrency vs parallelism makes me feel really secure about my continuing employment.

The problem with multithreading is that the programmer is the one implementing it. The CPU hardware should be delegating work to it's worker cores. It should opperate internally as a multithreaded system and present the user with an apparent single thread and the user should have the option to bypass the thread overseer but the default behaviour should be to just let the thread overseer handle threading and data race prevention.

Multi-threading should be a hardware level issue, not a software level issue. There is no reason anti-data-race circuits could not be added to memory modules using a XOR-gate access lock at minimum.

Hell, it could even be implemented compiler level, instead of programmer level, you just have the complier mutex lock any variable that can be access from multiple threads: internally handle those as structs containing var and mutext and then overload the access opperators to aquire and release the mutext locks.

.....at the developer level, this is a single template class.........

When I figured out how asynchrony works in Rust, it helped me in understanding asynchrony in other languages. For example, like Python, where I understood asynchrony quite vaguely.

I'd say parallelism is when something runs in parallel on a given processing unit (i.e. your GPU or your CPU) while concurrent means that we are doing things in parallel across different processing units/hardware, i.e. doing work on the CPU while some other component is doing data transfers instead of just waiting for that to finish. When you're calling some function on the CPU that tells the GPU to do something, that will run concurrently. The task you gave to the GPU itself will execute in parallel on the GPU, and the GPU itself can also run things concurrently since it has more than just one streaming multiprocessor and can very well be running different tasks at the same time, but only one dedicated task in parallel on a given SMP.

For people elated about type annotations in the javascript files, they won't happen because they will straight up add parsing time and size to scripts with no runtime benefit whatsoever (and therefore the implementors will be blamed for "slow sites"). It might somewhat work in Python, because it's parse once and use many more times in prod, but not in browser js.
The same reason there won't be pipe operators in JS either, because they incur a performance penalty on almost entire runtime, and implementors will be blamed for it.

Just learn an entire Unix spec to write a fs call in your CRUD, bro.

Can't someone write the equivalent of go in a rust library

What I really want is Rust with all the memory safety, true functional language features, and Hoare concurrency (all communication with green threads occurs via channels with immutable messages). Who is working on this?

To be fair: go's concurrency features enforce "The Right Way(tm)" to do concurrency. Now I want go-style concurrency in all languages and get frustrated that it isn't fully supported.

To be fair: go's concurrency features enforce "The Right Way(tm)" to do concurrency. Now I want go-style concurrency in all languages and get frustrated that it isn't fully supported.

Parallelism may not use two separate CPUs; it may use two different threads, and you may use the same CPU for those threads. Splitting hairs, but, meh.

Soon graalvm will gain popularity and java again will become popular. I noticed that while coding in rust I become tired very quickly. This is not I expect from modern language

Pin is a small pinis that gets added to your code to 🪛 things around for ya. Simple!

Came across this recently and feel like not being able to have shared mutability across async tasks on the same thread really kind of defeats the purpose of async in the first place.

Parallelism is two people each chopping an onion at the same time. Concurrency is one person chopping an onion while they wait for the oil in the frying pan to heat up.

Everyone who hosted a Minecraft server hates GC by default

please review Rob Pikes "Concurrency is not Parallelism" its a very good talk and a critical one for Go devs

Love the humour!

I used to do this on an old IBM S360 reducing my shifts from 9-10 hours to only 4. Two tape units and printer running flat out. And me smashing keys to run the JCL that I'd split up to run the stock control and invoicing code at the same time. Hehe. No parallel tasks of the same code though.

Parsrelism is having multiple arms

Concurrecy is having multiple hands

The “you end up with a s*** GC” comment makes no sense. And they offer no empirical evidence to back that statement.

You can still develop a CSP style async app in Rust. However, I generally find its a better suit for critical software where you do need to care about the minutia.

Let’s be real, languages are really domain specific because they all have subtle trade offs under the hood. Rust is a systems language. If you want to build a massive server application using a ton of async and constantly moving/growing requirements, Rust is probably not the best option. In that scenario, I think Go is king.

Async Rust is particularly great if you have a bounded requirement that is very critical. For instance, I’m an HFT and I’ve found async Rust phenomenal at processing market data. It’s a latency critical section that’s been dominated by C++ or raw assembly for 30-40 years. With both the type system, safety guarantees, and a way to make use of cores beyond traditional threading, it’s a great option. I really like it there.

As for the rest of my system, not everyone in the HFT world comes from a true CS background. They’re quants or researchers or traders who know a good amount of coding but nothing to the extent of systems level programming or distributed systems design. In that area, you get a lot of python and java. The better modern version of that layer is Go, OCaml, stuff that has decent performance with a GC.

You really just need to evaluate both the technical and human problems and pick the language accordingly.

You don't know what NFS is?

parallelism is a subset of concurrency... all parallel tasks are concurrent tasks, but not all concurrent tasks are parallel... concurrency is about solving problems of sharing resources (CPU, memory, files, etc.) between processes/threads/tasks both in parallel or in pseudo-parallelism

rust is really good for data oriented ecs based games

More trivia: Meteor JS has a forked version of Node 14 using a Fibers extension to do "colourless" concurrency instead of await/async. Meteor 3.0 will be going 100% async to get away from that weird fork situation though, so it's sort of the end of a weird parallel universe of JS concurrency (pun not intended).

One thing I learned about Rust is that we can't try to be big brained with it. Often it is better to use the simplest solution possible instead of just trying to specify exactly how everything should work. Better to avoid fancy code as much as possible to avoid the weirdest bugs.

deez parallel units

omg i got pixel 7 too

I've written a service in rust recently, using tokio runtime and messages for communication between threads. It was sending about 40-60k messages per second and channels quickly became the bottleneck. If your main thread is owning the storage (like hashmap with a complex structs with strings) and you need to send messages on precise timers, cloning the objects to send via channel is not an option - your messages will be delivered waaay later in quite unpredictable manner. The only option here is to send Arc of storage (with Mutex or RwLock) and key to receive data in the task.

I wonder if it is possible to somehow introduce things to rust that "fix" async to be more approachable.

btw default rust async is dogwater, i thought everyone knew that already?? might as well just use java or csharp if using 4+ rust threads. i mean, same can be said for some cpp implementations too. however, that doesn't preclude writing fast rust implementation . noobs

parallel is the same task running in multiple threads, concurrent is different tasks running at the same time maybe in different threads.

😂

I really like the syntax of rust,just the lifetime complexity make it hard to use it,if rust would have a builtin semi automated garbage collector in std library,I won't gonna use other language anytime soon.

NFS is the network file system. We use it at home to have all computers' home directory on a central computer

Never had to use Pin<T>. What the h*ll were you developing? An async linked list?

Pixel 7 eh? The volume rocker is soon to fall out.

Number 5. Each thread having a 4kb control block... Is this related to why when piping data between processes the buffer size is 4096 bytes?

Parallel is when two chefs prepare two meals in the kitchen. Concurrent is when the same waiter two customers those two meals.

Bruh AsyncAgent

NFS was great (other than the stale mounts of course)!!

Parallelism IS a subset of concurrency. Asynchronousity also is a subset of concurrency. What you are referring to as “concurrency” throughout the video is actually specifically asynchronous code. Parallel code is also concurrent.

I don’t get these about GC, low level control nerds, maybe because this is the internet where low level nerds bash any language that have GC, honestly when it comes to stackful concurrency esp MN threading it’s an absolute nightmare without a “fat runtime”

every week we get this same shitty article