Does anyone know of languages that are built aroun...
# thinking-togethern
Nick Smith
08/12/2019, 7:16 AMDoes anyone know of languages that are built around event-driven concurrent transactions on shared state? It sounds like I'm just asking for a database engine, but I'm looking for something more general purpose. Take the OO concept of "everything is an object" and change it to "everything is a transaction" as a starting point. Supporting concurrency is the key thing here, otherwise I would be basically describing an actor (whose execution is not individually concurrent).
g
Gary Trakhman
08/12/2019, 12:48 PMlasp comes to mind: https://lasp-lang.readme.io/
👍 1
i
Ivan Reese
08/12/2019, 2:53 PM
Maybe.. Tuple Spaces?
👍 1
Ivan Reese
08/12/2019, 2:53 PM
n
Nick Smith
08/17/2019, 6:25 AMI watched a video on Lasp but nothing about it really stuck out to me.
Nick Smith
08/17/2019, 6:25 AM@Ivan Reese I'd forgotten about tuple spaces! I'm putting them back on my reading list.
Nick Smith
08/17/2019, 10:24 AMI've realised that this approach to writing programs (transactions on shared state as opposed to message passing) is also heavily pushed within the Clojure community (though Clojure isn't event-driven by default). See: https://clojure.org/about/state
Nick Smith
08/17/2019, 10:27 AMThough more recently, Clojure's core.async library goes against this grain with a message-passing architecture.
i
Ivan Reese
08/17/2019, 6:33 PM
core.async is a bit of an oddity. It was (IIRC) mainly the project of Tim Baldridge, who is no longer at Cognitect and no longer working on it. It was never properly finished, and has a bunch of bugs and shortcomings. I think there have been a handful of community projects that have done a better job at cracking the same nut.
I'm not sure that I'd describe it as message passing. It's CSP, which is a more specific thing. If you say that CSP is a form of message passing, then you might as well lump in the actor model and Pi-Calculus and a few other things, and at that point a lot of meaning has been lost. After all, the interesting thing in core.async isn't the messages & inboxes, it's the use of queues and the coordination mechanisms.
g
Gary Trakhman
08/19/2019, 2:07 PMTBH I think the early clojure concurrency stuff (refs, agents, STM) is near useless, just based on how many times I've reached for it on some complex clojure projects. I think it does attract a lot of people, but it's not really necessary for most work.
👍 1
Gary Trakhman
08/19/2019, 2:08 PMbut it checks the box of 'concurrent transactions on shared state'
n
Nick Smith
08/23/2019, 7:43 AM@Gary Trakhman Is that so? What constructs do you use when you want to write concurrent Clojure programs?
g
Gary Trakhman
08/23/2019, 2:18 PMcore.async for concurrent but not shared state
Gary Trakhman
08/23/2019, 2:20 PMatoms are generally fine for shared state in most programs, and even so, you're only ever using a handful. I've never done or had to use the transact across multiple refs STM thing. I did use agents once before core.async came along, but I think it's clearer to use core.async and an atom for that case.
Gary Trakhman
08/23/2019, 2:23 PMI think the more valuable concurrency tool is using immutable data structures by default, so you can write small-scale isolated code and reuse it effectively later in a concurrent context with no changes.
👍 1