An interesting project, but it seems to be in its infancy :)
I definitely want an actor based language to play with, and something with a strong type system would be perfect. gleam [1] and inko [2] look promising in this regard<p>[1]<a href="https://gleam.run/" rel="nofollow">https://gleam.run/</a><p>[2]<a href="https://inko-lang.org/" rel="nofollow">https://inko-lang.org/</a>
Curious if this overlaps at all with the use cases of the spritely project [1]. Another question is whether esoteric languages are strictly needed for these architectures or simply more convenient.<p>[1] <a href="https://spritely.institute/" rel="nofollow">https://spritely.institute/</a>
Still a lot todo.<p><a href="https://github.com/douglascrockford/Misty">https://github.com/douglascrockford/Misty</a>
There's only the spec and parser yet: <a href="https://mistysystem.com/doc/road_ahead.html" rel="nofollow">https://mistysystem.com/doc/road_ahead.html</a><p>Giving that he was at same state a year ago also, I see not much progress
A fair bit of discussion from a year ago:<p><a href="https://lobste.rs/s/r8vitn/misty_programing_language_from_creator" rel="nofollow">https://lobste.rs/s/r8vitn/misty_programing_language_from_cr...</a><p><a href="https://news.ycombinator.com/item?id=38820305">https://news.ycombinator.com/item?id=38820305</a><p>There are a few older discussions on HN, but none with more than single digit comments.
Regardless of the merits of the language itself, the presentation here leaves something to be desired.<p>The landing page itself conveys zero information, and when I click into the Introduction, it's almost entirely dedicated to a particularly persnickety whitespace standard, and the grammar rules for parsing comments and identifiers. This is not really helping me understand what the language is about...<p>Between that and the odd jab at Javascript assignment operators, I have the sense that the author is more interested in grinding axes than in explaining.
> The Misty Programming Language is a dynamic, (...), secure, distributed actor language<p>In this day-and-age, dynamic programs should be considered insecure (in the broad sense) by design. There have been lots of efforts in the past ~15 years to make distributed systems more robust (e.g. Cloud Haskell [0], choreographic programming [1]).<p>The term "secure" as used here is quite specific, used in reference to a capability model. This is quite nice and innovative. However, static typing and capabilities need not be mutually exclusive: capabilities can be modeled at the type level using algebraic effects [2].<p>[0]: <a href="https://simon.peytonjones.org/haskell-cloud/" rel="nofollow">https://simon.peytonjones.org/haskell-cloud/</a><p>[1]: <a href="https://en.wikipedia.org/wiki/Choreographic_programming" rel="nofollow">https://en.wikipedia.org/wiki/Choreographic_programming</a><p>[2]: <a href="https://github.com/yallop/effects-bibliography">https://github.com/yallop/effects-bibliography</a>