Misty: A secure distributed actor language(mistysystem.com)
87 pointsby m906 days ago9 comments
  • evomassiny4 days ago
    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/

    • az09mugen3 days ago
      Another less-known actor based language is pony [0], it is well documented and made some uncommon choices.

      [0] https://www.ponylang.io/

    • linkdd4 days ago
      For the record, Elixir has been slowly introducing a set theoretic gradual type system.
    • throwawaymaths3 days ago
      fundamentally I think though is that for distributed systems you don't really want actors, you want ~erlang processes. The distinction being around how errors propagate between processes, and various mechanisms to deal with that. The actor model doesn't have any of that in its theoretical basis. Because in a distributed system you fundamentally have unpredictable errors, and generally erlang tries to shoehorn you into a programming style where you're ok with faults, which makes your system more fault tolerant.

      The core philosophical problem with gleam is that it is trying to get rid of errors. Ok, well good luck with that.

      • davexunit3 days ago
        Actor systems can handle unpredictable errors and if you watch a recent talk by Douglas Crockford about actors/Misty there are Erlang-like "let it crash" examples.
      • __MatrixMan__3 days ago
        I've been meaning to get to know gleam better, so I'm interested in your comment.

        Do you mean that the error handling of an Erlang process is in any way diminished by using gleam? Or is it just that maybe it's unnecessary work to try so hard to prevent errors which you've already put so much into tolerating?

  • openrisk4 days ago
    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.

    [1] https://spritely.institute/

    • davexunit4 days ago
      Douglas Crockford has described Misty as vaporware (hence the name), whereas at Spritely we are building and shipping things that can be used. Rather than build an entirely standalone domain specific language, our research and development builds on top of Scheme because it's a multi-paradigm language that is easy to extend to implement new paradigms (such as the actor model) thanks to the powerful macro system. Lexical scope and first-class functions make Scheme amendable to the actor model (Scheme was initially created as an exploration of the actor model) and capability security. For the latter, we are inspired by Jonathan Rees' W7: A security kernel based on the lambda calculus.

      http://mumble.net/~jar/pubs/secureos/secureos.html

      We are also involved in a cross-organization effort to bring capabilities to everyone (on the network, at least) called OCapN and we are seeking implementers for as many programming languages as possible.

      https://ocapn.org/

      • davexunit4 days ago
        I should clarify that when he calls it vaporware he means that he is interested in propagating the actor model concept rather than any specific language or implementation.
  • rurban4 days ago
    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

    • rahkiin3 days ago
      I just ticket the checkboxes on that page and now it is finished.
  • macintux4 days ago
    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.

  • swiftcoder4 days ago
    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.

    • WorldMaker3 days ago
      A similar presentation bug that stands out to me, the "Public Domain by Author" copyright claims are non-standard and don't actually do anything legally speaking in the US or many other world jurisdictions, and feel kind of silly/out-of-place. Maybe they are a political statement, but I think that just makes them more annoying, not less. This is why CC0 [0] exists and provides a ton of useful explanations and FAQ and suggestions on dedicating works to the public domain in a way that legally works/matters. Also as a reminder CC0 is not an OSI-approved code license and for that you should consider using something like CC0 "dual licensed" with "1-Clause BSD" [1] for software code. (Though CC0 is directly FSF approved now [and generally considered GPL family compatible], with suggested License verbiage in the CC0 FAQ.)

      [0] https://creativecommons.org/public-domain/cc0/

      [1] https://spdx.org/licenses/BSD-1-Clause.html

    • tossandthrow4 days ago
      > I have the sense that the author is more interested in grinding axes than in explaining.

      People are free to target whoever they want when publishing on the internet.

      There is a good chance that neither you nor HN is a part of that target.

      • bheadmaster4 days ago
        > People are free to target whoever they want when publishing on the internet.

        People are also free to criticize whatever is published on the internet. Hypotetically not being a part of the "target audience" doesn't preclude one form such freedom.

        I agree with the comment above: the introduction doesn't really "introduce" the reader to the language, it only introduces the reader to the syntactic constructs used in the language. Such introduction would better fit in the "specification" section.

      • swiftcoder4 days ago
        > There is a good chance that neither you nor HN is a part of that target.

        I mean, I'm at least tangentially in the target audience, as an enthusiast of programming language design, who is very fond of Erlang...

        • tossandthrow4 days ago
          It is the assumption that this is meant as dissemination. there is a lot of material online (especially on GitHub) that is not meant to be read.

          It is a valid criticism that it is uninteresting to read, but the core criticism is that this should not have been shared on HN, to which the canonical response is to scroll through and not upvote.

    • fasten4 days ago
      agreed the focus on whitespace rules and grammar feels misaligned for an introduction
    • mirekrusin4 days ago
      ...author is Douglas Crockford, creator of JavaScript and JSON.
      • thebestjames4 days ago
        Brendan Eich (of more recent Brave fame) is the creator of JavaScript.
        • mirekrusin3 days ago
          Thanks for correction, indeed I mixed him up, Crockford just created JSON parser and popularized this format (he also popularized js in general though his book, linter etc).
      • exe344 days ago
        to be fair, if $Y creates $X and $Y doesn't hate $X with a passion and doesn't come up with $Z that is a gazillion times better than $X, then $X is probably not very useful.
  • thyrsus3 days ago
    This says that the implementation cannot cede time slicing to the OS, therefore it would seem to necessarily occupy kernel space. Am I mistaken?
  • dustingetz4 days ago
    example of distribution please? couldn’t find
  • faraaz984 days ago
    Tldr for erlang users?
    • davexunit4 days ago
      Erlang actors are not privately addressable, so they cannot be used for capability security. The actors described here are.
      • withoutboats33 days ago
        Joe Armstrong goes to lengths to describe the benefits of "privately addressable" actors in his thesis (though he uses different terminology). As far as I'm aware, Erlang actors are also privately addressable. cf:

        > System security is intimately connected with the idea of knowing the name of a process. If we do not know the name of a process we cannot interact with it in any way, thus the system is secure. Once the names of processes become widely know the system becomes less secure. We call the process of revealing names to other processes in a controlled manner the name distribution problem— the key to security lies in the name distribution problem. When we reveal a Pid to another process we will say that we have published the name of the process. If a name is never published there are no security problems.

        > Thus knowing the name of a process is the key element of security. Since names are unforgeable the system is secure only if we can limit the knowledge of the names of the processes to trusted processes.

        https://erlang.org/download/armstrong_thesis_2003.pdf (page 24-25)

        • jerf3 days ago
          That may be what is in the thesis, but in real Erlang, any process can list all processes on any node it can reach: https://www.erlang.org/doc/apps/erts/erlang.html#processes/0 (As the docs say, it lists "processes on the local node" but I'm fairly sure any process can RPC that to any connected node to get the local processes on that node) From there you've got a lot of introspection on the processes in question.

          And beyond that, there is no sandboxing in Erlang that allows you to do anything like spawn a process that can't access the disk or network or anything like that. So in practice that doesn't even hardly buy you anything on a real system because if you were somehow running unauthenticated Erlang code you've already got access corresponding to the OS permissions of the running Erlang process. (Though for those not familiar with Erlang, "somehow running unauthenticated Erlang code" is very unlikely, to the point that it's not a realistic threat. I'm just speaking hypothetically here.)

          The thesis may cover how such systems could be turned to a more secure context but it does not correspond to current Erlang.

          • davexunit3 days ago
            There are many layers of capabilities. Unguessable process IDs would be necessary for network capabilities. A sandboxing environment would be necessary for system or process level capabilities. It's still worth having the network security even if process security isn't there. Very few language implementations can provide that level of security.
            • jerf3 days ago
              My point here is merely to make sure that people do not come away from this thread thinking that Erlang has, well, anything like this at all. It isn't an especially insecure language as it lacks most of the really egregious footguns, but it isn't a specially secure one either, with any sort of "capabilities" or anything else.
          • withoutboats33 days ago
            The IO aspect is not a surprising flaw but it's disappointing to learn that Erlang lets any process enumerate all the other ones.
        • SoftTalker3 days ago
          This really only works if the process names are unguessable? Erlang PIDs are if not predicatable at least appear to be guessable, e.g. they look like this: <0.30.0>
          • davexunit3 days ago
            Right, they would need to be unguessable to be used as capabilities.
    • Guthur4 days ago
      Continue to use Erlang. ;)
  • cosmic_quanta4 days ago
    > 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

    [2]: https://github.com/yallop/effects-bibliography

    • demosthanos4 days ago
      You can also model capabilities with the Object Capability Model—just pass the capabilities around as object handles. This has the downside of being rather verbose, but that can be remedied by something like Scala's implicits.