What does HackerNews think of trio?

This was the main driving force behind the development of Polyphony. I've been exploring all the different ways of expressing concurrent operations: callbacks, promises, async/await. Each of these solutions has its drawbacks: callbacks make you split your app logic across different functions; promises are a somewhat better API but do not solve the split logic problem; async/await potentially leads to two types of functions (the "what color is your function" problem). All three kind of break Ruby's exception handling model.

In contrast, Polyphony relies on Ruby fibers, which provide a base for implementing cooperative concurrency, where each fiber does its work, yielding execution whenever it performs a blocking operation, such as reading from a socket, or waiting for a timeout. In addition, fibers are arranged into a tree where each fiber is considered the child of the fiber from which it was spawned, and is guaranteed to stop executing before its immediate parent stops executing. Any uncaught exception raised by a fiber will be propagated up the fiber tree. This implements a pattern known as Structured Concurrency [1]. Fibers can communicate by sending each other messages, in a similar fashion to Erlang/Elixir processes.

There's no direct equivalent in Polyphony to the program you included, which seems to implement two generators running asynchronously. But the following does something similar.

    def number_generator
      n = 0
      loop do
        client = receive
        client << (n += 1)
      end
    end

    task1 = spin { number_generator }
    task2 = spin { number_generator }
    
    10.times do
      task1 << Fiber.current
      puts "next number from task1: #{receive}"
      task2 << Fiber.current
      puts "next number from task2: #{receive}"
    end

 So in the above program, two fibers are spun, each running the same number generator, which repeatedly waits for a message which is actually the fiber of the "client", and sends the next number to the client. In Python there's the Trio library [2], which implements structured concurrency, and which was actually one of the main inspirations for developing Polyphony.

Structured concurrency is one approach to solving this problem. In a structured concurrency a promise would not go out of scope unhandled. Not sure how you would add APIs for it though in Javascript.

See Python's trio nurseries idea which uses a python context manager.

https://github.com/python-trio/trio

I'm working on a syntax for state machines and it could be used as a DSL for promises. It looks similar to a bash pipeline but it matches predicates similar to prolog.

In theory you could wire up a tree (graph if you have joins) of structured concurrency with this DSL.

https://github.com/samsquire/ideas4#558-assign-location-mult...

In fairness they were only included in asyncio as of Python 3.11, which was released a couple of weeks ago.

These were an idea originally from Trio [2] where they're called "nurseries" instead of "task groups". My view is that you're better off using Trio, or at least anyio [3] which gives a Trio-like interface to asyncio. One particularly nice thing about Trio (and anyio) is that there's no way to spawn background tasks except to use task groups i.e. there's no analogue of asyncio's create_task() function. That is good because it guarantees that no task is ever left accidentally running in the background and no exception left silently uncaught.

[1] https://docs.python.org/3/library/asyncio-task.html#task-gro...

[2] https://github.com/python-trio/trio

[3] https://anyio.readthedocs.io/en/latest/

The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing.

The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I'm optimistic about its future. There were plans to use it for requests v3 until the fundraiser fiasco [5].

[0] https://github.com/python-trio/trio

[1] https://vorpus.org/blog/announcing-trio/

[2] https://trio.readthedocs.io/en/stable/reference-core.html#us...

[3] https://trio.readthedocs.io/en/latest/reference-core.html#ca...

[4] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

[5] https://vorpus.org/blog/why-im-not-collaborating-with-kennet...