Misty: A secure distributed actor language(mistysystem.com) |
Misty: A secure distributed actor language(mistysystem.com) |
The core philosophical problem with gleam is that it is trying to get rid of errors. Ok, well good luck with that.
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?
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://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
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.
Misty Programming Language - https://news.ycombinator.com/item?id=38820305 - Dec 2023 (47 comments)
Creator of JSON Unveils New Programming Language 'Misty' - https://news.ycombinator.com/item?id=38680087 - Dec 2023 (6 comments)
Doug Crockford's new programming language – Misty - https://news.ycombinator.com/item?id=38620026 - Dec 2023 (3 comments)
Misty: Programing Language from the Creator of JSON - https://news.ycombinator.com/item?id=38114122 - Nov 2023 (3 comments)
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.
> 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)
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
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.
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.
I mean, I'm at least tangentially in the target audience, as an enthusiast of programming language design, who is very fond of Erlang...
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.
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.