Hacker News new | past | comments | ask | show | jobs | submit login

It's occurred to me that asynchronous programming is essentially just very lightweight green threads with the added benefit of scheduling tied directly to I/O.

Synchronous programming is typically much more natural. It's too bad no languages have opted to abstract this away. Of course I suppose coroutines are kind of that.




>It's too bad no languages have opted to abstract this away.

Erlang and other BEAM languages like Elixir and LFE kind of do. They use the actor model for concurrency and message passing is asynchronous. However, most of the time directly after sending a message, a program waits for a reply message, which blocks the calling process until the reply arrives, or a configurable timeout passes, making it a synchronous call. This is ok since spawning new processes is very cheap, so a web server for example idiomaticly spawns a new process for every request, making blocking calls in one request not interfere with other requests. The result is highly concurrent code that is mostly written synchronously without creating red function/ blue function kind of divisions most(?) async/await implementations have.


Erlang does that. The logic inside erlang processes look synchronous but outwardly its all async.

For example you can send a message to a different process, even running on a different machine and wait for the reply right there in the next line. It doesn't hold any OS threads.


Intriguing thought, async to what?

If a program needs the input before continuing doesn't it need to wait and therefore hold the program flow and therefore stop, even in erlang?


>If a program needs the input before continuing doesn't it need to wait

Erlang applications are developed using message passing Actors which are implemented as very light weight processes/green-threads.

So your process that sent a message can wait for the reply synchronously. It doesn't hold anything up in the overall application.

You can have hundred of thousands of these processes running in a node.

Do check it out. It is very liberating. Why it is not vastly more popular is a mystery to me.


While it's possible to have thousands of these processes running, it's completely up to the problem domain for it to be useful. If it wouldn't be bound by the problem domain you wouldn't need to write actors either.


Vibe.d [0] the one and only D web framework uses fibers, because of this reason. The tagline is "Asynchronous I/O that doesn’t get in your way"

I'm not sure about the tradeoff. It seems to be equivalent with performance. It might require more memory, but if the competition is Java, Python, and Ruby then they are easy to beat in terms of memory consumption. I'm not sure how it compares to Go.

[0] http://vibed.org/


Python has gevent and eventlet which achieve this pattern.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: