I haven't heard of ToffeeScript before, but this is pretty much how Erlang works. Whenever you make a blocking call, all of the async stuff happens under the hood, so that you just deal with sequential code.
Erlang's concurrency model deals with lots of lightweight processes. Rather than having callbacks it uses a message system. Whenever a process waits for a message it yields so other processes can be executed.
In your example there would be a process separate from the main[0] process that handles the database connection. When you request the update to the database, you are just sending a message to the database connection process. This will receive the message and handle the update when it can[1], and once complete, send you a message back with the result of the update. During the waiting period the VM will continue executing other processes. No callbacks needed :)
[0] Erlang concurrency is based upon the actor model. There isn't really a main process, but for the sake of explanation...
[1] The database connection process will actually block while making the update, so if you have 10,000 processes calling this, you will have a bottleneck. As such you should have a pool of database connection processes, rather than just one.
Yeah Erlang looks awesome and I should definitely try to learn it at some point.
To me Node.js and ToffeeScript seem a lot more straightforward and have the advantage of the whole package system which I believe is more advanced, as well as the npm ecosystem with 54,000 packages.
But anyway it would be good to actually learn Erlang and use it in some projects so that I can really evaluate it.
I'm not sure but I think it might be a lot more resource efficient for one thing.
Erlang's concurrency model deals with lots of lightweight processes. Rather than having callbacks it uses a message system. Whenever a process waits for a message it yields so other processes can be executed.
In your example there would be a process separate from the main[0] process that handles the database connection. When you request the update to the database, you are just sending a message to the database connection process. This will receive the message and handle the update when it can[1], and once complete, send you a message back with the result of the update. During the waiting period the VM will continue executing other processes. No callbacks needed :)
[0] Erlang concurrency is based upon the actor model. There isn't really a main process, but for the sake of explanation...
[1] The database connection process will actually block while making the update, so if you have 10,000 processes calling this, you will have a bottleneck. As such you should have a pool of database connection processes, rather than just one.