These notes definitely seem like a useful reference, although I wish the author spoke more about what it was they were trying to accomplish. As someone with only a cursory familiarity with Lasp I've been hoping to see some applications that put its characteristics to use.

The post was intended as a reference and not an introduction, the docs on Lasp provide a good introduction: https://lasp-lang.readme.io/docs/what-is-lasp

Very nice. Thanks for sharing!

I like all the steps shown and the extra comments with output values and explanation of what's going on.

One question -- saw that all update operations take self() as an argument. In the code saw it was the "Actor". Is that always a pid of the calling processes or can it be anything like an integer or a reference. If this whole thing was running in a server would that be the ID of the client or still be generated locally on the server from the process running the request.

It kind of seems like there could be another layer or something on top of that to simplify it even further?

That's a lot of boilerplate to get and set a variable.

hi, I don't want to reply for cmeik (creator of Lasp), but I think eventually Lasp will be its own language.

from the github repo: "Prototype implementation of Lasp in Erlang"

Elixir's reasonably popular these days and it'd be easy to call this from that. The magic is all in the algorithms and communication protocols, I don't see how a different language really helps things too much.

Actually... thinking about it, I would hope that it'd be fairly language neutral if you really wanted it to grow.

Your device, running some Go code that talks to SQLite as well as a server running in Java could still use the same data structures and communication protcols... right?

Let me be that dumb guy at the party that will ask: what exactly is "planetary scale application" supposed to mean? Search engines seem to fail finding a definition.

It's a bit of a silly tagline.

The idea with CRDT is to define some data structures and operations on them so that it's possible to update the data structure in a concurrent environment with potentially conflicting updates which then end up being merged automatically.

For example, take a set and the operation of updating it. Say I am in Australia and you are in US and we are trying to operate on a shared set S. We both have local versions of it on our servers and our servers replicate with each other.

Maybe I add an item x to it and you pretty much at the same time add an item y. For a short while my version of the set will be S={x}, yours will be S={y}. Then after say 250 msec I'll see your changes and you'll see my changes we'd both have S={x,y}.

Notice how time didn't really figure out in the operation, and the order didn't matter -- you could have updated your version first or I could have updated mine first, but we'd both end up with the same result. And even better, we didn't have to manually resolve a conflict. Also you could have been on Neptune and I could have been on Mercury, it would have still worked but taken longer to replicate, maybe 6 hours or something like that.

PS: Mathematically this is related to https://en.wikipedia.org/wiki/Semilattice

"Lasp is about writing correct distributed programs.

The goal of Lasp is to allow you to write a program once and know that it will behave the same whether it is executed on one computer or distributed across many."