3 ms·

I was curious about the opposite: What does this offer on top of Erlang? Is it just a new syntax for effectively the same language? IMO, the pure operator prec

I was curious about the opposite: What does this offer on top of Erlang? Is it just a new syntax for effectively the same language? 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...

kll 2y ago
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.
whalesalad 2y ago
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.
- kll 2y ago
  It is not ERTS / BEAM. Acton has its own run time system. Acton code is compiled to C functions, so the execution of functions look quite different between BEAM and Acton RTS. Acton has a Pythonic syntax but is NOT Python, so there is no GIL - quite the contrary, the Acton RTS runs actors concurrently. I'm afraid that Acton in itself won't teach "how to architect systems on actors". I do wholeheartedly relate to the challenge. It's not easy to switch and think "natively" in a new paradigms. Go try it out, do Advent of Code in Acton and see how it feels ;)
seivan 2y ago
[dead]

kll 2y ago

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.

whalesalad 2y ago

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.

kll 2y ago
It is not ERTS / BEAM. Acton has its own run time system. Acton code is compiled to C functions, so the execution of functions look quite different between BEAM and Acton RTS. Acton has a Pythonic syntax but is NOT Python, so there is no GIL - quite the contrary, the Acton RTS runs actors concurrently. I'm afraid that Acton in itself won't teach "how to architect systems on actors". I do wholeheartedly relate to the challenge. It's not easy to switch and think "natively" in a new paradigms. Go try it out, do Advent of Code in Acton and see how it feels ;)

seivan 2y ago

[dead]