I totally agree 👍

💯

Your take on async and threads is completely wrong just saying. JavaScript has a asynchronous non-blocking I/O thread, a single thread that does not block execution. It’s more easy to explain in a metaphor. If Node was a server at a restaurant it would take that order. Give it to the chef come back out and take another order aka HTTP request. On the other hand PHP would grab the order. Wait for the Cook to complete that order before they ever took another order from another customer. Basic synchronous operations verse asynchronous operations. Research the JS event loop. What do you think callback hell is? Why did ES6 give us the Promise API? Just a fun fact synchronous languages don’t have a call stack. ✌️

​@@Vorenus875 both explanations are understandable and I think 100% correct 😅

@@thedelanyo Sorry you’re right I read it again. I just caught caught more with “threads” in the video. Maybe someone can explain to me how this is a “game changer” in 2023 being that the JS event loop has always been this way.

data race. data race!!

Sure helps that you have to explicitly state what bit of data should cause you headaches, at least it helps me think more clearly about it.

sounds like a good way to go to hell to me

You talk like you can only code by example.

This isn't like the multithreaded nightmare that is Java. You explicitly need to define a chunk of memory or data to be shared and be mutable, it's not "anything goes".

And this is concurrency or parallelism? sorry I'm confused.

@@danielvega646 here's a easy way to understand. concurrent: cpu will spend x time on a task, but once the timer is up it goes to another; parallelism: cpu will process all the tasks at the same time. in this case, worker_threads execute parallel instead of concurrent. this is a big simplification so if you want to know more how concurrency and parallelism work you should look it up and also try to understand how the OS schedule these tasks to multiple cores at the same time.

People get confused by this because they use the phrase "at the same time." You used that phrase to describe both concepts. I feel like the industry chose poorly with the term concurrency, since the meaning of the English word is "at the same time," and more accurately describes parallelism. I'd have offered something like interspersed, interleaved, multitasking, or something like that. If computing concurrency is occuring, then the different tasks are very much not being performed "at the same time." I had been using the computing terms essentially interchangeably because of this misunderstanding, luckily without ever being in a context where it mattered.

@@donkeyy8331 concurrent looks like ____-----____---____---___ parallel looks like =========== ? Is that's right?

​@@bryanlee5522yup! That's exactly it

Well, not quite. In Node, both IO operations and long-running code can be bottlenecks. Yes, if you don't have long-running code, then your application will run fine. But as soon as you have long-running code, that'll bottleneck you way faster than in other languagues because it's that much harder to execute that code in another thread. In that sense, long-running code is the Node.js-specific bottleneck and is what should be avoided if you want to have low latency.

NodeJS is single-threaded (CPU handles tasks sequentially), but the I/O is asynchronous. So, the I/O devices - like networks, storage, and other connected devices, do not have to hold on to the CPU. Other languages are multi-threaded, but their I/O were mostly synchronous. This is why you get HTTP timeouts with Java and Python, but you never get it with Node.

@@josephmariealba8483 both Java and Python has asynchronous. HTTP timeouts are caused by many reasons (and Node application can return HTTP timeout too), sometimes its due to bad code implement, sometime it's security mechanism (to avoid some kind of attacking method - which try to hold connection as long as possible).

@@DavidsKanal > that'll bottleneck you way faster than in other languagues because it's that much harder to execute that code in another thread How easy it is in other langs?

​@@hl7297 for c#, more or less: new Thread(fib).Start() new Thread(fib).Start(singleParamPassedAsObject) new Thread(() => fib(param1, param2, param3)).Start() to create a completely new thread or Task.Run(fib) Task.Run(async () => { fib(param1, param2, param3); }) to run your code on one of pooled threads (generally better idea, unless the code is long running or does synchronous io) you also have PLINQ where you can for example do ' var x = someArray.AsParallel().Select(i => i*2 + 2).ToArray();' which will distribute the calculations over all cores and merge the result automagically. Note that while it's easy to start code on new thread, it's not that easy to make sure the code runs correctly in parallel (think locks, deadlocks, race conditions, compiler and cpu optimizitations causing writes to var on thread 2 not visible to thread , multiple threads accessing same var under coarse-grained lock effectively making your multithreading slower than single thread and many many more)

just a reminder for everyone that js _is_ single threaded

@@josedallasta yes the language itself is single threaded, But the runtime can run multiple instances of it and share some memory Between them.

@@josedallasta JS used to be single threaded. However modern JS has features like SharedArrayBuffers and Atomics, which are definitely multitreading features.

"She laughed at me" - trust me, you don't want to work for those people.

@@blizzy78 Happily I learned the game pretty early on!

Shouldnt buffer sharing like in the example solves this issue?

​@@EuSouAnonimoCara Yes and no :D. Anyway you can only serialized data into shared buffer, so performance issue about serialization doesn't went away. It can be managed in early stage of developing module, but sadly you can't just wrap smth into web-worker to make it faster. My point was about it :D

You can use transfer lists to move memory to the other thread downside is you can’t use it in the thread that sent it but you can have the worker thread re transfer the same buffer back after doing whatever it needed to do. Nice thing is you can still use postMessage but can avoid the overhead of deep cloning

​@@sawinjerwhere do you learn all this stuff? I'm taking a node js course and I'm not sure if I'd be able to keep up with the people in the comments when discussing this stuff. I think I've heard a few speakers talk about this, but that was a long time ago and I can't remember who or what they said. (Kyle Simpson maybe)? Did you study CS?

@@thelegendofzelda187 I have CS major, but this knowledges I gained in a MDN articles. Also in particular this topic I had commercial experience

Caddy is nice! But nginx and apache are pretty good too though. If you're not familiar with any of them and you don't care about battle testedness then caddy for sure

I wish to make a nextjs app too but after watching this video and comments, I think I have not fully understood nodejs yet... I also want to use nodejs but ofcourse, I don't want frozen app with just a few users! Any tips on learning and understanding it in the real world sense?

​@@shantanukulkarni8883 start making this nextjs app and learn what you need on the go

Can you explain redis queue and separate service in detail?

@@ritik-patel05 nextjs api backend puts json stringified data on redis queue. Node script conitinuously looks for new value in queue.. When it gets a value from it, the value is parsed and gets sent to the GPU server. After, the GPU server is done fulfilling the request the node script gets the data and this data is again stringified and put in Redis . While this was happening, the client polls the nextjs app every few seconds to see the status of the job in queue. After processing of the job, nextjs app gets the output from Redis and sends it back to the client.

Nodejs is outdated BE framework. Why would anybody except for some "fullstack" devs use it nowadays? Libraries are absolute mess with tons of vulnerabilities and close to zero support, let alone half of them dies over 1-2 years. Why would you use it over python, c#, kotlin, go, java and etc... Those languages have frameworks that are way more mature with way more reliable libraries and way less security concerns. People claim that starting with nodejs is simple, while it is not true. It is infinitely easier to build a dotnet7 api for a newcomer. All the tooling works out of the box, no mess, actual code standards, no clickbait content, no confusion with libraries(what orm should I use? MikroORM, Objection, TypeORM, sequelize etc...). You just download SDK and IDE. No need to download nvm. No need to fight over npm, pnpm, yarn. No need for nvm either. Node is just a mess. Absolute nightmare to work with 3+ people on the same project. It is also absolute nightmare if you need to maintain the project for 5+ years. If I learned anything in the past decade, staying away from node is the best thing...

I think the shared memory is new for node

Agreed

Thx man I never knew about this

I'm curious, what would you use them for on the front end? Is it some kind of cpu intensive task that runs on the client?

@@matth23e2 Yeah pretty much. I run a reasonably cpu intensive search algorithm in a worker, and it just returns the array of references. Keeps the main thread unblocked. If you give workers some thought you can use them for a lot of things though.

@Name I myself haven't used go that much yet, but what's wrong with it?

​@Name are you serious? Go a bad language? Compared to.... JavaScript? Bro, you are killing me stop.

@Name I think you don't know basic English. The other guy was talking about go being better than JavaScript and you said that go is a bad language, meaning in context that is no better than JavaScript, V doesn't have absolutely anything to do with this. Plus you look like a complete moron if you go around shoving your favourite language down everyones throats when its not asked for.

​@Name try v?

@@twothreeoneoneseventwoonefour5 it all good until that GC cycle kick in and grab your ball and you have nothing to do to even reduce it a bit. Go is as good as simple but when you start adding more memory related to it, then GC will happily blow all your work. i/e: personally i prefer Jai more, but since god know when it got release, Zig is fine

I think you're right: "Concurrency is the task of running and managing the multiple computations at the same time. While parallelism is the task of running multiple computations simultaneously."

thats true but it looks like the total running time was 1/5th of the time

Context switching ! If you spawn more threads than the available number, they're going to take much longer, That's way you should create a thread pool first and assign tasks to it.

Initialization of threads also adds up. This is a bad way to benchmark.

These whole techniques seem like going back to regular multi threaded programing languages

@@anothermouth7077 No one is going back to anything, worker threads are even present in thr rust + actix for example. You need to understand what you are trying to do, in this case if you have a long lock it's interesting to invest into a worker thread.

저도 그렇게 알고 있습니다만, 그 멀티 스레드 활용이 제한적이라는 게 여기서의 논쟁거리인 것 같습니다. Ryan 의 피보나치 테스트에서 수치가 나왔으니까요... 만약, Ryan 의 코드에서 피보나치 연산을 외부의 C 스크립트로 처리했고, Node 는 그 연산결과를 받아오는 방식이었다면, Node 의 멀티스레딩을 신뢰하는 사람들의 기대에 부합하는 결과가 나왔을 수도 있겠죠. 적어도, C/Python 으로 처리해야 할 작업과, Node 가 직접 연산해야하는 작업의 판단은 있어야 하고, worker 로 스레드를 분산해 준다면, 그에 따르는 위험도 관리할 수 있어야 한다는 정도로 저는 정리해봅니다.

go is ❤

if err != nil if err != nil if err != nil if err != nil if err != nil if err != nil if err != nil if err != nil if err != nil if err != nil

yeah, let alone js on the browser

so in short if it comes utilising all cores it's parallelism, when it's just concurrency it's just once core which quickly swaps context executions.

@boohba yes, clone is the underlying syscall that it's all built upon. I figured keeping it in the fork/join terminology would be simpler in this case, as fork/join parallelism technically is the ancestor of multi threading. So forking, creating threads, its all built using the clone system call with different parameters.

Async and promises do the same thing. They are just syntactically different. The video is highlighting that you need multiple cores in order to execute things in parallel. You are not able to execute things in parallel in JS because it only has access to one CPU which can only handle one process at a time. JS Async is not handling tasks at the same time, it is scheduling tasks to be handled at a later time. This is concurrency. This video is about parallelism not concurrency.

if you've ever used assembly language before, Its like putting a jump statement at the end of a block of code to go to a previous (or future)spot in the code, the asynchronous portion of the code, then have another jump statement to jump to the next part of the code the dev wishes to execute when the asynchronous code finishes.

@@terrencemoore8739 If you read my comment you should see that I said that async/await is not multi core execution and my main point was that his example used promises in a way that didn't really make sense, he could have just put the calls to the functions as direct calls as he wasn't really making use of promises in a meaningful way. If the code is going to use promises it should demonstrate how they can execute code asynchronously.

I've never tried writing asynchronous Assembly language code though, so this part may be a bit inaccurate

@@John.Whitson The video is not about asynchronous code, its about parallelism. He acknowledges that JS is async but if you want to do two things at the same time, its impossible. CPUs handle one process at a time. If you want two things to run at once , you need two CPUs

You can split sync func into asynchronously executed pieces, but it's not always possible, and requires completely different approach. Meaning that functions like fibonacci cannot be executed neither asynchronously nor in parallel, as every next step requires data from previous one (adding previous numbers). However you can Promise.resolve(returns of fibonacci), so the fibonacci function itself won't execute faster, but now event loop is able to execute some of the tasks in-between recursive fibonacci calls. In this case you'll have to await every return from fib fn, but now it won't be as blocking, but in reality it won't make any difference, and most certainly would still block the event loop on high numbers. Essentially you can't make anything faster with async in javascript, with exception of I/O tasks, which are actually handled by separate thread/threads, so that event loop while it's waiting for I/O to respond - is able to perform something in-between.

For using other cpus/cores you still need to use cluster module, This feature only lets you spawn threads in the current process, if thats fits your requirement, yeah you should definitely try Worker threads .but if you ask me, you should use the combination of both. Simply put, you can assign cpu intensive sync tasks to workers , let node handle async tasks and do multiple forks of this combination to handle incoming traffic