16 ms·

If anyone is looking for another language that also uses the actor model for concurrency and has very similar ways of handling it like D, then checkout Erlang.

If anyone is looking for another language that also uses the actor model for concurrency and has very similar ways of handling it like D, then checkout Erlang. It's language lessons are clearly still relevant today. :)

athenot 9y ago
I'm a big fan of Erlang—and believe it's a useful language to know even if the daily language is something else—but my understanding of D is that it excels in a different problem space (build efficient native code, etc.)
elsurudo 9y ago
Important to point out Elixir as well, which is touted as a "more modern" way to write code that runs on the Erlang VM (so you get the same concurrency features, etc.)
- strkek 9y ago
  The _only_ downside I find of Elixir is that it looks too Ruby-ish to my taste. I'm still waiting for the day a C-like language that runs on BEAM becomes mainstream enough.
  - StavrosK 9y ago
    Here's my thought process while reading your comment, which illustrates why we can't have nice things: > The _only_ downside I find of Elixir is that it looks too Ruby-ish to my taste. Yeah, preach it! > I'm still waiting for the day a C-like language that runs on BEAM becomes mainstream enough. Eww.
    - strkek 9y ago
      Haha yeah, I've become too used to C-like syntax (C, Go, Rust, etc). I wouldn't mind a Lisp syntax too, but Ruby and ML are definitely a "no" from me. I just can't bring myself to like them. Their syntax feels too "loose", not sure if that makes sense. Btw, I know there are some Lisp-like implementations out there, but same criteria applies: still not mainstream enough as of now.
      - StavrosK 9y ago
        No, I agree with you completely, I'm just remarking on how everyone will have different aesthetics and things they're used to, and, ultimately, that might not be a valid complaint. Like, sure, I don't like Ruby's syntax much, but if the ecosystem is good and the language is a joy to write, eh, I'm going to compromise because you can't please everyone's subjective preferences.
      - krick 9y ago
        Could you clarify, what's wrong with the Ruby syntax, exactly? I don't think there's a single programming language I like in terms of the syntax, but I don't see anything really wrong with Ruby. Surely not to the point I wouldn't use otherwise nice language because of it. Is python a no-no as well?
        heavenlyblue 9y ago
        He thinks the syntax doesn’t “pop”, clearly.
        strkek 9y ago
        It's not "wrong"; it just doesn't appeal me. - `elsif` - `end` - `unless` - `a unless b` - `f 1` vs `f(1)` - Implicit method calls (`f` vs `self.f`). I know both have different behavior, I just don't like this "implicit self". ... etc. I find Python okay-ish though, as paradoxical and nonsensical as that might sound. But in my toolchain Python has been reduced to little more than a calculator, since it's been replaced by Go for most of my automation needs. Btw, friendly reminder that this is my subjective opinion regarding my own tastes, not absolute truth on aesthetics. EDIT: Formatting.
        mercer 9y ago
        Speaking for Elixir, a few notes: I rarely find myself using if/else statements and I definitely avoid 'unless'. One of the 'Rubyisms' I really disliked was the optional parentheses for method calls. While these are still optional for good reason, in practice this is no longer the case. The formatter will add parentheses and IIRC the compiler will give you a stern lecture too. Obviously taste is subjective, but I do agree it matters. I'd say if the Ruby-like syntax is what keeps you from trying Elixir, remember that's it's only skin deep and at least for me, the bad stuff is not really there compared to Ruby. Furthermore, the advantages of having a functional and 'lispy'/homoiconic language that doesn't look like my bathroom floor after clipping my toenails is worth any remaining 'niggles' like the begin/end thing, or optional [] in the last parameter of a function call, etc. (which just like the optional parentheses is there for a very good reason).
    - erokar 9y ago
      I had the exact same reaction. > The _only_ downside I find of Elixir is that it looks too Ruby-ish to my taste. Granted. More ML-like would be nice. > I'm still waiting for the day a C-like language that runs on BEAM becomes mainstream enough. WTF!?
  - ancarda 9y ago
    >I'm still waiting for the day a C-like language that runs on BEAM I used to have a similar desire! I actually started working on a language that transpiled to Haskell, like CoffeeScript -> JS. What I found, however, is a lot of little ways to make it more and more terse, until I ended up with something resembling Haskell’s syntax. After this happened several times, I had some new found appreciation for Haskell’s syntax. It’s god awful for someone coming from a C-like background, but that seems like a very temporary problem. I went from hating Haskell’s syntax so much I wanted a language wrapping it, to realizing it’s actually rather well thought out and other languages have a lot of noise to them. Lots of curly braces and semicolons that seem to mostly be there to make writing a compiler easier. I still love C-like syntax, and still don’t like Haskell’s syntax, but not enough to write a CoffeeScript-like language.
  - jfhufl 9y ago
    Funny, I love Ruby and it's my primary language of choice, but I'm a heretic, using braces whenever I can: # events per day ndbh.fetch('select ts from tbl').all.map { |row| row[:ts] }.map { |t| t.strftime('%Y-%m-%d') }.each { |day| days[day] += 1 } (yes this could be conciser) This is generally frowned on, and I'm sure everyone who likes having this style foo .map {} .select {} .blah {} will frown as well, but it's so much more visually appealing to me, coming from a C/perl background when I first encountered Ruby (many years ago). Funny how important syntax is. So easy to look at code in another style/language and go THATS NOT RIGHT!!
    - strkek 9y ago
      > Funny how important syntax is. So easy to look at code in another style/language and go THATS NOT RIGHT!! I'm waaay too picky in this aspect. I once was reading about Ada (before my bias towards C-like languages kicked in). It looked interesting and all, and I was like "Hmm, not bad, learning this might be interesti--" > Put_Line Nope. The irony here is, my current language of choice is Go, and tests must be named like `TestType_Method` and I'm like "arrrgggghhh". EDIT: Btw I don't really mind indentation styles, brace placement, "dot placement" (like your example) and those things, as long as they're consistent across the codebase.
- pessimizer 9y ago
  > "more modern" Is it really touted as that? It's just a more Algol-looking way to write for Erlang semantics.
  - eric_the_read 9y ago
    It's more than that; there's a lot of tooling and documentation around Elixir that either doesn't exist in Erlang or appears to exist only via tribal knowledge ("Well, of course everyone knows you need to {X} to {Y}, why waste time writing it down?"). My experience trying to write a gen_server that could be upgraded on-line in Elixir was vastly simpler than trying to figure it out in Erlang. That said, I think Elixir has helped inspire the Erlang community to get better at documentation and tooling, so that's a definite win for both.
  - bitwalker 9y ago
    The other reply mentioned tools and documentation, which are the big differentiators in my opinion, but there are also some language level tools in Elixir which feel more "modern" I guess, the macro system which is on part with Lisp, protocols, a consistent standard library which extends Erlang rather than replacing it (although it does duplicate some things, both because binaries are the default string type in Elixir, and because OTP has a bit of an annoying problem with switching the position of the subject), and some conveniences like pipelines, the `with` construction - basically it produces something which semantically is like Erlang at its core, but how you go about solving problems in it offers a lot more options, which oftentimes result in a lot less code written for the same effect.
pratikkonnur 9y ago
We dabble in Akka - a good option for Java / Scala shops
- WorldMaker 9y ago
  There are ports of Akka and Akka-like libraries for a number of languages. Actor frameworks are relatively easy to find for most languages. Another variation of a sort of an Actor framework that gets used for relatively large projects is the Orleans framework for .NET: http://dotnet.github.io/orleans/ http://dotnet.github.io/orleans/
Cthulhu_ 9y ago
How does it compare to Go channels? I only know actors from Scala, Go felt similar but more er, simple?
- sudhirj 9y ago
  Simple to fault, in that channels and Goroutines don’t prevent you from making mistakes the way actors do - ie you can still share state and memory. Go allows for the possibility of writing cleanly concurrent code, but you must study and practice. Using an actor system, though, involves a bit more study with regards to setting things up, but it’s almost impossible to make mistakes - actors simply can’t access each other’s state (maybe some systems allow it, but you’ll have to struggle against the language to make that mistake).
  - macintux 9y ago
    Erlang does a great job of protecting data from concurrency problems, but you're still vulnerable to mistakes like deadlock.
    - signa11 9y ago
      > Erlang does a great job of protecting data from concurrency problems, but you're still vulnerable to mistakes like deadlock. without any shared data, and an asynchronous-message-passing style concurrency (i.e sharing memory by communicating, as opposed to communicating by sharing memory) can you please elucidate how we might get into deadlocks ? thanks !
      - macintux 9y ago
        OTP offers two basic messaging options: async or synchronous. The latter is implemented by forcing the caller to wait for the response. If process A sends a synchronous message to B, and B while processing it sends a different synchronous message either directly to A or to another process that eventually calls back to A, you end up in a deadlocked state.
nickbauman 9y ago
I'd argue the most interesting problems are those that end up having some sort of shared state requirement. Clojure handles this nicely with language primitives like atoms and refs, which helps avoid the pitfalls of the locking paradigm found in Go and Java, for example. What does D do in this case, then?
- earenndil 9y ago
  There are the basic primitives found in c/any language, but there are also synchronized{} (or synchronized (my_mutex) {}) blocks that essentially automagically handle locking/unlocking and let you just mutate around willy-nilly across threads (in that block). There are also atomics, although the syntax for using them is a bit clumsy (foo.atomicOp!"+="(7), anyone?).
nkim12 9y ago
rust has actors too https://github.com/actix/actix https://github.com/actix/actix
- eikenberry 9y ago
  Libraries aren't the same as native support as the latter case influences all uses of concurrency in a language while the former only affects things that use that library and may be incompatible with other concurrency libraries.
  - zokier 9y ago
    That seems kinda fallacious. I don't think inherently there is anything that would make an ecosystem around a library weaker than an ecosystem around a language. I.e. if you have a popular actor library then it is not unreasonable to think that there is as rich if not richer ecosystem of things built on top of that library than a niche language with native actors.
syeaj 9y ago
Would any sort of actor model language have the raw throughput for a AAA game? I get how this model is nice for the web, for example, but I'm wondering why it doesn't get used for high performance computing (that I know of).
- macintux 9y ago
  The Erlang VM (BEAM) is unusual in that it, like the languages it hosts, is very opinionated. It is designed for robustness, scalability, concurrency, distributed environments. And immutable data. So far as I know, you literally cannot implement a language with mutability on the VM. So, raw performance will never be its thing. In general, I think the actor model could achieve high performance, but perhaps only if messaging is syntactic instead of truly distributed with mailboxes, network transparency, etc.
  - mapcars 9y ago
    >So far as I know, you literally cannot implement a language with mutability on the VM. Elixir allows reassignment, of course, in the end, it uses different "Erlang" variables, but the language abstracts it.
    - macintux 9y ago
      Changing an alias isn't the kind of mutability that would allow high performance, though.
    - masklinn 9y ago
      That is not mutability.
      - erikpukinskis 9y ago
        It is though. A mutable state layer written on an immutable backend still has all the pitfalls of a native mutable data structure.
defined 9y ago
Erlang does go way beyond concurrency into the domain of distributed and highly-reliable systems, and has more than lessons for us IMO - together with OTP, it’s still arguably one of the most effective and battle-tested environments for highly concurrent systems. Like anything, it has its envelope and sweet spots, as well as its warts. Some people find the Erlang language syntax to be ugly; I quite like it and find it easier to comprehend in general than Elixir, which is much more verbose to my eyes (except for the very nice pipe operator!) Yes, the semicolon / period thing in Erlang can be annoying, but not so much that it really gets in my way. The tooling can be a real barrier to entry, and I’m glad that Elixir is bringing more people into the fold, although I can’t bring myself to really like Elixir for purely subjective reasons. For example, one of my major complaints about Elixir is that it is literally Erlang with some syntax changes, rewritten libraries, and extensions like macros - but if you don’t grok Erlang thoroughly, you will get frustrated when you hit the bottom layer - like exceptions and error messages - and it’s full of Erlang data structures. I had the same reaction when working with non-Java languages targeting the JVM. They all feel a bit like bolt-on kits. At some point, you really need to understand the core. In my opinion, of course.

athenot 9y ago

I'm a big fan of Erlang—and believe it's a useful language to know even if the daily language is something else—but my understanding of D is that it excels in a different problem space (build efficient native code, etc.)

elsurudo 9y ago

Important to point out Elixir as well, which is touted as a "more modern" way to write code that runs on the Erlang VM (so you get the same concurrency features, etc.)

strkek 9y ago
The _only_ downside I find of Elixir is that it looks too Ruby-ish to my taste. I'm still waiting for the day a C-like language that runs on BEAM becomes mainstream enough.
- StavrosK 9y ago
  Here's my thought process while reading your comment, which illustrates why we can't have nice things: > The _only_ downside I find of Elixir is that it looks too Ruby-ish to my taste. Yeah, preach it! > I'm still waiting for the day a C-like language that runs on BEAM becomes mainstream enough. Eww.
  - strkek 9y ago
    Haha yeah, I've become too used to C-like syntax (C, Go, Rust, etc). I wouldn't mind a Lisp syntax too, but Ruby and ML are definitely a "no" from me. I just can't bring myself to like them. Their syntax feels too "loose", not sure if that makes sense. Btw, I know there are some Lisp-like implementations out there, but same criteria applies: still not mainstream enough as of now.
    - StavrosK 9y ago
      No, I agree with you completely, I'm just remarking on how everyone will have different aesthetics and things they're used to, and, ultimately, that might not be a valid complaint. Like, sure, I don't like Ruby's syntax much, but if the ecosystem is good and the language is a joy to write, eh, I'm going to compromise because you can't please everyone's subjective preferences.
    - krick 9y ago
      Could you clarify, what's wrong with the Ruby syntax, exactly? I don't think there's a single programming language I like in terms of the syntax, but I don't see anything really wrong with Ruby. Surely not to the point I wouldn't use otherwise nice language because of it. Is python a no-no as well?
      - heavenlyblue 9y ago
        He thinks the syntax doesn’t “pop”, clearly.
      - strkek 9y ago
        It's not "wrong"; it just doesn't appeal me. - `elsif` - `end` - `unless` - `a unless b` - `f 1` vs `f(1)` - Implicit method calls (`f` vs `self.f`). I know both have different behavior, I just don't like this "implicit self". ... etc. I find Python okay-ish though, as paradoxical and nonsensical as that might sound. But in my toolchain Python has been reduced to little more than a calculator, since it's been replaced by Go for most of my automation needs. Btw, friendly reminder that this is my subjective opinion regarding my own tastes, not absolute truth on aesthetics. EDIT: Formatting.
        mercer 9y ago
        Speaking for Elixir, a few notes: I rarely find myself using if/else statements and I definitely avoid 'unless'. One of the 'Rubyisms' I really disliked was the optional parentheses for method calls. While these are still optional for good reason, in practice this is no longer the case. The formatter will add parentheses and IIRC the compiler will give you a stern lecture too. Obviously taste is subjective, but I do agree it matters. I'd say if the Ruby-like syntax is what keeps you from trying Elixir, remember that's it's only skin deep and at least for me, the bad stuff is not really there compared to Ruby. Furthermore, the advantages of having a functional and 'lispy'/homoiconic language that doesn't look like my bathroom floor after clipping my toenails is worth any remaining 'niggles' like the begin/end thing, or optional [] in the last parameter of a function call, etc. (which just like the optional parentheses is there for a very good reason).
  - erokar 9y ago
    I had the exact same reaction. > The _only_ downside I find of Elixir is that it looks too Ruby-ish to my taste. Granted. More ML-like would be nice. > I'm still waiting for the day a C-like language that runs on BEAM becomes mainstream enough. WTF!?
- ancarda 9y ago
  >I'm still waiting for the day a C-like language that runs on BEAM I used to have a similar desire! I actually started working on a language that transpiled to Haskell, like CoffeeScript -> JS. What I found, however, is a lot of little ways to make it more and more terse, until I ended up with something resembling Haskell’s syntax. After this happened several times, I had some new found appreciation for Haskell’s syntax. It’s god awful for someone coming from a C-like background, but that seems like a very temporary problem. I went from hating Haskell’s syntax so much I wanted a language wrapping it, to realizing it’s actually rather well thought out and other languages have a lot of noise to them. Lots of curly braces and semicolons that seem to mostly be there to make writing a compiler easier. I still love C-like syntax, and still don’t like Haskell’s syntax, but not enough to write a CoffeeScript-like language.
- jfhufl 9y ago
  Funny, I love Ruby and it's my primary language of choice, but I'm a heretic, using braces whenever I can: # events per day ndbh.fetch('select ts from tbl').all.map { |row| row[:ts] }.map { |t| t.strftime('%Y-%m-%d') }.each { |day| days[day] += 1 } (yes this could be conciser) This is generally frowned on, and I'm sure everyone who likes having this style foo .map {} .select {} .blah {} will frown as well, but it's so much more visually appealing to me, coming from a C/perl background when I first encountered Ruby (many years ago). Funny how important syntax is. So easy to look at code in another style/language and go THATS NOT RIGHT!!
  - strkek 9y ago
    > Funny how important syntax is. So easy to look at code in another style/language and go THATS NOT RIGHT!! I'm waaay too picky in this aspect. I once was reading about Ada (before my bias towards C-like languages kicked in). It looked interesting and all, and I was like "Hmm, not bad, learning this might be interesti--" > Put_Line Nope. The irony here is, my current language of choice is Go, and tests must be named like `TestType_Method` and I'm like "arrrgggghhh". EDIT: Btw I don't really mind indentation styles, brace placement, "dot placement" (like your example) and those things, as long as they're consistent across the codebase.
pessimizer 9y ago
> "more modern" Is it really touted as that? It's just a more Algol-looking way to write for Erlang semantics.
- eric_the_read 9y ago
  It's more than that; there's a lot of tooling and documentation around Elixir that either doesn't exist in Erlang or appears to exist only via tribal knowledge ("Well, of course everyone knows you need to {X} to {Y}, why waste time writing it down?"). My experience trying to write a gen_server that could be upgraded on-line in Elixir was vastly simpler than trying to figure it out in Erlang. That said, I think Elixir has helped inspire the Erlang community to get better at documentation and tooling, so that's a definite win for both.
- bitwalker 9y ago
  The other reply mentioned tools and documentation, which are the big differentiators in my opinion, but there are also some language level tools in Elixir which feel more "modern" I guess, the macro system which is on part with Lisp, protocols, a consistent standard library which extends Erlang rather than replacing it (although it does duplicate some things, both because binaries are the default string type in Elixir, and because OTP has a bit of an annoying problem with switching the position of the subject), and some conveniences like pipelines, the `with` construction - basically it produces something which semantically is like Erlang at its core, but how you go about solving problems in it offers a lot more options, which oftentimes result in a lot less code written for the same effect.

pratikkonnur 9y ago

We dabble in Akka - a good option for Java / Scala shops

WorldMaker 9y ago
There are ports of Akka and Akka-like libraries for a number of languages. Actor frameworks are relatively easy to find for most languages. Another variation of a sort of an Actor framework that gets used for relatively large projects is the Orleans framework for .NET: http://dotnet.github.io/orleans/ http://dotnet.github.io/orleans/

Cthulhu_ 9y ago

How does it compare to Go channels? I only know actors from Scala, Go felt similar but more er, simple?

sudhirj 9y ago
Simple to fault, in that channels and Goroutines don’t prevent you from making mistakes the way actors do - ie you can still share state and memory. Go allows for the possibility of writing cleanly concurrent code, but you must study and practice. Using an actor system, though, involves a bit more study with regards to setting things up, but it’s almost impossible to make mistakes - actors simply can’t access each other’s state (maybe some systems allow it, but you’ll have to struggle against the language to make that mistake).
- macintux 9y ago
  Erlang does a great job of protecting data from concurrency problems, but you're still vulnerable to mistakes like deadlock.
  - signa11 9y ago
    > Erlang does a great job of protecting data from concurrency problems, but you're still vulnerable to mistakes like deadlock. without any shared data, and an asynchronous-message-passing style concurrency (i.e sharing memory by communicating, as opposed to communicating by sharing memory) can you please elucidate how we might get into deadlocks ? thanks !
    - macintux 9y ago
      OTP offers two basic messaging options: async or synchronous. The latter is implemented by forcing the caller to wait for the response. If process A sends a synchronous message to B, and B while processing it sends a different synchronous message either directly to A or to another process that eventually calls back to A, you end up in a deadlocked state.

nickbauman 9y ago

I'd argue the most interesting problems are those that end up having some sort of shared state requirement. Clojure handles this nicely with language primitives like atoms and refs, which helps avoid the pitfalls of the locking paradigm found in Go and Java, for example. What does D do in this case, then?

earenndil 9y ago
There are the basic primitives found in c/any language, but there are also synchronized{} (or synchronized (my_mutex) {}) blocks that essentially automagically handle locking/unlocking and let you just mutate around willy-nilly across threads (in that block). There are also atomics, although the syntax for using them is a bit clumsy (foo.atomicOp!"+="(7), anyone?).

nkim12 9y ago

rust has actors too https://github.com/actix/actix https://github.com/actix/actix

eikenberry 9y ago
Libraries aren't the same as native support as the latter case influences all uses of concurrency in a language while the former only affects things that use that library and may be incompatible with other concurrency libraries.
- zokier 9y ago
  That seems kinda fallacious. I don't think inherently there is anything that would make an ecosystem around a library weaker than an ecosystem around a language. I.e. if you have a popular actor library then it is not unreasonable to think that there is as rich if not richer ecosystem of things built on top of that library than a niche language with native actors.

syeaj 9y ago

Would any sort of actor model language have the raw throughput for a AAA game? I get how this model is nice for the web, for example, but I'm wondering why it doesn't get used for high performance computing (that I know of).

macintux 9y ago
The Erlang VM (BEAM) is unusual in that it, like the languages it hosts, is very opinionated. It is designed for robustness, scalability, concurrency, distributed environments. And immutable data. So far as I know, you literally cannot implement a language with mutability on the VM. So, raw performance will never be its thing. In general, I think the actor model could achieve high performance, but perhaps only if messaging is syntactic instead of truly distributed with mailboxes, network transparency, etc.
- mapcars 9y ago
  >So far as I know, you literally cannot implement a language with mutability on the VM. Elixir allows reassignment, of course, in the end, it uses different "Erlang" variables, but the language abstracts it.
  - macintux 9y ago
    Changing an alias isn't the kind of mutability that would allow high performance, though.
  - masklinn 9y ago
    That is not mutability.
    - erikpukinskis 9y ago
      It is though. A mutable state layer written on an immutable backend still has all the pitfalls of a native mutable data structure.

defined 9y ago

Erlang does go way beyond concurrency into the domain of distributed and highly-reliable systems, and has more than lessons for us IMO - together with OTP, it’s still arguably one of the most effective and battle-tested environments for highly concurrent systems. Like anything, it has its envelope and sweet spots, as well as its warts. Some people find the Erlang language syntax to be ugly; I quite like it and find it easier to comprehend in general than Elixir, which is much more verbose to my eyes (except for the very nice pipe operator!) Yes, the semicolon / period thing in Erlang can be annoying, but not so much that it really gets in my way. The tooling can be a real barrier to entry, and I’m glad that Elixir is bringing more people into the fold, although I can’t bring myself to really like Elixir for purely subjective reasons. For example, one of my major complaints about Elixir is that it is literally Erlang with some syntax changes, rewritten libraries, and extensions like macros - but if you don’t grok Erlang thoroughly, you will get frustrated when you hit the bottom layer - like exceptions and error messages - and it’s full of Erlang data structures. I had the same reaction when working with non-Java languages targeting the JVM. They all feel a bit like bolt-on kits. At some point, you really need to understand the core. In my opinion, of course.