So apparently people started using nodejs for servers because of the event loop thingy

So apparently people started using nodejs for servers because of the event loop thingy.
But why not just implement an event loop in a better language like C++?

Other urls found in this thread:

nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/
libevent.org/
twitter.com/AnonBabble

because javascript is a dynamic language that lets you write sphagetti really fast

when i'm doing business logic i don't want to bother with memory management, i want to get this shit done as fast give me my paycheck already

>because of the event loop
Wrong. In fact that is its biggest weakness, the one that makes this technology useless for any normal project.

Node became a thing because it allows web devs to write backend things fast without having to learn a proper language, which otherwise will fry their single neuron.

Node itself is written in C++, the Javascript interface is just a wrapper over the actual code that runs on a server. Javascript does not have any standard library, there are no functions that would allow you to write a framework that runs on a server in Javascript itself.

>makes this technology useless for any normal project.

>I'm too much of a brainlet to grasp callbacks so it's useless.

Whats the most complicated stack you ever worked on?

>single neuron

nigga, javascript is an F-35 compared to the c++ tricycle.

but if you need type safe training whels I can understand how it's hard to even comprehend the concept of higher level programming

at least I can fizzbuzz so stfu plz.

Its not about the callbacks. Its about the poor performance. Every processor today has multiple hardware threads, even more in the server market, restricting yourself to one fucking job queue is retarded, and not an option for most projects.
Inb4 multiprocess, nobody sets up node this way, and thats even more difficult than threads.
Inb4 microservices and docker containers. It is still a waste of cores.

V8's event loop is implemented in C.

But I know what you mean.
I think you can use libuv (C) or Boost ASIO (C++) if you want to do asynchronous IO in a fast language.

>type safe training whels
>Procceeds to use typescript so as not to commit sudoku over casting errors

Java vertx.io using similar event loop and begins multi thread.

Probably embedded stuff. Mobile comes in a second place.

For webservers, It makes little sense to use more than one thread.
The thing web servers traditionally (PHP, for example) did most was wait for I/O. While a PHP application waits for an API response or an SQL query result, the entire process just halts like a fucking fucktard instead of just doing other work it can do without the result.

An event loop fixes that problem, although it does make the application more complex.

>not being multi-core makes it "useless" for normal projects.

Guess 90%+ of all software is "useless"

Never worked directly on the queue, just a side look on node, it's effectively tied to a hardware thread or it's just an abstract thread over the os?
All server parser like php or aspnet run a thread independent for each request, but it's an abstract thread over a a managed system.

>threads

you do know that javascript (or at least, the V8 implementation) is single-threaded, right?

>bringing up C++

Alright. Let me load my cannon

Not him but whatever it is it's just a single thread.
So if you use node to host a web page each request gets handled one by one.

Although you can easily run multiple instances.
So you'd have for example 10 threads instead of one.

The Node programmer generally needs to take care not to block the thread for too long.
For example by using synchronous IO operations.

I know they suck balls.

But doesn't Node have webworkers by now?

>90% of all software is useless
Exactly. If only the web finally ceased to exist. It is the most bloated, dirty, complex and insecure technology out there. It is like the teletext, it refuses to die, but it clearly should.

So why is there this thing called load testing? And why do servers have a ridiculous number of cores?
Oh, sorry, I forgot you web devs don't care about performance at all since it doesn't exist in the domain of the web.

>nigga, javascript is an F-35 compared to the c++ tricycle.
What the fuck am I reading. C++ is literally hated by millions because it's too bloated, and has too many features.

Maybe your comparison could be apt for C, at best. Even so, I would question its validity. If you want metaprogramming done right, use Lisp.

That is a browser thing, and they are really restricted (no DOM manipulation, no access to websql, etc)

God I hate fucking Node.

I remember now thanks. Last time I saw this was on 2016, it's the same now?
Also if you configure multiple threads it just have one queue for all threads?

From what I'm seeing, the logical conclusion is, whanever the worker need to wait file io or any other return like database it should let the request as blocked (like a process) and move to next, and then collect an interruption or event for io completed. You are saying it keeps the worker locked waiting for response?

>Also if you configure multiple threads it just have one queue for all threads?

I use PM2

Which has a single thread of its own, but it dispatches all requests to the processes it manages which all run in their own thread.

So in this picture there would be 5 active threads plus the pm2 thread itself and one stopped thread.

>its the same now?
Yes

>Configure multiple threads
Not possible.

>It keeps the worker locked?
Only for blocking calls, which you shouldn't abuse because they block the entire server. Most IO is async though.

btw: note the memory use: each API instance requires around 15.45MB even though it probably contains pretty much the same data.

This is the biggest drawback I think.
Would be awesome if it could use shared memory somehow so you could launch dozens of threads with little penalty.

>lisp
>1958

nigga u for real

>Would be awesome if it could use shared memory somehow so you could launch dozens of threads with little penalty.
But then again that would be proper backend. Webdevs would jump out of the window if forced to deal with concurrency (yes they will jump one by one).

>From what I'm seeing, the logical conclusion is, whanever the worker need to wait file io or any other return like database it should let the request as blocked (like a process) and move to next, and then collect an interruption or event for io completed. You are saying it keeps the worker locked waiting for response?

It doesn't interrupt when completed.

Say request A gets served first.
Request B has to wait.
After some processing request A needs to load a file.
So A does an IO request and passes a callback function.
Now request A is put on hold and request B gets handled instead.
The file A requested is ready, but B is still busy so nothing happens on A yet.
OK, B is done so now it's finally A's turn again.
The callback function A passed with its IO request now gets executed with the file content as an argument.

Ironically, Javascript is actually based on Lisp.

It has C/Java type syntax but the way the interpreter works is much closer to Lisp.
It also treats functions as first class citizens - it's just unfortunate that it has no easy way of manipulating function programmatically but that's mostly a syntax issue I think.

>first class citizens
kek

>JS
>Lisp
Are you shitting on lisp?

Isn't that what every Lisp professor calls it?

What are you talking about

Yes, Javascript is a bastardisation of Lisp with a ton of normie-friendly features and a cancerous, C-based normie syntax. This results in people who would have absolutely no idea how to write anything in Lisp being able to throw together monstriosities using javascript.

JavaScript is the closest mainstream language to LISP.

Dynamic programming, callbacks, etc.

It lacks macros unfortunately, so it is quite useless.

I can't wait until Trump puts javascript "programmers" into camps.

You want Elixir (built on Erlang).

>Javascript is actually based on Lisp.

barely, brendan eich approached his bosses with a Scheme-based version of ECMAscript, they told him to trash it for C/Java style OOP

Common Lisp is a mainstream language, it has better cross-platform support than just about any other language and 40+ years of libraries (it was a standardization of other lisps), just because you can't get a code monkey enterprise IT job does not mean your language is obscure and the community is better off for keeping the pajeets away

>he way the interpreter works is much closer to Lisp.
What the fuck is that even supposed to mean? Are you unaware of there being a myriad of Lisp compilers and countless Lisp interpreters that all work in many different ways?

>callbacks are a feature of Lisp
Are you literally retarded?

Here's a serious answer to your bait thread. Instead of having a codebase of C++, JavaScript and whatever glue to make it all work, just write the entire thing from top to bottom in JS. It'll probably end up far less complex if all you're doing is some CRUD shit.

Also your average developer has no business using C++ anywhere near the web. It's a bad business decision. Even if you can write secure network code that doesn't break as soon as you have 1000 connections, doesn't mean you can trust everyone else you work with to be able to as well. That's how you manage a team when you don't have access to top talent, but still need to ship a product

This is how nginx works. They have an event queue with worker threads pulling events off the queue. By default it has 1 worker for each core. However, unlike node it's queue and message processing architecture isn't retarded.

nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

>C++ is used on f-35
>javascript isn't
checkmate

It has already been done in C++, Java, Tcl and many more, but...
It's not an actual good choice, but a consequence of V8 following the JS spec.
Without threads or other means of concurrency they had to implement it by running the interpreter in an event loop with a callback API.

The computer industry is the only industry that is more fashion-driven than women's fashion.

Why don't they just add threads to js?

Because they haven't really figured out how to keep the DOM from race conditioning.
Loading a website is already a clusterfuck, I can't blame them to not wanting to complicate this.

Kestrel

>the average node.js user

what do you need threads for when everything is asynchronous

user probably wants to do actual work in his scripts

Pic related is me

i just created a d3 visualization that allows users to filter data between 2 periods and gives you a tooltip on hovering over the line. it only took me 400 lines of JS. ask me anything

>Why don't they just add threads to js?
Node is implemented in C++, adding threads to Javascript wont do anything because you cant use Javascript as a systems/networking language because Javascript lacks any kind of standard library.

>Inb4 multiprocess, nobody sets up node this way, and thats even more difficult than threads.

Explain why the fuck not? Some issue with load balancing? If you need shared state between processes outside the data store urdoinitwrong, yeah? Spawning one instance per core with fixed affinity should just werk.

[not him]
Node runs on a single event loop which is dispatching tasks to the operating system, putting multiple event loops isnt going to speed anything up, there is only one operating system to interface with that is doing all the I/O, whether you are feeding the OS with 1 event loop or 20, it doesnt make any difference

That still leaves all computationally bound tasks blocking the thread.
Node doesn't have webworkers because the devs are memeing retards that think spawning more processes is the only solution, so that's basically your only way if something is computationally bound.

>Node is implemented in C++, adding threads to Javascript wont do anything because you cant use Javascript as a systems/networking language because Javascript lacks any kind of standard library.
JavaScript is not the problem here, it's a shitty fucking language but it works. The problem is that V8 is not thread-safe hence node is not either.
MongoDB uses V8 too and has the same problem, it came to the very stupid conclusion a map reduce can only be ran in a single thread per shard due to this limitation.

No; that's total bullshit. Modern OS kernels are reentrant and can serve multiple tasks concurrently without one blocking any of the others. You get an even bigger win on modern SMP systems that can run multiple processes in parallel.

This argument only applies if you're totally IO bound with 1 thread fully loading all IO devices. If not adding processes absolutely will help.

thats true, here is a better diagram that shows what is actually happening

lol wow

libevent.org/

and a even better diagram still

no, they started using nodejs because they're javascript nerds

So instead of create a thread for every connection, node manage everything in single loop.
Pretty good idea if there are only IO operation, but what happen if we need to calculate something? Can we push that task to worker threads?

No, remember all these worker threads are communicating through a single event queue, if the threads take too long to execute, everything gets backed up, this is why Node is only good for SPA backends where youre only concerned with quick response time.

Clustering

should just use go

Excellent post

Parallelism != Async

Derp