Thanks for the feedback.
> What's exactly novel about all this?
See the dissertation, which I successfully defended :-) Less flippantly, the novelty is in the failure handling and the communications mechanism.
> I see an untyped(!) DSL to model actor supervisor hierarchies, including a protocol which allows the actors to access some shared mutable state.
There are multiple levels of language here: the DSL for describing system services and supervision is untyped, in the same way as systemd, sysv init, Erlang's supervision hierarchies, and many (all?) others are.
The interactions among actors is also untyped. I'll discuss this a bit more below.
The way an actor makes use of the interaction machinery, however, is as typed as the host language itself. The TypeScript and Rust implementations are statically typed at the level of individual actors.
> NIH
Is there something specific you have in mind here? I'd like to hear about it. I think most of the choices I've made that seem NIHish are defensible, but if I'm wrong, I want to know about it, because it's always nice to be able to not implement something and to reuse something else instead.
> From a systems architecture point of view this looks actually very good, but all the details are more or less standard stuff found in industry products since quite some time.
This is not true. It's in the details where the novelty is. (And, the hypothesis goes, that the specific details chosen make it easier to get a good architecture without heavy effort.)
> But it's engineering, not research to me.
Do take a look at the project proposal, https://syndicate-lang.org/projects/2021/system-layer/, which lays out a research question and so forth. I am sympathetic, though, since I have a hard time seeing the dividing line between engineering and research when it comes to systems work myself.
> The other thing is, all hard problems, there where the "fun" starts, seem actually unsolved. Form the end of the dissertation defense slides:
So I defended at the end of 2017. Since then there has been a lot of progress!
Enhancements to the formal models
- types; names; grouping & relaying; formal properties
Regarding types, my colleage Sam Caldwell has been exploring various kinds of dataspace-specific type system:
https://www.cambridge.org/core/journals/journal-of-functiona...Regarding grouping and relaying, the Synit project has made a solid contribution to the
relaying part, and I'm currently investigating the grouping part further.
Regarding formal properties, nothing yet has been done.
System model
- performance; tool support; generic protocols; process management;
stdio; contracts; security; persistence; polyglot
Performance is now more than 30x better than the research prototypes of 2017. Performance is now "good". (Faster than DBus, for what it's worth ;-) )
Tool support is improving, though slowly, because it's mostly just me working on it. There's TypeScript language support, for example, making programming with Syndicate in TypeScript relatively ergonomic in vscode, emacs etc.
Generic protocols, process management, stdio, polyglossy: Synit has made a solid contribution here.
Contracts: investigation of gradual behavioural type systems should lead to interesting results here.
Security: Synit and improvements to the SAM have introduced
object capabilities (with a unique twist for incorporating assertions).
Persistence: I'm actively working on this right now.
Distributed systems
- unpredictable latency & scheduling; message loss; subnets
Needs more investigation. The relaying that Synit has introduced is a big step toward getting a good handle on this.
> I'm not sure this is actually easy to solve.
Well no, it's genuinely tricky.
> The basic idea here seems to be that actors coordinate with the help of shared mutable state (the "dataspace"). At this point you're actually back to square one as synchronizing shared state is the core problem with distributed, concurrent systems…
No: please go look at the dissertation some more. The key difference between simple mutable state or tuplespaces and the Syndicate idea of dataspaces is the way they handle failure and the kind of eventually-consistent synchronization model they offer. TL;DR is Syndicate's "shared" state is the logical sum of assertions placed in the space by its members, so retractions (or crashes) are handled by re-computing (or incrementally updating) this sum and propagating changes downstream.
> Given that, and the fact that this whole thingy is untyped makes me skeptical. Not even the std. ingredients like type-state, session types, behavioral types, or the like seem to get used. I also don't see linear types here, which go very well with session types / behavioral types, and can help making typing message passing easier.
These are all open research areas. I'm not sure they qualify as "standard" yet. That said, all these approaches are worth investigating in a Syndicated Actor setting. Except perhaps linearity, which doesn't readily apply.
> Also that this approach would be completely network transparent, as I see it, seems like a design flaw. One needs control over the various effects that can occur! Otherwise the points form "distributed systems future work" can't be solved, imho.
I don't understand your point here. There's no network transparency in the traditional sense here; rather the opposite! Local interactions are presented as if they were potentially remote.
> And form the practical point of view: There is no Akka / Pekko based Scala implementation? I'm quite surprised, to be honest.
I'd love to see such a contribution, if you're interested! Akka is a solid system, of course, but its goals and properties are quite far from the kinds of things Syndicate is aiming for. Producing a Syndicate for Scala could be interesting, though.
> Syndicate-lang looks OTOH more like the usual callback-hell.
Heh well ok. Take a look at the way facets structure conversations. It's actually remarkably close to "structured concurrency". https://syndicate-lang.org/tonyg-dissertation/html/#x_2_5_0_...
> (BTW: Very nice web-site design on all the projects. Especially nice typography. Really enjoyed this part while clicking through this stuff.)
Thanks :-)