Thread by @plajjan

I'd like to tell you about Acton, a programming language that I've been part of developing over the last couple of years.

"What? A new language? But why?"

I think you'll like it, so I'll try to explain... 🧵

The killer feature of Acton is that it provides for a distributed persistent programming environment. AFAIK, the way Acton does this is unique and a world first. I will get to details of that, but first an introduction to the Acton language in general.

At a first view, Acton looks a fair bit like Python. The Acton syntax is heavily inspired by Python and for good reason; we, the Acton developers, think that Python has a simple and elegant syntax. It allows its users to be productive and write high quality code.

Acton is however not Python. It could not be without also implementing the quirks and bugs of Python. No, Acton is pythonic, borrowing idioms and large parts of the syntax but it also extends beyond Python.

The most notable extension is that of the "actor" keyword, which hints about a key feature of Acton: it is based on the Actor model (Carl Hewitt) and as we will see, a great many good things emanate from the use of actors. But first, some other notable features of the language.

Acton, unlike Python, is a compiled language. Acton uses C as an intermediate representation, which is then compiled to a binary. This means Acton can be fast, like really fast. It also means we can detect more errors earlier (at compile time instead of run time).

Acton is statically typed with an advanced type system (Hindley / Milner, extended with Qualified Types, like Haskell). To avoid placing a constant overhead of dealing with types, the Acton compiler features a state of the art type inferencer.

This means you do not have to explicitly write out the types of your variables or type signatures of your functions (like in Java or C). Rather you let the compiler *infer* the types. You can enjoy the quality and robustness of static typing without the extra work!

Other languages does type inferencing too, but many of them have much lower aspirations when it comes to just what you can infer. The Acton compiler plays in the upper league, being able to infer more complex types and work in larger programs.

The combination of these features and characteristics alone are enough to make Acton unique and quite useful I think... but it doesn't stop there, let's enter the world of distributed systems!

The Acton Run Time System (RTS) offers a fault tolerant distributed mode of operation allowing multiple computers to participate in running one logical Acton system. Actors can migrate between compute nodes for failover and load sharing.

The RTS compute nodes communicate with each other through a distributed database. The inter-actor communication and the state of actors themselves is snapshotted to the database, which is what allows for resuming a failed actor as well as migration of an actor between computers.

You do not have to manually persist data to a database! Think about that for a moment. The state of an actor - your program - is seamlessly snapshotted to a database and is automatically restored as needed (after restarts / crashes / migrations).

The distributed database is written from scratch specifically for the Acton RTS and features lockless algorithms, quorum reads etc. Pretty cool!

The RTS allows for exactly once delivery. Failure of a RTS compute node means we can resume the actors that were running on that RTS and pick up from where they left off. Code upgrades (of your Acton program) can be done live on the running system. An Acton program is immortal!

Think of what this means for your program. You don't need to explicitly persist state information to a database. There is no need for a database ORM or similar. The state of your program itself is persisted! I think this is a game changer for how we write programs!

Many good things emanate from the actor concept; only private memory & message passing for isolation and simple and efficient concurrency. This enables snapshotting and persistence per actor etc. In a shared memory model language, you would end up snapshotting the entire program.

Now, Acton is young. We have worked on it for years but writing a programming language from scratch, at least of the magnitude of Acton, takes time. At first there was a prototype, backed by Python and Cassandra. Now it is reimplemented mostly in C, for dat true sp33d.

I like to think of Acton being roughly at the stage of those first SpaceX rockets. They crashed and they burned. Even though they failed, anyone could see the tremendous effort that must have gone into building them.

Running the acton compiler currently feels a lot like those crashing rockets. There's a tremendous amount of things that must work correctly in the compiler to produce a working program and many times it goes wrong, but sometimes it works and that gives a taste of what shall come

Acton is not quite ready for general use but if you're interested in programming languages themselves, I invite you to have a look. We need to build up a standard library of modules. If you like C and have opinions on (Python's?) standard library, tag along, it'll be fun :)

Even if you aren't quite as interested in the internals of programming languages, do remember the Acton name. Give it some time and I promise, you'll fall in love one day ❤ meanwhile, give it a star so you won't forget ;) github.com/actonlang/acto…

Wanna know more? AMA :)

Oh and of course, it is #Hacktoberfest now. Come hack on Acton! Many ways to contribute. Draw a logo! Write a web page! Pick a "good first issue" on GitHub! Join the fun!