Comment by bad_user | Hacker News Reader

Comment by bad_user | Hacker News Reader

Parent Full thread

Doesn't work. There are fundamental differences between Haskell and Ruby, or between Java and Clojure, or between Scala and JavaScript.

Solutions written in these languages will look vastly different. Nobody is attempting the actor model in Haskell because the actor model is anti static typing, non-deterministic and there's nothing FP about it. You don't see the State or the IO monads in many other languages. Or type-classes and higher-kinded types for that matter. LISP macros are a language feature, not a runtime feature, so you can forget about interoperability. Ditto for Linq in .NET or for scala-async. ActiveRecord / ActiveModel has been a good idea for Ruby on Rails, but would be terrible in Scala. Garbage collection changes everything - for one, building immutable data-structure becomes something you can do. Etc, etc...

Point is, programming languages aren't equal and the universe of languages is not unidimensional. And how a library gets implemented is not orthogonal to the picked language.

I answered most of your other objections in a sibling comment, but to this:

> Nobody is attempting the actor model in Haskell because the actor model is anti static typing

People write servers in Haskell, no? Servers that speak to the internet? If so, they're writing actor-modelled programs; each actor is just an entire OS process.

Now, if you want to write several servers at once, and have them scheduled efficiently, you might want a DSL that allows you to write specify the code for several Haskell server processes, and also specify their relationships. Sounds like you're going to be writing some actor-modelled code!

Which is all to say, Haskell (and strongly-statically-typed FP et al) works perfectly fine as a language for specifying what goes on within an actor.

The actor boundary is precisely where the tradeoff between static typing and dynamic typing is made, because when you want to communicate between actors (where an actor may also represent a socket or somesuch), you have to stop speaking in terms of typed data, and start speaking in terms of pattern-matching on binary messages that a given version of an actor might not recognize the totality of.

Haskell could have actors. Erlang could have strong-typing within functions. Both languages would basically look like they're embedding the other by doing so. The right solution probably involves exactly the kind of mixing of semantics that that sounds like.

No, that doesn't make sense. What you're talking about is not the actor model.

Sure it is -- actor model is an is an abstraction of software behaviour. Web services can be modelled as such.

Reply on news.ycombinator.com