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.
Still a lot todo.
https://github.com/douglascrockford/Misty There's only the spec and parser yet: https://mistysystem.com/doc/road_ahead.html
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:
https://lobste.rs/s/r8vitn/misty_programing_language_from_cr...
https://news.ycombinator.com/item?id=38820305
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.
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...
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.
This says that the implementation cannot cede time slicing to the OS, therefore it would seem to necessarily occupy kernel space. Am I mistaken?
example of distribution please? couldn’t find
Tldr for erlang users?
> The Misty Programming Language is a dynamic, (...), secure, distributed actor language
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]).
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].
[0]: https://simon.peytonjones.org/haskell-cloud/
[1]: https://en.wikipedia.org/wiki/Choreographic_programming
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
[1]https://gleam.run/
[2]https://inko-lang.org/