cmeiklejohn

More like "...we call it the simply typed lambda calculus."

Also, it remains unclear how you expect to support parametric polymorphism if you're assuming JavaScript as a base language for your analysis.

But, if you're assuming EsDoc, you're already inherently tied to JavaScript/TypeScript/etc, no?

Part of the point of the paper is assuming non-uniformity between APIs, hence the IDL.

Also, I have to sign up for stdlib? Do I have to pay for it? (Never got that far, and the fact I have to sign up is quite misleading for something called stdlib.)

We're trying to highlight that most of the work you're doing to make sure the interfaces are well defined and match up manually can easily be done by a type checker, as you would have if you wrote this as a single application.

To be clear, it seems you have basic coercions (a la C, or ad-hoc polymorphism) but no general support for subtype polymorphism nor parametric polymorphism.

Interesting.

I just went through this a bit and it doesn't appear that the specification allow for polymorphism in the type system. Am I missing something here?

If that's true, it doesn't seem to address the issues highlighted by the paper, although does handle simple type checking across interfaces of primitive types.

The entire point of CORBA was interop, so it's a bit absurd to say it wasn't actually needed, no?

Unfortunately, popular opinion disagrees and that's part of the motivation for this work.

Care to extrapolate? We tried hard to take industry use cases.

If you actually read the paper, we talk about ASN.1 and why it's insuffient for what we are doing. That's clearly stated, and it's clear you didn't read that paragraph.

Why sad?

To be fair, all modern RPC frameworks like Thrift, Protobuffs, etc. all use a IDL and it would be remiss to discount CORBA for this.

Just like RMI, CORBA was fine if you knew the boundaries where distribution started/ended. The issue with CORBA was the transparency and was apparent since NFS. If you used CORBA tastefully, it was fine.

Can you extrapolate on this?

As much as I disagree with CORBA, as highlighted by my publication history, it's clear in many cases it was very successful in industry in limited applications.

With the exception that these systems wouldn't have identified the type errors we highlight.

The Lasp programming system also has an eventually consistent key-value store built-in (and, we've scaled it to 1,024+ nodes).

Project home: https://lasp-lang.readme.io/docs

Results on scaling: https://arxiv.org/abs/1708.06423

Thanks for the feedback.

Good point.

But, most of the post was meant as joke to see what I could push lambda to do.

(committer on Antidote, Riak and Lasp)

We're investigating a backend that works on LevelDB and RocksDB. We just haven't had the academic resources to get it implemented yet. However, it's largely an engineering resource problem and not a theoretical problem.

See my comment above that you specifically replied to.

Lasp [in high-scalability mode] does not connect in a mesh, and the links I provided demonstrate that we do not connect in a mesh.

I specifically provided a link in the comment [with a link to an academic publication and a paper] you responded to about how we do non-full mesh and achieve 1000+ nodes.

Antidote only uses distributed Erlang inside of a single cluster limiting a single cluster to 100+ nodes. The multi-DC protocol is not based on distributed Erlang, and therefore, is not limited by distributed Erlang (but, is limited by other factors.)

Additionally, there are Riak Core modifications (authored by myself and others) that bypass distributed Erlang using the same semantics, and therefore, don't have the 100+ node cluster restriction.

And finally, the 100+ node cluster restriction is highly-debated, by myself and other academics, because the restrictions are based on use of the global module, where systems that don't use this module will experience higher scalability numbers (based on empirical evidence, not yet published.) For reference, Ericsson, has run 200+ node Erlang clusters.

(former Basho engineer and committer on Riak and Antidote)

No, it's not Riak.

[Full disclosure: work was started in 2013/2014, with Basho, as an alternative to Riak and shares Riak Core as a base. At the time, Basho was a member of SyncFree.]

It's built on Riak Core, but it's a lot different from Riak in many ways: no replication in the DC, transactions, more data-types, operation-based CRDTs and not state-based CRDTs, log vs. in-place replacement in the storage backend.

I mean, the analogy is poor: it's even less close than saying that Riak is Cassandra and vice-versa.

Ah, we might be pulling a branch for our Riak Core work. I can look into it tomorrow and get back to you.

I wouldn't say "better"; I'd probably say that the memory profile would be completely different. It all depends on the number of actors, the size of objects, and the workload. Remember: for large binary objects, references on a shared heap are sent and messages are not explicitly copied per actor. This means it's dependent on the workload and both the structure of how many processes are involved in a single request.

I suggest that you build on top of the Riak Core from Heinz Gies. That's what we are using in some of our new projects.

(committer on Antidote, author of Lasp, both SyncFree projects)

Antidote is designed for DC deployments, in the hundreds of clusters. It provides causal consistency and transactions.

Lasp is designed for high-churn, edge deployments (with CRDTs) and provides eventual consistency: it's designed for 1,000+ nodes.

They share a bit of code, and you might want to evaluate both to determine which is a better use case: Lasp might be a better fit for the IoT application, because it was designed for that.

Here's a HN post on Lasp's scalability:

https://news.ycombinator.com/item?id=15444156

Here's a HN post on Lasp:

https://news.ycombinator.com/item?id=14300763

(committer here)

It uses Riak Core as the underlying distribution layer, which is the same that Riak itself uses. For storage of the log, the built-in Erlang disk_log is used.

Further follow-up: we're (members of the SyncFree consortium and it's follow up project for moving CRDTs, Antidote, and Lasp to the edge) considering raising money to industrialize Antidote (and it's associated tool chain) for building Just-Right Consistency applications.

If you'd be interested in any of the above, or just using the database and/or trying the tools, reach out to me via email christopher.meiklejohn at gmail.com or cmeik on Twitter.

Here's links to other things in the SyncFree group.

Lasp (previously on HN):

https://news.ycombinator.com/item?id=14300763

https://news.ycombinator.com/item?id=15444156

SyncFree project review results:

http://cordis.europa.eu/result/rcn/197514_en.html

Legion:

https://syncfree.lip6.fr/index.php/2-uncategorised/54-legion

SyncFree homepage:

http://syncfree.lip6.fr