Hacker News Reader

Comment by zackmorris | Hacker News Reader

I'm late to the party but please for anyone reading this, look into the actor model. Shared mutable state quickly becomes unmaintainanble. It used to be slow to do shared immutable state but that's no longer the case. Today there are many better ways to do shared memory with copy-on-write so data is only copied if it's changed. Think back on history - there are only a handful of computation approaches that have stood the test of time. Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker. Had concepts from those programs made it into programming, our lives would be a lot simpler today. We don't need to torture ourselves for imagined efficiency by copying the C threading model that quickly dissolves into spaghetti.

View on HN

> there are only a handful of computation approaches that have stood the test of time. Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker. Had concepts from those programs made it into programming, our lives would be a lot simpler today.

Can you go into more detail on which concepts from Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker you're thinking of? My familiarity with the tools is leading to blindness about application...

Ya what I was trying to say for each of those is:

Pipes/streams: one way channels between isolated executables

Spreadsheets: the only form of functional programming that's reached mass adoption (equivalent to lisp for the most part)

DBMS: the only form of declarative programming other than the web that's reached mass adoption. In this case the view has two-way binding to the data, but relationships are declarative and the controller has been abstracted into the GUI and event callbacks on buttons etc (controller is the weakest portion of MVC)

All of these concepts could/should make it into mainstream programming languages. Try searching for Redux, Elm, software transactional memory, the Clojure state store, coroutines (which are interchangeable with state machines but without goto).

I believe that we can use all of these techniques without the ugly syntax of functional programming languages like Haskell, Scala, R, etc. For example Elixir is trying to be a kinder, gentler Erlang.

Hi Zach, I'm working on a implementation of the actor model for node, and since you mentioned it, I was wondering if you would perhaps be able to provide some feedback on it. Still very early days, but making some good progress on a single node implementation.

Ya sure, I could maybe take a look. I have to be honest though that I haven't used the actor model for a project yet. I just get a lot of leverage from its principles when I do shell scripting.

In Node I would be concerned about shared mutable memory. Just curious how you are isolating the actors? Or is that still in the todo stage?

http://akka-js.org

Akka port for javascript

The actor model is not the panacea it's often made out to be. (Though it's obviously better than shared-memory models for almost everything.). I'm sure you already know this, I'm just pointing it out explicitly.

For one, AFAICT very few implementations provide built-in back-pressure which is crucial if you want to avoid runaway resource consumption or having to just drop messages on the floor. This may not be critical for one's particular scenario, but it very often is for applications where you'd used threading and blocking queues (redezvous being a special case).

Reply on news.ycombinator.com