3 ms·

Indeed, an advanced static compiler could provide assurance against certain types of errors. Generally, I think compilers should do as much work as possible, be

Indeed, an advanced static compiler could provide assurance against certain types of errors. Generally, I think compilers should do as much work as possible, because people are slow and prone to error. Having said that, I know of no language that offers concurrency via the actor model – which is easy to reason about – fault tolerance, advanced static typing and distribution out of the box, all at the same time. Thus, I'm wiling to forgo the static typing, in favor of all other features.; no to mention other cool Elixir/Erlang features such as live runtime introspection and tracing, hot code reloading, the OTP, excellent multicore support, and soft-realtime capabilities due to preemptive scheduling and per process garbage collection. And btw, people have written large systems in languages less stricter than Elixir – e.g. Python, Ruby, etc - thus I think large codebases in Elixir should be fine.

Zalastax 8y ago
My Master's Thesis is about this topic! The related works section mention some languages that get fairly close to being actors with types (e.g. Pony), but you're right that we're not there yet. The tricky thing is that we need types that evolve as messages are being sent - an actor might change behaviour when it receives a message. Academica is still figuring out the kinks of how to do that. My work assigns a static type per actor and my conclusion is that that's decent - but quite annoying to program with and without the guarantee of deadlock freedom. https://www.dropbox.com/s/lczrcqu2m9p6osv/Master_Thesis.pdf?dl=0 https://www.dropbox.com/s/lczrcqu2m9p6osv/Master_Thesis.pdf?...
- di4na 8y ago
  This is now my goto link to explain the problem to people that ask about it. Thanks for the links :)
  - Zalastax 8y ago
    That warms my heart!
- bjz_ 8y ago
  Oh lovely, will have to give this a read at some stage! I'd also be really interested in versioning, and upgrading a cluster over time, without bringing the whole thing down (like with Cloud Haskell). Would be super handy to be able to verify that your migration works first, before actually going ahead with it. I'd also love it if the types could be used in some way to make this kind of thing easier to reason about. Are you also aware of the work advancing in Akka Typed? After a number of iterations they made some modifications that made things simpler - not sure how it compares with your work though: https://doc.akka.io/docs/akka/2.5/typed/actors.html#relation-to-akka-untyped-actors https://doc.akka.io/docs/akka/2.5/typed/actors.html#relation...
  - Zalastax 8y ago
    It looks like they're on the right path! Seems pragmatic and usable. Personally I don't think Scala is the right tool for the job. Once we figure this out we should design a special purpose language - this is too complex to expose as a library (bad error messages etc.); and while we're experimenting I think Scala's type system is not expressive enough - we need dependent types. I hope to see someone continue in my spirits but based on "mailbox types for unordered interactions". Versioning, upgrading and errors are really difficult problems. I think it should be possible to do upgrades in a typed setting but it will not come easy. We'll need to start simple here, e.g. upgrades that don't change any types.
- mercer 8y ago
  That's great! I'd be very interested in anything else you put out on this topic in the future :).

Zalastax 8y ago

My Master's Thesis is about this topic! The related works section mention some languages that get fairly close to being actors with types (e.g. Pony), but you're right that we're not there yet. The tricky thing is that we need types that evolve as messages are being sent - an actor might change behaviour when it receives a message. Academica is still figuring out the kinks of how to do that. My work assigns a static type per actor and my conclusion is that that's decent - but quite annoying to program with and without the guarantee of deadlock freedom. https://www.dropbox.com/s/lczrcqu2m9p6osv/Master_Thesis.pdf?dl=0 https://www.dropbox.com/s/lczrcqu2m9p6osv/Master_Thesis.pdf?...

di4na 8y ago
This is now my goto link to explain the problem to people that ask about it. Thanks for the links :)
- Zalastax 8y ago
  That warms my heart!
bjz_ 8y ago
Oh lovely, will have to give this a read at some stage! I'd also be really interested in versioning, and upgrading a cluster over time, without bringing the whole thing down (like with Cloud Haskell). Would be super handy to be able to verify that your migration works first, before actually going ahead with it. I'd also love it if the types could be used in some way to make this kind of thing easier to reason about. Are you also aware of the work advancing in Akka Typed? After a number of iterations they made some modifications that made things simpler - not sure how it compares with your work though: https://doc.akka.io/docs/akka/2.5/typed/actors.html#relation-to-akka-untyped-actors https://doc.akka.io/docs/akka/2.5/typed/actors.html#relation...
- Zalastax 8y ago
  It looks like they're on the right path! Seems pragmatic and usable. Personally I don't think Scala is the right tool for the job. Once we figure this out we should design a special purpose language - this is too complex to expose as a library (bad error messages etc.); and while we're experimenting I think Scala's type system is not expressive enough - we need dependent types. I hope to see someone continue in my spirits but based on "mailbox types for unordered interactions". Versioning, upgrading and errors are really difficult problems. I think it should be possible to do upgrades in a typed setting but it will not come easy. We'll need to start simple here, e.g. upgrades that don't change any types.
mercer 8y ago
That's great! I'd be very interested in anything else you put out on this topic in the future :).