Sweeper posted:

Lets not give the users something they don't understand, then they won't have to understand it!

Zombywuf posted:

Let's not give user's anything. gently caress users. If they can't write it themselves they don't deserve it.

rotor posted:

god I hate users SO MUCH

Zombywuf posted:

Users are the worst. Except for developers.

Zombywuf posted:

Oh how I wish for a language that had read more than 2 chapters of CSP.

Gazpacho posted:

are you talking about all the traces stuff because i dont see how that works into a language

OBAMA BIN LAUGHIN posted:

because the world is still racist as gently caress

Zombywuf posted:

Racist against mathematicians.

Hard NOP Life posted:

David Hilbert

trex eaterofcadrs posted:

georg cantor

trex eaterofcadrs posted:

georg cantor

Cocoa Crispies posted:

OBAMA BIN LAUGHIN posted:

this but moose milkie

MononcQc posted:

I'm due for a carepost on why node.js is a terrible idea.

Let's say I'm writing a server app decades ago. I start from scratch, on a computer with a single core. I first write my little socket acceptor dealing with TCP stuff. It opens a listen socket, waits to accept a connection, and then parses the request, dispatches it to some library function I have written, which goes fetch the data, builds the page that will result in it, then push it to the client. I then go back and accept another connection. This gives me an execution model a bit like that:

code:

accept -> parse -> dispatch -> read -> read more -> write -> push.

If two requests come at the same time under that model, one of these will have to wait until the other one is done before even being able to start:

code:

accept -> parse -> ... -> write -> push -> accept -> parse -> ... -> write -> push.

Realizing this, I wish I had parallelism to allow a flow more like this:

code:

accept -> parse -> dispatch -> read -> read more -> write -> push.
accept -> parse -> dispatch -> read -> read more -> write -> push.

But I can't -- I'm using a single processor and I am using a poo poo platform that doesn't support concurrency in any way (coroutines, threads [OS threads included], erlang-style processes [akka included], clojure-style actors, etc.) because I'm in the stone-age of computers and also no library for this exists. So what do I do? Well, I guess I'll break them up and track them by hand with callbacks -- it's the only way:

code:

(accept 1) -> (accept 2) -> (parse 1) -> (parse 2) -> (dispatch 1) -> ...

Which I guess is kind of okay, but annoying. poo poo can be locked up, I need to manually split everything in callbacks that will register themselves in order to know when things are done (something like resource.ready(callback)), I need to keep track of everything manually (is this parse for request 1, 2 or 73?).

Then at some point, computer evolution allows us to have things like threads and processes, and other proper concurrency mechanisms. By making things fork, go parallel, go async, or whatever after accepting, I'm able to serve two queries at once, without special care. If I have only my one processor with one core, then it will transform:

code:

accept -> parse -> dispatch -> read -> read more -> write -> push.
accept -> parse -> dispatch -> read -> read more -> write -> push.

automatically into:

code:

accept ->        parse ->          dispatch ->             read -> ...
        accept ->          parse ->             dispatch ->        ...

without me even needing to make a special effort, especially if there's a form of preemptive scheduling going on. I won't have to understand the callback based form of:

code:

(accept 1) -> (accept 2) -> (parse 1) -> (parse 2) -> (dispatch 1) -> ...

which will be declared as:

code:

accept (when accepted call parse callback)
parse (when parsed call dispatch callback)
dispatch (read once, when done, call dispatch2)
dispatch2 (read a second time, also when done reading, write)
read (when done call callback)
write (when done reading, push)

I'll only need to keep my code pretty much the same.

Then at some point, I may gain parallelism on top of it Awesome, poo poo will go great, except maybe my writes, which will need to block to be sane. What I'll be able to do with my concurrent code (not callback-based) is:

code:

accept -> parse -> dispatch -> read -> read more -> write -> push.
accept -> parse -> dispatch -> read -> read more ->        write -> push.

My code that was concurrent is now parallel by default, and I limit how much blocking I need to do (assuming the write is written to block correctly, either via transactions, safe queues, mutexes, locks or whatever). However, if I go back to my callback-based code and get parallel, what I get is still this:

code:

(accept 1) -> (accept 2) -> ... (write 1) -> (write 2) -> (push 1) -> (push 2)

And I want to get the speedup of my friends in the parallel and concurrent worlds. So I know what I'll do! I'll add non-blocking IO and will send poo poo to concurrent drivers in charge of doing poo poo right!

code:

(accept 1) -> ... ->          ->              -> (write 1) -> (write 2) ->
                     (read 1)    (read more 1)                             (push 1)
                     (read 2)    (read more 2)                             (push 2)

See? I got the parallelism going! I only did so at the cost of a shittier way to read and write code, still as sensitive to failures or blocks from independent requests, and relying heavily on the implementation of individual drivers not to gently caress my poo poo up! It's still worse on every level, but hey, I get to keep using my callback-based code (not that it's impossible to do in concurrent/parallel systems anyway). Hooray.

While the modern world of programming on servers has moved to concurrent and parallel methods a long while ago (mostly because they are objectively better), Javascript users with node.js came crashing through the door and said "we have a great new model! it's callbacks with non-blocking IO! it's loving great!".

Everyone who is not node.js knows what they propose is worse than what exists. It's like someone inventing PHP again, but for server-side platforms.

Node still has a decent community, interesting libraries, documentation, etc. In some cases better than many other communities and libraries. Parallel and concurrent code still is tricky to write without high-level constructs to keep you from having deadlocks, memory corruption, etc. and requires a lot of discipline otherwise.

This changes nothing to the fact that the underlying model of node.js is still outdated garbage. It's the worst of both world.

Otto Skorzeny posted:

mumble mumble gar1t on youtube

gucci void main posted:

Coffee Jones posted:

https://www.youtube.com/watch?v=b2F-DItXtZs oh wow

Coffee Jones posted:

https://www.youtube.com/watch?v=b2F-DItXtZs oh wow

gucci void main posted:

is that true about mongodb that it "stages data to be written later" cause if so then lol

vapid cutlery posted:

you could just say cooperative multitasking is bad but i don't think anyone who really uses node even knows what that means

MononcQc posted:

Last time something like that happened, node.js people took a blog post that had a fibonacci server example to demonstrate CPU-intensive code would block node in the most literal sense, and you then had 2-3 days of node programmers trying to prove they could write good fibonacci servers and posting the results on hacker news.

Gazpacho posted:

no the blogger specifically said closed form was beside the point