Introducing otavia: Your shiny new IO & Actor programming model!

Hi, here!

This project is still in the incubation stage, it took me about a year to complete the initial design and I currently have a working prototype. I am eager to receive your ideas, suggestions and even criticisms to improve the design of this project!

GitHub - otavia-projects/otavia: Your shiny new IO & Actor programming model!

Introduction

otavia is an IO and Actor programming model power by Scala 3, it provides a toolkit to make writing high-performance concurrent programs more easily.

You can get a quick overview of the basic usage and core design of otavia in the following documentation:

More document can be found at website

Features at a Glance

  • Full-Link Asynchronous:Everything is asynchronous, no blocking, no thread suspending.
  • Forget Threads, Forget Locks:You will no longer be plagued by multithreading problems; everything you write runs in a single thread!
  • Simpler Concurrent: Actors and Channel let you build systems that scale up, using the resources of a server more efficiently, and out.
  • Resilient by Design: Building on the principles of The Reactive Manifesto Otavia allows you to write systems that self-heal and stay responsive in the face of failures.
  • High Performance: build Millions actor instance and send many billion message in seconds.
  • Type Safe: Message send between actor is type safe in compile time.
  • Zero-Cost Ask-Pattern: Send ask message and get reply message like call a method, but zero-cost.
  • DI of Actor: An ActorSystem is also seen as a container for Actor instances, and developers can type-safely inject dependent Actors at compile time.
  • Powerful IO Stack: The IO stack is ported from Netty, but support AIO and file channel.
  • async/await: Implement async/await syntaxes based on the CPS (Continuation Passing Style)
    using Scala 3 metaprogramming tools.
  • Simple threading model: The threading model of the otavia runtime is very simple and efficient, allowing you to maximize the utilization of your system’s CPU!
  • Zero-Deps: The core modules does not depend on any third-party packages.
  • Open Ecosystem: Otavia provides a module mechanism that allows users to easily use third-party module libraries.
2 Likes

Interesting! Could you, if relevant, summarize some important similarities and differences between Otavia and Akka/Pekko? I think it would be good to have contrasting info about open source alternatives in the Otavia docs, to help understand the sweet-spot of this lib.

1 Like

Very good suggestion, next I’ll add a comparison document between otavia and AKKA. AKKA is a great project, while otavia in general focuses more on a lightweight Actor model and a better IO model (ported from Netty).

Since real programming requires us to handle a lot of IO tasks, porting the IO model from Netty allows us to port a lot of application-layer protocol coding and decoding code from the Netty ecosystem. Perhaps this will expand the boundaries of the Actor model even more!

Wellcome to the Discussions of Otavia!

GitHub - Discussions

2 Likes

Thank you for your interest in otavia. This is a frequently asked question, so I maintain a thread dedicated to it. You are welcome to participate!

Discussions - Similarities and Differences between Otavia and Akka/Pekko

1 Like

Design principles of otavia

Object-oriented programming is a very useful programming paradigm, and while the original object-oriented idea was somewhat similar to the Actor model, where an object is equivalent to an Actor, modern implementations of object-oriented in the major programming languages have degraded it to a way of organizing and encapsulating the code, since the cost of calling methods directly is much less than message passing. This is wonderful in the single-threaded case, where everything is organized.

But the crisis came with multithreading and multiple CPU cores: multithreading is like a herd of savage bulls rampaging through a fragile jungle of objects! Instead of having a single path of execution, programs are now controlled by a well-organized set of objects. Instead, you need to care carefully whether each object will be accessed by more than one thread at the same time, and you need to double-check your program’s concurrency safety. But it’s not easy to do. Especially for a software system of enormous size, you don’t know how many threads are rushing through your jungle of objects, so you need to go out and simulate every thread with a human brain, track their paths, and then figure out which objects should need to deal with concurrency safety. Imagine tracking down this herd of savage bulls in the jungle, meticulously checking one by one which grasses they’ve stepped on! God, it’s maddening to think about. All this work was already exhausting, but there was an even more serious problem: these bulls would suddenly come to a standstill when they stepped on certain grass! They are blocked and thus suspended, and this reduces the system’s CPU utilization, which in turn may lead to the launching of more threads, with more and more concurrent contention, until the system crashes under a concurrency problem that is not rigorously examined!

Happily, new technologies have emerged to solve these problems. The most popular technical solutions are coroutine and JVM virtual threads. However, in our opinion, these techniques are effective in alleviating the problem of low CPU utilization due to suspended threads, but they do not alleviate the problem of having to carefully design our objects due to concurrency competition.

The main reason the problem has gotten so bad we believe is that the current mainstream programming languages and object-oriented programming paradigms are missing some of their key features! That is, the lack of organization of concurrency and the lack of organization of execution flow! Concurrency and execution flow are currently coupled with objects, which was not a problem in early single-threaded environments, but becomes very serious in multi-threaded, multi-CPU environments!

Organizing concurrency and execution flow is where the Actor model excels! With the advent of Scala 3, we saw the possibility of designing an Actor programming tool that was more in line with object-oriented thinking. So, after a long period of conceptualization, I designed otavia and its associated toolkit. The goal is to explore a simpler and safer programming paradigm to meet the current challenges. Also hope to open up a new idea to provide everyone to promote the development of programming tools!

We believe that a better programming hierarchy would look like the following, and the design of otavia follows this hierarchy

System > Process > Threads > Virtual Threads/Stacked coroutines > Actor > Objects > Functions

In this hierarchical design, the Actor is the end point of concurrency, i.e., the Actor and its subsequent parts should all run single-threaded! Actors communicate with each other by sending messages, and multiple messages are processed one by one in the Actor’s mailbox in a single-threaded fashion.The logic inside the Actor can be either object-oriented or functional, or even a combination of them, as in Scala! Now everything is simple again and you can boldly use objects without worrying about that wild herd of bulls!

‘otavia’ is a very interesting project, which is currently in the incubation stage. If you are interested, any contribution from you is warmly welcome! We would also love to hear your suggestions or criticisms about the project. All your comments will ultimately help us to improve the quality of the project! You can also give a like to the project to encourage the contributors to the project! You can also give the project a star to encourage contributors!

1 Like