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

https://hexdocs.pm/gleam_stdlib/gleam/list.html

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.

https://github.com/mypalmike/RetrAction

There just needs to be a script version, and people will really get confused.

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.

[1]: https://acton.guide/types/intro.html

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.

    message := "hello world"

    # some fictional function I just came up with
    def install_requirements(dependencies, opts):
        run_setup(dependencies, opts)
        return assert_requirements_installed(dependencies)

    message = "hello world"

    # some fictional function I just came up with
    def install_requirements(dependencies: set[str], opts: dict[str, str]):
        run_setup(dependencies, opts)
        return assert_requirements_installed(dependencies)

In case you're not aware, Elixir is in the process of implementing gradual set-theoretic types.

https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

It could be both if all types are inferred.

It's unclear from a brief skim of the documentation what the story is around memory safety in Acton.

Pony uses object capabilities in its stdlib, but its real value proposition is reference capabilities that provide memory safety at compile time.

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...

It's not currently pluggable but there are quite few interaction points between RTS & DB so I imagine it could be done relatively easily. Depending on what you want to do, this might work well or become ultra-slow ;) Acton persists the execution of individual continuations (like actor methods but chopped up at every I/O point), so if you write functions in certain ways, you end up with many commits and if the database is not super fast, this can become a real chokepoint.

There are design for how to improve this in Acton through batching and asynchronous commits.

I read the main feature to be durable storage or in other words persistent actors. Erlang Term Storage (ETS) I thought was in-memory.

I think a lot of these things sort of come-for-free when you are an actor based language. Like actors are basically little processes communicating with each other, so you've mostly already abstracted away from memory pointers on your local machine, thus, it's trivial to move an actor to a remote computer but continue communicating with it in largely the same fashion. Clearly you need to be wary of latency but otherwise it looks about the same. Actors are single-threaded and have their own private state, so upgrading an actor is "just" replacing old code with new code but the same private data. You don't have to synchronize this access with other threads or similar. Actors just make this easier, which is why you'll probably find such features in languages using actors.

Acton has its own run time system though which shares much more with Pony than with BEAM. Pony folks wrote a paper on distributed computing with actors - https://www.doc.ic.ac.uk/~scb12/publications/s.blessing.pdf

I assumed given Wayland and Weston exist that Acton was named after yet another small town in metrowest Massachusetts.

Curiously the claim sounds like learning this programming language is equivalent to reading the whole DDIA book. :P

Elixir is pretty easy

Yes, it does affect the local control flow. If you don't assign the return value, then the local actor will proceed execution of the next thing, so effectively async execution of the remote method call. You can also write this explicitly like so:

    async remote_actor.foobar()

If you on the other hand want to wait for that remote actor to finish but still not assign locally you can use a dummy variable:

    _ = remote_actor.foobar()

or explicitly ask to await

    await async remote_actor.foobar()

You can also explicitly ask for async while grabbing the return value, which makes it easy to run things concurrently

    a1 = async remote_actor1.foobar()
    a2 = async remote_actor2.foobar()
    print("a1 and a2 run concurrently")
    r1 = await a1 # collect both results
    r2 = await a2
    print(r1, r2)

Return value is not needed, so just "call away" -- asynchronously.

I guess this means when a return value is used, the call is synchronous, and after running the method processing resumes where things left off.

    a = await async remote_actor.foobar()