5 ms·

> In this approach, threads own their data, and communicate with message-passing. This is easier said than done, because the language constructs, primitives, an

by SEMW 11y ago

> In this approach, threads own their data, and communicate with message-passing. This is easier said than done, because the language constructs, primitives, and design patterns for building system software this way are still in their infancy "Still in their infancy"? That's basically a description of Erlang's concurrency model, almost three decades old now. Is there a concurrency equivalent of Spencer's law -- something along the lines of "Those who do not understand Erlang are doomed to reinvent it"?

vezzy-fnord 11y ago
occam, as well. They're not entirely wrong, though. Actor model and CSP are in their infancy w.r.t. mainstream usage, even though they seem to be working really well. Then Erlang/OTP gives you all sorts of other perks besides concurrency.
- MichaelGG 11y ago
  OTP will probably really take off once there's a solid, maintained, port for a nicer and faster language.
  - vezzy-fnord 11y ago
    Solid, maintained and nice is already there. As for speed, one must define their needs. Throughput, latency, asynchronicity and GC strategy (which is per-process and concurrent in Erlang) can all affect perceptions of "speed". Then you're given a multitude of ways to interface with C code, right down to treating a C program like it's an Erlang VM node.
  - mcguire 11y ago
    I keep thinking about OTP in Rust. Unfortunately, they got rid of M:N threads, which makes threading less of a useful abstraction.
    - erickt 11y ago
      We're still pretty confident that Rust will be able to support a high quality green threading library and other M:N concurrency libraries without needing to be integrated into the language itself. All the type magic that we do to pass data between threads should work quite well for a green threading library. We already have a couple projects experimenting with this [1], [2], [3]. Servo also has a pretty nifty work-stealing queue [4] that is yet another abstraction for easily sharing data between threads. 1: https://github.com/rustcc/coroutine-rs https://github.com/rustcc/coroutine-rs 2: https://github.com/zonyitoo/simplesched https://github.com/zonyitoo/simplesched 3: https://github.com/dpc/mioco https://github.com/dpc/mioco 4: https://github.com/servo/servo/blob/c76720d67c0d04f6d77c138c295b4fd4ebf24ee3/components/util/workqueue.rs https://github.com/servo/servo/blob/c76720d67c0d04f6d77c138c...
  - shepardrtc 11y ago
    The Erlang team is working on a JIT for the language, and the first release should be out soon. That should help with the "faster" part. "Nicer" is rather subjective. I happen to enjoy how Erlang looks and works, though it took me a couple of tries before I really liked it. I'm not sure why people don't jump on the idea of a bulletproof VM.
    - MichaelGG 11y ago
      Doesn't seem as concise as an ML is one of my factors in "nice". I guess I don't care about a bulletproof VM because I've not had issues with the JVM, CLR or other systems. And BEAM reeks of instability. Furthermore the resulting apps seem to bear no relation to Erlang's robustness. Look at RabbitMQ. Lots of stability problems... So what's Erlang saving us from?
      - tormeh 11y ago
        Your sense of nice conflicts with Erlang's goal of supporting reliable systems. For example, Erlang is not designed using the paradigm du jour. It may seem like Erlang borrows from functional programming, but Erlang's designers invented all that independently because it supported writing reliable systems. Concise and maintainable are antagonistic qualities, and so Erlang's designers sacrificed all the conciseness they could get away with. Erlang is not deisgned to be nice, elegant or have any other property people normally advertise their language as having. Erlang is designed so that programmers at Ericsson could write better code for phone switches, with constant feedback from said programmers. That's Erlang's mission statement, originally. If you want concise actors, Scala with Akka allows you to write pretty unreadable code if you want to.
        incepted 11y ago
        > Concise and maintainable are antagonistic qualities Uh? How so? That's quite a strange argument to rationalize Erlang's verbosity and boiler plate.
        SEMW 11y ago
        > Your sense of nice conflicts with Erlang's goal of supporting reliable systems. Obvious counterexample: Elixir. Plenty of modern niceties that Erlang lacks (rubyesque syntactic sugar, scheme-style hygenic macros, the pipe operator, mix, etc), but shares most of Erlang's semantics and ultimately compiles down to the same bytecode, so AFAICS doesn't sacrifice any of the things that make Erlang good for building reliable systems.

by SEMW 11y ago

vezzy-fnord 11y ago

occam, as well. They're not entirely wrong, though. Actor model and CSP are in their infancy w.r.t. mainstream usage, even though they seem to be working really well. Then Erlang/OTP gives you all sorts of other perks besides concurrency.

MichaelGG 11y ago
OTP will probably really take off once there's a solid, maintained, port for a nicer and faster language.
- vezzy-fnord 11y ago
  Solid, maintained and nice is already there. As for speed, one must define their needs. Throughput, latency, asynchronicity and GC strategy (which is per-process and concurrent in Erlang) can all affect perceptions of "speed". Then you're given a multitude of ways to interface with C code, right down to treating a C program like it's an Erlang VM node.
- mcguire 11y ago
  I keep thinking about OTP in Rust. Unfortunately, they got rid of M:N threads, which makes threading less of a useful abstraction.
  - erickt 11y ago
    We're still pretty confident that Rust will be able to support a high quality green threading library and other M:N concurrency libraries without needing to be integrated into the language itself. All the type magic that we do to pass data between threads should work quite well for a green threading library. We already have a couple projects experimenting with this [1], [2], [3]. Servo also has a pretty nifty work-stealing queue [4] that is yet another abstraction for easily sharing data between threads. 1: https://github.com/rustcc/coroutine-rs https://github.com/rustcc/coroutine-rs 2: https://github.com/zonyitoo/simplesched https://github.com/zonyitoo/simplesched 3: https://github.com/dpc/mioco https://github.com/dpc/mioco 4: https://github.com/servo/servo/blob/c76720d67c0d04f6d77c138c295b4fd4ebf24ee3/components/util/workqueue.rs https://github.com/servo/servo/blob/c76720d67c0d04f6d77c138c...
- shepardrtc 11y ago
  The Erlang team is working on a JIT for the language, and the first release should be out soon. That should help with the "faster" part. "Nicer" is rather subjective. I happen to enjoy how Erlang looks and works, though it took me a couple of tries before I really liked it. I'm not sure why people don't jump on the idea of a bulletproof VM.
  - MichaelGG 11y ago
    Doesn't seem as concise as an ML is one of my factors in "nice". I guess I don't care about a bulletproof VM because I've not had issues with the JVM, CLR or other systems. And BEAM reeks of instability. Furthermore the resulting apps seem to bear no relation to Erlang's robustness. Look at RabbitMQ. Lots of stability problems... So what's Erlang saving us from?
    - tormeh 11y ago
      Your sense of nice conflicts with Erlang's goal of supporting reliable systems. For example, Erlang is not designed using the paradigm du jour. It may seem like Erlang borrows from functional programming, but Erlang's designers invented all that independently because it supported writing reliable systems. Concise and maintainable are antagonistic qualities, and so Erlang's designers sacrificed all the conciseness they could get away with. Erlang is not deisgned to be nice, elegant or have any other property people normally advertise their language as having. Erlang is designed so that programmers at Ericsson could write better code for phone switches, with constant feedback from said programmers. That's Erlang's mission statement, originally. If you want concise actors, Scala with Akka allows you to write pretty unreadable code if you want to.
      - incepted 11y ago
        > Concise and maintainable are antagonistic qualities Uh? How so? That's quite a strange argument to rationalize Erlang's verbosity and boiler plate.
      - SEMW 11y ago
        > Your sense of nice conflicts with Erlang's goal of supporting reliable systems. Obvious counterexample: Elixir. Plenty of modern niceties that Erlang lacks (rubyesque syntactic sugar, scheme-style hygenic macros, the pipe operator, mix, etc), but shares most of Erlang's semantics and ultimately compiles down to the same bytecode, so AFAICS doesn't sacrifice any of the things that make Erlang good for building reliable systems.