NUMA can cause really crappy performance. We deployed a Go based LLM gateway in Kubernetes deployed on a server with hundreds of CPU cores. We didn't explicitly set GOMAXPROCS so Go runtime scheduled goroutines over different CPUs and it constantly used 200% CPU and GC was causing latency spikes. Then we set GOMAXPROCS 8 and all performance issues went away. Until recently Kubernetes didn't work well with NUMA.
It simulates x86 (win32 and win16) and implements Windows APIs in javascript and renders window frames with DOM and contents with canvas (e.g. GDI translates to browser canvas operations). A lot of programs run already but a lot of APIs are not yet implemented.
I successfullt spent a few days extending it to run a Click & Create based game from my childhood.
That's just not true. Let's say you have a form validation library with a public api that supports custom validators Validate(name string, value string) bool. Then you decide that your validator now needs to make an HTTP request. This request needs context so that tracing is propagated and needs to return (bool, error) so that error is propagated up instead of silently ignoring it or logging it and returning false. This is coloring. You can use context.Background the same way you can use blocking in other languages. It just doesn't feel right and it breaks things.
I wonder what would happen if they used Kimi 2.5 directly instead of Cursor Composer 2.5. Composer is a fine tune of Kimi. Probably they didn't want to test "Chinese" models.
You generally want both relative and absolute tolerances. Relative handles scale, absolute handles values near zero (raw EPSILON isn’t a universal threshold per IEEE 754).
The usual pattern is abs(a - b) <= max(rel_tol * max(abs(a), abs(b)), abs_tol) to avoid both large-value and near-zero pitfalls.
Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)