A `runtime` means something that operates at `runtime` with extra overhead compared to anything done at compile-time by the compiler. It also means potentially interoperability issue.
For example, a garbage collector or a reference counting scheme is also a runtime, extra overhead, not done at compile-time. Systems languages need to keep a runtime very lightweight in most cases and inexistent in certain critical cases (operating system, interoperability/embedability in other language). Now a runtime is also supposed to bring benefits: abstract away the programmer's worries of manual memory management or manual thread management. I would say the goal is not to replace threadpool, but provide an advanced version. The standard library threadpool gives you a simple way to use threads, however those are not load balance which is a critical issue in many cases. Now users have 2 choices, either they have a common use-case (process all my tasks as fast as possible) and they can use Weave. Or they have very specific constraints like real-time scheduling/latency/fairness or priority jobs and they need to build their own scheduler on top of the threadpool or raw Nim threads. For example if you process audio or video in real-time, the goal is not to process the whole video as fast as possible but to get the next frame processed before the deadline. Weave would guarantee the former, but maybe it would schedule the first frame as the very last processed (guarantee of throughput but not of latency).
