3 ms·
Of all the methods for dealing with async calls I've come across, I strongly prefer the Smalltalk process flavor. The general idea is that main runs in a fiber
by sifoobar 8y ago
Of all the methods for dealing with async calls I've come across, I strongly prefer the Smalltalk process flavor.
The general idea is that main runs in a fiber (or process in Smalltalk lingo) out of the box. There's a way of starting new fibers, yielding to the next; and blocking calls yield automagically. And that's it.
But talk is cheap, and Smalltalk is not coming back anytime soon; which is why I'm building a new language [0] around the same ideas.
https://gitlab.com/sifoo/snigl https://gitlab.com/sifoo/snigl
- deleted 8y ago[deleted]
- nightfly 8y agoIsn't that pretty much how Erlang does things?
- ekimekim 8y agoYep, and golang, and python with gevent (linked in the article). The general approach is often called "green threads" or "userspace threads".
- sifoobar 8y agoGo runs NxM threading behind the scenes, it's far from the same thing. By choice, but it's not what I'm aiming for. And it needs to be built into the core (as opposed to gevent), otherwise it wont run as fast as it could and can't integrate deeply enough with IO to be seamless.
- seabrookmx 8y agoWhen doing network calls golang will yield in a similar fashion as described in the thread above. However this is standard library magic and and user code will indeed run in the context of a goroutine which is NxM threading.
- sifoobar 8y agoErlang throws plenty of other ideas into the mix though, I prefer my concerns separated. It assumes multiple threads for example, in plenty of applications that's needless complexity. You end up sending messages between processes when all you wanted to do was encapsulate some state.
- dnautics 8y agoElixir solves this with Agent.