Hello all,

My name is Albert and I built this statechart engine to scratch my own itch. I work with embedded systems and in an environment where process is paramount. My current employer has a number of certifications that require semi-annual audits of process, paperwork, etc.

I kept reaching for tools I knew about (python-statemachine in particular) in order to solve process problems, but nothing really scratched the itch; I needed an engine that took declarative workflows that were versionable and more importantly, not a part of the core runtime. I want to be able to push/pull/up/down workflows the same way I do docker containers. I want those workflows to expose API endpoints and webhooks so I can interface with them in a variety of ways (UI, test completions, ECO/ECR flows involving people, and so on).

This library is a foundational piece of that puzzle; it gives me a relatively performant statechart execution engine that I can build my dream app on top of.

It consists of two runtimes: an event driven runtime, and a tick-based runtime. The event driven runtime does not make guarantees about event execution order for parallel states, where the tick-based system does. The tick based runtime is single-threaded on purpose, in order to guarantee event evaluation order, which makes it deterministic.

As an aside, I plan on building out a number of demos using this engine in the coming weeks. Amongst the demo ideas are: an AI agentic pipeline doing something arbitrary, like research (because why not), a simple game engine integration where the tick-based runtime takes the place of 'system' in an entity-component-system architecture, and probably an http server implementation just for kicks.

Thanks for taking a look!

---

Oh, and here are some benchmarks for the alpha release:

StatechartX Benchmarks (i5-5300U, 4 cores, Linux)

  Runtime              Burst      Sustained   Latency   Queue   Allocs
  ---------------------------------------------------------------------
  Realtime (1000Hz)    15.05M/s   ~6.1M/s     279 µs    10K     0
  Core - Simple        8.86M/s    8.86M/s     ~83 ns    100K    0
  Core - Internal      12.08M/s   12.08M/s    ~83 ns    1K      0
  Core - Concurrent    4.00M/s    4.00M/s     ~83 ns    10K     0
  Core - Parallel      3.69M/s    3.69M/s     ~83 ns    100K    0
  Core - Hierarchical  3.41M/s    3.41M/s     ~83 ns    100K    0
  Core - Guarded       3.01M/s    3.01M/s     ~83 ns    100K    0

  Memory: 32KB/machine | Zero allocations under load | Graceful backpressure

  Event-driven: burst = sustained (constant, predictable)
  Tick-based: burst > sustained (15M submit, 6.1M process)

It seems like everything converges on either LISP or emacs.

It's actually the opposite, I think. Because of how industrialized the lumber/paper industries have gotten, stewardship of forests has improved over time. This includes replanting in harvested areas.

Says anyone who has tried to do anything requiring the smallest amount of computer science or computer engineering. These models are really great at boilerplate and simple web apps. As soon as you get beyond that, it gets hairy. For example, I have a clone of HN I've been working on that adds subscriptions and ad slot bidding. Just those two features required a lot of hand holding. Figma Design nailed the UX, but the actual guts/business logic I had to spend time on.

I expect that this will get easier as agentic flows get more mature, though.

Then the only place that novelty will occur is in the actual study of computer science. And even then, a well contexted agentic pipeline will speed even R&D development to a great degree.

One very bad thing about these things is the embedded dogma. With AI ruling the roost in terms of generation (basically an advanced and opinionated type-writer, lets be honest) breaking away from the standards in any field will become increasingly difficult. Just try and talk to any frontier model about physics that goes against what is currently accepted and they'll put up a lot of resistance.

I’ve been pleasantly surprised how useful it is for writing low level stuff like peripheral drivers on imbedded platforms. It’s actually-simple- stuff, but exactingly technical and detail oriented. It’s interesting that it can work so well, then go wildly off the rails and be impossible to wrestle back on unless you go way back in the context or even start a completely new context and feed in only what is currently relevant (this has become my main strategy)

Still, it’s amazingly good at wrestling the harmony of a bunch of technical details and applying them to a tried and true design paradigm to create an API for new devices or to handle tricky timing, things like that. Until it isn’t and you have to abort the session and build a new one because it has worked itself into some kind of context corner where it obsesses about something that is just wrong or irrelevant.

Still, it’s a solid 2x on production, and my code is arguably more maintainable because I don’t get tempted to be clever or skip clarifying patterns.

There is a level of wholistic complexity that kills it though. The trick is dividing the structure and tasks into self contained components that contain any relevant state within their confines to the maximum practical extent, even if there is a lot of interdependent state going on inside. It’s sort a mod a meta-functional paradigm working with inherently state-centric modules.

> a clone of HN I've been working on that adds subscriptions and ad slot bidding

Wut, what's the purpose of that? Is this just a toy learning project? Would it be to make money off of people who don't know that an ad-free version of HN exists at news.ycombinator.com? Will you try to sell it to Ycombinator?

I am hoping they are developing it as a satirical art project, otherwise... yikes; needing a credit card and an ad blocker to use HN would be very depressing and is counter to everything I enjoy about this forum.

A "clone" usually doesn't mean that they'll copy the content, but the idea, like Ola is a clone of Uber.

(Though they probably should've said a link aggregator instead of HN clone.)

> (Though they probably should've said a link aggregator instead of HN clone.)

That's fair. It is a feature-to-feature clone, though.

Mostly just learning, to be honest. I'm not trying to replace HN, I'm just fiddling around and seeing what I can do and what I can't.

My long term purpose is to provide the source code for communities/creators that want something simple to set up, and specifically allow creators to gate content behind a paywall. I'm sure stuff like that exists, but I hope what I build will be at least somewhat use-able.

I'm glad you are not being competent enough to create a paid version of HN with the help of AI

> Poorly engineered

How so? As a pedagogic tool it seems adequate. How would you change this to be better (either from a teaching standpoint or from a SWE standpoint)?

I'm curious what the alternative would be? Python's threads/sub-processing almost requires IO queues to function well, and are nearly the same semantically as channels...

I'm not saying these are "good", just wondering what alternatives look like?

One alternative is STM, software transactional memory which is modular and composable. I think Haskell was first to implement it but its also in Clojure and some Scala libs.

This is what ZIO's type safe version looks like https://zio.dev/reference/stm/ Scala's for-comprehension is syntactic sugar for calls to flatMap, map, and withFilter, similar to Haskell's do-notation.

Meh. The US has a history of installing totalitarian or terrorist governments. The middle-east is a lovely example; the US was responsible for the likes of Osama Bin Laden (CIA asset), for the installation of Saddam Hussein, and many many more.

To be fair, I would probably toss the gun away if a bullet went through my foot.

I find that having a code-base properly scaffolded really, really helps a model handle implementing new features or performing bug-fixes. There's this grey area between greenfield and established that I hit every time I try to take a new project to a more stable state. I'm still trying to sort out how to get through that grey area.

I had Claude nearly one-shot (well, sequence-of-oneshots) a fairly complex multi-language file pretty-printer, but only after giving it a very specific 150-line TODO file with examples of correct results, so I think pure greenfield is very achievable if you steer it well enough. I did have to really focus on writing the tasks to be such that there wasn't much room for going off the rails, thought about their ordering, etc; it was pretty far from vibecoding, produced a strict data-driven test suite, etc.

But ultimately, I agree with you, in most projects, having enough existing style, arranged in a fairly specific way, for Claude to imitate makes results a lot better. Or at least, until you get to that "good-looking codebase", you have to steer it a lot more explicitly, to the level of telling it what function signatures to use, what files to edit, etc.

Currently on another project, I've had Claude make ~10 development spikes on specific ~5 high-uncertainty features on separate branches, without ever telling it what the main project structure really is. Some of the spikes implement the same functionality with e.g. different libraries, as I'm exploring my options (ML inference as a library is still a shitshow). I think that approach has some whiff of "future of programming" to it. Previously I would have spent more effort studying the frameworks up front and committed to a choice harder, now it's "let's see if this is good enough".

> that machine is far more skilled at generating quality Rust than I currently am. But I am using this as an opportunity to learn.

I'm currently doing this with golang. It is not that bad of an experience. LLMs do struggle with concurrency, though. My current project has proved to be pretty challenging for LLMs to chew through.