czardoz

Exactly. OpenClaw is good, but expects the model to behave in a certain way, and I've found that the local options aren't smart enough to keep up.

That being said, my gut says that it should be possible to go quite far with a harness that assumes the model might not be quite good (and hence double-checks, retries, etc)

Really looking for a minimal assistant that works with _locally hosted models_. Are there any options?

If this stack is heavily skewed towards numerical computations, Cinder might require a lot of tuning to be effective.

It has some elements of WSGI, but has expanded into its own thing which supports asyncio (this happened before ASGI was a thing).

I'd love to see lazy imports become part of the upstream at some point.

Cinder's feature set is highly optimized for IO bound web services that run under a forked-worker model.

For example: you start a main process, warm it up with a few requests, run the JIT compiler and then fork off worker processes to handle the main chunk of traffic.

As of now, it requires hand-tuning to get the best possible performance.

In terms of use cases, Cinder does the best when faced with "business logic" code (lots of inheritance, attribute lookups, method calls, etc). It can speed up numerical computations too, but you're probably better off using a library if that's the majority of the workload.

I worked on Cinder, and on the web server. Happy to answer technical questions if any :)

I'm always surprised when patterns like this actually work. But they do!

I've moved to Zoho mail. It's $1/month for a single user, which seems to be well worth it. The catch is, it's not possible to _send_ from Zoho without creating additional users (which has a cost).

Can you elaborate on what you mean by "skip" Cython compilation on dev builds? How would you then test changes to Cython code?

Unlike RPython, Static Python in cinder is not really a subset of Python, it can compile everything (although it will throw compile time errors if it sees mismatched types). If it cannot determine type information, it just assumes the type could be anything, and falls back to slower CPython behavior.

> Why is “developers might have to interact with it” some kind of non-starter, as though having a compile phase is a worse evil than a hyper-slow language?

For big monoliths (like ours at IG), the server start-up can take more than 10sec, which is already super high for a "edit -> refresh" workflow. Introducing a Cython like compilation step is really a major drawback for every single developer.

For smaller projects, Cython works extremely well (and we do use it for places where we need to interface with C/C++).

> Well, the compilation step is alredy present in current py -> pyc phase

Yes, but developers don't have to ever interact with it.

> Also, look at how cython work

Cython works by adding a separate build step. Changing a Cython module requires you to recompile it, which is avoided with a JIT.