There's so little said about how it does what it does. The Github README says:
> The Acton Run Time System (RTS) offers a distributed mode of operation allowing multiple computers to participate in running one logical Acton system. Actors can migrate between compute nodes for load sharing purposes and similar. The RTS offers exactly once delivery guarantees. Through checkpointing of actor states to a distributed database, the failure of individual compute nodes can be recovered by restoring actor state. Your system can run forever!
> NOTE: Acton is in an experimental phase and although much of the syntax has been worked out, there may be changes.
I'd like a lot more info on how this checkpointing mechanism and discovery/communication works.
I tried using gleam for real work the other day and found myself really enjoying it. It's a cool language and surprisingly productive coming at it with no experience with OTP or the BEAM.
I know it's a me issue, but I got stumped by how inefficient it is to write code that handles linked lists in some cases. As far as I can tell, there's no built-in array or anything more convenient. I had to write a function to find items at indices, haha.
I looked through the docs and it seems like I'm not missing anything. I'm clearly too accustomed to web development
It's not just you, this is an issue with the BEAM platform itself. Singly-linked lists are the privileged sequential datastructure on the BEAM. I work in Elixir every single day and this is one of my pet peeves about the platform.
There actually are arrays [1] and ETS tables [2] that allow for fast random access and updates but they don't have first-class syntax in Erlang, Elixir, or (it seems) Gleam. They're just libraries, so you can't pattern match on them. And when it comes to the array datatype, approximately no one uses it. I don't think I've ever seen code in the wild that uses it.
I don't know why they don't build a first-class random-access vector datastructure like Clojure [3] that has a superset of BEAM's list functionality. I think at this point it's mostly just historical inertia: list has been there so long it would be a massive pain to change it.
Tuples are the BEAM's native arrays, but they're expensive to update, immutability means you (usually) have to copy the whole thing to update one index. Lists are a lot more common in functional languages.
If you really need random access you can use a map with integer keys. If you want to write numerical stuff, Elixir has Nx - not sure if it's usable from Gleam though.
for a second I thought it was a link to the "Action!" language which was a cool little language for the Atari 8bit computers back in the day, it came as a plugin cartridge...
I thought the same. Possibly because I recently wrote a compiler/interpreter for the Action! language. Not terribly useful in its current state, but most of the language is supported.
I was confused by that too. Under the "Types" page of the guide[1], they say:
> Every value in Acton is of a certain data type, which tells Acton what kind of data is being specified so it knows how to work with the data. Acton is a statically typed language, which means the type of all values must be known when we compile the program. Unlike many traditional languges like Java or C++, where types must be explicitly stated everywhere, we can write most Acton programs without types. The Acton compiler features a powerful type inferencer which will infer the types used in the program.
> Acton implements the Hindley-Milner (HM) type system, which is common in languages with static types, like Haskell and Rust. Acton extends further from HM to support additional features.
The language also has inheritance (and thus presumably subtyping), protocols (interfaces, I think), and generics. Historically, those features have not played nice with HM inference, so I'm not sure what's going on there.
Static: the types could be inferred. I haven't looked too closely yet.
Strong: Python is strongly typed with a similar syntax.
Strong vs weak typing means "how much information does the type system provide to me." Static vs weak typing means "when does the type system do its work."
I see no reason why a language with syntax like this could not be strongly typed. The static part is hard to claim until the type inference rules are explained.
I looked thru the docs assuming this might run on ERTS/BEAM but it doesn't seem so? Perhaps it is novel?
Personally I really struggle with Erlang syntactically. Elixir is a lot better... but I think Python is the king of syntax.
My biggest problem in life is actually not syntax related - it is "how to architect systems on actors". Writing modules/classes, the implentation, that stuff is really trivial for any decent programmer. The hard part to me is figuring out, how do I map my problem to these actors? How many supervisors do I have? Who supervises who? Transitioning from traditional RPC or process/thread based thinking to actor thinking has been hard for me. I yearn to understand it fully, but I have a block. You could perhaps say the same thing for languages like go and clojure who rely on channels for async communication. In some sense, you can consider a goroutine or a core/async function to be an actor, and the channel is an inbox (broad generalization here). The issues you face adjusting your thinking are similar.
This tool does not solve the aforementioned problem for me, that exists regardless. But I have long thought that Python with a distributed actor model and immutable datastructures that could circumvent the GIL would be the unstoppable language for building modern apps.
Acton has a different focus than Erlang. Beyond syntax, the type system is likely the biggest difference, both in how in feels to the developer as well as what it means for things under the hood. I think Acton, given static typing, can compile down to more efficient code than what you can ever achieve with Erlang. From this perspective, Acton is more in the same camp as Rust or Go. But where Go is a language built around CSP, Acton, like Erlang, is built around the actor model. So if you like actors but also like types, maybe Acton is for you :)
There's lots of work to get types into Erlang, but it's hard to bolt things on afterwards, which is why Acton is a language and not just an actor framework for X.
Readit News
> The Acton Run Time System (RTS) offers a distributed mode of operation allowing multiple computers to participate in running one logical Acton system. Actors can migrate between compute nodes for load sharing purposes and similar. The RTS offers exactly once delivery guarantees. Through checkpointing of actor states to a distributed database, the failure of individual compute nodes can be recovered by restoring actor state. Your system can run forever!
> NOTE: Acton is in an experimental phase and although much of the syntax has been worked out, there may be changes.
I'd like a lot more info on how this checkpointing mechanism and discovery/communication works.
I know it's a me issue, but I got stumped by how inefficient it is to write code that handles linked lists in some cases. As far as I can tell, there's no built-in array or anything more convenient. I had to write a function to find items at indices, haha.
I looked through the docs and it seems like I'm not missing anything. I'm clearly too accustomed to web development
https://hexdocs.pm/gleam_stdlib/gleam/list.html
There actually are arrays [1] and ETS tables [2] that allow for fast random access and updates but they don't have first-class syntax in Erlang, Elixir, or (it seems) Gleam. They're just libraries, so you can't pattern match on them. And when it comes to the array datatype, approximately no one uses it. I don't think I've ever seen code in the wild that uses it.
I don't know why they don't build a first-class random-access vector datastructure like Clojure [3] that has a superset of BEAM's list functionality. I think at this point it's mostly just historical inertia: list has been there so long it would be a massive pain to change it.
[1] https://www.erlang.org/doc/apps/stdlib/array.html [2] https://www.erlang.org/docs/23/man/ets [3] https://clojure.org/reference/data_structures#Vectors
If you really need random access you can use a map with integer keys. If you want to write numerical stuff, Elixir has Nx - not sure if it's usable from Gleam though.
https://en.wikipedia.org/wiki/Action%21_%28programming_langu...?
https://github.com/mypalmike/RetrAction
It would be really nice to have strong, static types. It's the only thing keeping me from learning Elixir, so this could be a nice alternative.
> Every value in Acton is of a certain data type, which tells Acton what kind of data is being specified so it knows how to work with the data. Acton is a statically typed language, which means the type of all values must be known when we compile the program. Unlike many traditional languges like Java or C++, where types must be explicitly stated everywhere, we can write most Acton programs without types. The Acton compiler features a powerful type inferencer which will infer the types used in the program.
> Acton implements the Hindley-Milner (HM) type system, which is common in languages with static types, like Haskell and Rust. Acton extends further from HM to support additional features.
The language also has inheritance (and thus presumably subtyping), protocols (interfaces, I think), and generics. Historically, those features have not played nice with HM inference, so I'm not sure what's going on there.
[1]: https://acton.guide/types/intro.html
Strong: Python is strongly typed with a similar syntax.
Strong vs weak typing means "how much information does the type system provide to me." Static vs weak typing means "when does the type system do its work."
I see no reason why a language with syntax like this could not be strongly typed. The static part is hard to claim until the type inference rules are explained.
https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
Doing some searches based on that, I enjoy/endorse the "natural progression" analogy in https://github.com/actonlang/acton/discussions/1400#discussi...
Pony uses object capabilities in its stdlib, but its real value proposition is reference capabilities that provide memory safety at compile time.
I.e. solves the two generals problem?
Does someone wanna offer up a different definition of either term, or do we file this alongside the CAP-beaters?
Edit: I was too quick to judge!
In addition to the above, you don't "give up consistency", you get "the speed of C" (with GC), and "exactly once message delivery guarantees".
IMO, the pure operator precedence syntax of Erlang is peak homoiconigraphy. I prefer that over syntactic sugar. But also I'm a fan of Prolog...
Personally I really struggle with Erlang syntactically. Elixir is a lot better... but I think Python is the king of syntax.
My biggest problem in life is actually not syntax related - it is "how to architect systems on actors". Writing modules/classes, the implentation, that stuff is really trivial for any decent programmer. The hard part to me is figuring out, how do I map my problem to these actors? How many supervisors do I have? Who supervises who? Transitioning from traditional RPC or process/thread based thinking to actor thinking has been hard for me. I yearn to understand it fully, but I have a block. You could perhaps say the same thing for languages like go and clojure who rely on channels for async communication. In some sense, you can consider a goroutine or a core/async function to be an actor, and the channel is an inbox (broad generalization here). The issues you face adjusting your thinking are similar.
This tool does not solve the aforementioned problem for me, that exists regardless. But I have long thought that Python with a distributed actor model and immutable datastructures that could circumvent the GIL would be the unstoppable language for building modern apps.
There's lots of work to get types into Erlang, but it's hard to bolt things on afterwards, which is why Acton is a language and not just an actor framework for X.
Dead Comment