3 ms·

I see what the author is getting at, but I don't see the reason for a language to provide this isolation. Why not just use an OS-level process? Why not create

by j_baker 15y ago

I see what the author is getting at, but I don't see the reason for a language to provide this isolation. Why not just use an OS-level process? Why not create a library or framework to do this?

masklinn 15y ago
> Why not just use an OS-level process? OS-level processes are very expensive (and the OS themselves may set quite harsh limits on e.g. the number of processes you can have[0]) leading to lower flexibility. Furthermore, process-based IPC tends to be untyped (unless you're willing to pay for the price of serialization and deserialization of higher-level structures). Finally, the ability to link processes together and react to events (mostly death) of unrelated processes (no SIGCHLD and no SIGHUP) are limited. [0] it defaults to 532 on a non-server Snow Leopard system, for instance...
- andrewvc 15y ago
  nptl (read, any modern kernel) Linux processes are cheap, they share an implementation with threads in fact. Note that this only means they can be quite cheap, if you dirty a large amount of memory you lose CoW of course.
  - masklinn 15y ago
    > nptl (read, any modern kernel) Linux processes are cheap They're not 300-bytes cheap. They're not you-can-have-a-million-of-them-on-a-desktop-box cheap. Erlang's processes are.
petar 15y ago
The other commenter has a good answer and I will re-iterate (I'm the author): Sure you can everything the old school way. The point is that being able to replace processes with in-program constructs is both less expensive resource-wise (memory, OS engagement, etc.) as well as more convenient to program (and thus making the programmer more productive). Language design questions are very much about how to make the programming process more productive and less error prone. So the focus should be on convenience. Of course, you can do everything the old-fashioned way (but that's not the point).
- j_baker 15y ago
  Language design questions are also about how to not make languages complex and add too many features to them. I'd argue that creating or modifying a language should be a last resort. After all, there's nothing to stop you from implementing this in Python right now with thread-local storage, and I'm sure you could achieve the same effect with other languages if you don't like the idea of the GIL or slow interpreted languages.

by j_baker 15y ago

I see what the author is getting at, but I don't see the reason for a language to provide this isolation. Why not just use an OS-level process? Why not create a library or framework to do this?

masklinn 15y ago

> Why not just use an OS-level process? OS-level processes are very expensive (and the OS themselves may set quite harsh limits on e.g. the number of processes you can have[0]) leading to lower flexibility. Furthermore, process-based IPC tends to be untyped (unless you're willing to pay for the price of serialization and deserialization of higher-level structures). Finally, the ability to link processes together and react to events (mostly death) of unrelated processes (no SIGCHLD and no SIGHUP) are limited. [0] it defaults to 532 on a non-server Snow Leopard system, for instance...

andrewvc 15y ago
nptl (read, any modern kernel) Linux processes are cheap, they share an implementation with threads in fact. Note that this only means they can be quite cheap, if you dirty a large amount of memory you lose CoW of course.
- masklinn 15y ago
  > nptl (read, any modern kernel) Linux processes are cheap They're not 300-bytes cheap. They're not you-can-have-a-million-of-them-on-a-desktop-box cheap. Erlang's processes are.

petar 15y ago

The other commenter has a good answer and I will re-iterate (I'm the author): Sure you can everything the old school way. The point is that being able to replace processes with in-program constructs is both less expensive resource-wise (memory, OS engagement, etc.) as well as more convenient to program (and thus making the programmer more productive). Language design questions are very much about how to make the programming process more productive and less error prone. So the focus should be on convenience. Of course, you can do everything the old-fashioned way (but that's not the point).

j_baker 15y ago
Language design questions are also about how to not make languages complex and add too many features to them. I'd argue that creating or modifying a language should be a last resort. After all, there's nothing to stop you from implementing this in Python right now with thread-local storage, and I'm sure you could achieve the same effect with other languages if you don't like the idea of the GIL or slow interpreted languages.