HN user

czardoz

624 karma
Posts1
Comments164
View on HN

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)

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'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).

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.

So much stuff just from the readme would introduce breaking changes to the Python ecosystem.

Being compatible with the rest of the Python ecosystem is the main reason why Cinder is built on top of CPython. Although yes, some features are indeed very experimental.

in a world where we have type annotations, JITs feel like a massive step back. Stuff like mypyc could get us way further into high performance stuff

Ah, but that introduces a separate compilation step, which may not be tolerable in every situation.

There's nothing wrong with gotos in compiled code. At the end of the day, machine code is really just a bunch of gotos with other instructions in between.

The reason goto is considered bad is that it can make code hard to follow for humans. Since this is an intermediate step in compilation, that's not an issue here.

Why do I need methods to have underscores in 2021, but classes to use camel case? Why do my lines of code need to fit on a punched card invented decades before the language was invented? Why does the idiomatic "one true way" need to be what some other engineer thinks is "the one true" way?

These problems are applicable to all languages, not just Python.

You're talking about this as if a "calculated risk" is limited to that individual, but it's not. Someone's "calculated risk" is literally death knell for others.

In this case, the health of the society as a whole is at stake. Therefore, people need to collectively follow rules, and understand that minor inconveniences such as not being able to get a haircut will only affect them for a few weeks or months.

So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on.

That's unsubstantiated and dilutes the discussion IMO. If you read the post, the proposal outlines a bunch of good reasons to stop supporting UA strings (feature detection, etc)

Apple has a 1-week (or is it 2 weeks?) unconditional return policy. It actually disservices them to announce it after since they may now get a bunch of open box returns.

Yeah, but how many people are actually going to go through the hassle of returning them?