-
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
Hey folks, wanted to show this off and get feedback. Still early/experimental but there are quite a few concepts I'm excited about here. This project came about while writing a program in Go and loving its approach to concurrency. Being a long-time Rubyist I immediately started to think about what similar concepts might look like in Ruby.
I set out with two main design constraints:
1. Lightweight: I didn't want routines to be backed by fibers or threads. Having been involved some in the async project (https://github.com/socketry/async), I had some experience using fibers for concurrency but was curious if they could be avoided.
2. Explicitness: Routine behavior must be written to describe exactly how it is to behave. I always felt like concurrent code was hard to fully understand because of the indirection involved. On the spectrum between tedium and magical I wanted to err more on the side of tedium with Goru.
Goru routines are just blocks that are called once for every tick of the reactor. It is up to the developer to implement behavior in terms of a state machine, where on each tick the routine takes some action and then updates the state of the routine for the next tick. This fulfills both design constraints:
1. Because routines are just blocks, they weigh in at about ~345 bytes of memory overhead.
2. Routine behavior is explicit because it is written as a state machine inside the block.
Couple more features worth noting:
* Goru includes channels for buffered reading/writing (similar to channels in Go).
* Goru ships with primitives for non-blocking IO to easily build things like http servers.
Curious your thoughts!
