3 ms·

This strikes me a pragmatic decision driven by wanting to reduce complexity and be interoperable with 3rd party libraries (mostly C code). If you read my other

by mtanski 13y ago

This strikes me a pragmatic decision driven by wanting to reduce complexity and be interoperable with 3rd party libraries (mostly C code). If you read my other comment here, I outlined the problems I ran into with the N:M threading model (although mostly in C land). It strikes me as Rust ran into the same issues. I'm beginning to think that you can't make N:M well unless you take the approach that language X itself is the platform and everything needs to be done in language X. Java has taken this approach (yes I knot there's the JNI -- we know how fun to use it us -- but the Java community is pretty bent on writing almost everything in Java). Go seams to be going that direction by rewriting all the standard library, runtime and compilers slowly in Go. I don't know Erlang's stance on this. It looks like Rust is taking the approach of we want to be a systems language AND we want to be interoperable with tons of existing 3rd party code (which implies mostly other C libraries). P.S: Nice to see you commenting here Jermey. It's been a long time since we talked (cuda days).

jerf 13y ago
"I don't know Erlang's stance on this." Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. Not only that it isn't "stop the world" but that it's also fairly trivially so. It doesn't have synchronization problems because it basically doesn't have synchronization. (In the OS sense. Of course your user code may have various sync concerns, but there's no OS-level race conditions, or memory race conditions, etc.) It pays for these characteristics, but also reaps various benefits. (It's a pity that I don't know of any great single chunk of documentation on the Erlang VM I can point to; links solicited. It's such a different beast. Someone interested in learning about how it's different without necessarily learning Erlang would probably better just studying the VM itself.) P.S.: Yo, 'sup.
- pcwalton 13y ago
  > Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. This is the same as Rust.
  - jlouis 13y ago
    I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where you can use stop-the-world GCs and still avoid pause times.
    - pcwalton 13y ago
      > If Rust has a single large shared heap for all proceses, then the approach is different. Rust does not use one shared heap. Tasks cannot share memory (except through ARCs, which manage their own memory through atomic reference counting and so avoid garbage collection pauses). Garbage collection is completely local to a task, so while one task is collecting garbage other tasks are free to run.
- gtani 13y ago
  BEAM documentation: I don't think there's anything more concrete than Armstrong's first cut mentioned: https://groups.google.com/forum/#!searchin/erlang-programming/beam$20documentation$2C$20opcodes/erlang-programming/UspXtyb3yr0/6ie2yXMZ_-AJ https://groups.google.com/forum/#!searchin/erlang-programmin... OR: https://groups.google.com/forum/#!searchin/erlang-programming/beam$20documentation$2C$20opcodes/erlang-programming/nqFFXXCotME/-qICkpHQMI0J https://groups.google.com/forum/#!searchin/erlang-programmin... re: SMP scheduler (there may be other better info on the list, but I can't google it https://groups.google.com/forum/#!topic/erlang-programming/0axWwyWq8Aw https://groups.google.com/forum/#!topic/erlang-programming/0...
- pyotrgalois 13y ago
  Why do you think it pays for these characteristics? I'm interested on your point of view.
  - jerf 13y ago
    Some is just performance; there's an inevitable performance loss on copying. I've had some trouble with the binary sharing routines still leaking on me, though that got better as the VM improved. Some of it is a bit more theoretical, such as the way Erlang basically has no type system, which I believe is so that everything has an unambiguous serialization which is used for the cross-node communication, but I believe more modern languages have more flexible solutions. Really, though, it's just that "nothing is free"; it's not as if these decisions are so bad that they are objectively wrong, it's just, nothing is free.

by mtanski 13y ago

jerf 13y ago

"I don't know Erlang's stance on this." Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. Not only that it isn't "stop the world" but that it's also fairly trivially so. It doesn't have synchronization problems because it basically doesn't have synchronization. (In the OS sense. Of course your user code may have various sync concerns, but there's no OS-level race conditions, or memory race conditions, etc.) It pays for these characteristics, but also reaps various benefits. (It's a pity that I don't know of any great single chunk of documentation on the Erlang VM I can point to; links solicited. It's such a different beast. Someone interested in learning about how it's different without necessarily learning Erlang would probably better just studying the VM itself.) P.S.: Yo, 'sup.

pcwalton 13y ago
> Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. This is the same as Rust.
- jlouis 13y ago
  I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where you can use stop-the-world GCs and still avoid pause times.
  - pcwalton 13y ago
    > If Rust has a single large shared heap for all proceses, then the approach is different. Rust does not use one shared heap. Tasks cannot share memory (except through ARCs, which manage their own memory through atomic reference counting and so avoid garbage collection pauses). Garbage collection is completely local to a task, so while one task is collecting garbage other tasks are free to run.
gtani 13y ago
BEAM documentation: I don't think there's anything more concrete than Armstrong's first cut mentioned: https://groups.google.com/forum/#!searchin/erlang-programming/beam$20documentation$2C$20opcodes/erlang-programming/UspXtyb3yr0/6ie2yXMZ_-AJ https://groups.google.com/forum/#!searchin/erlang-programmin... OR: https://groups.google.com/forum/#!searchin/erlang-programming/beam$20documentation$2C$20opcodes/erlang-programming/nqFFXXCotME/-qICkpHQMI0J https://groups.google.com/forum/#!searchin/erlang-programmin... re: SMP scheduler (there may be other better info on the list, but I can't google it https://groups.google.com/forum/#!topic/erlang-programming/0axWwyWq8Aw https://groups.google.com/forum/#!topic/erlang-programming/0...
pyotrgalois 13y ago
Why do you think it pays for these characteristics? I'm interested on your point of view.
- jerf 13y ago
  Some is just performance; there's an inevitable performance loss on copying. I've had some trouble with the binary sharing routines still leaking on me, though that got better as the VM improved. Some of it is a bit more theoretical, such as the way Erlang basically has no type system, which I believe is so that everything has an unambiguous serialization which is used for the cross-node communication, but I believe more modern languages have more flexible solutions. Really, though, it's just that "nothing is free"; it's not as if these decisions are so bad that they are objectively wrong, it's just, nothing is free.