> but suggesting that highly skilled tech jobs are a solution is just not realistic.

I went from homeless to six figures thanks to tech.

I think you are missing that tech is one of the few well paying industries that doesn't have socioeconomic gatekeeping with degrees.

> ..kind of breaks the typical stack-trace patterns.

The expectation that iterative recursion ought to have a call stack is the problem here and wouldn't be up for debate if people had done their due diligence and read their SICP.

There is truth to this but it's important to acknowledge that exposure therapy alone may not be sufficient for everyone and will require alternative modalities.

Nothing is sufficient for everyone. You set an impossible bar.

Yep. Even io_uring sends all block device commands to a backend thread pool.

I think only benefit is reduced syscall overhead.

Instead of adding another dependency you can just call `loop.run_in_executor` yourself: https://github.com/Tinche/aiofiles/blob/main/src/aiofiles/ba...

I'm glad it was reposted so I saw it. I may actually use python for scripting now because uv makes it so easy.

> My thesis is that I disagree that "Self-Taught Engineers Often Outperform"

They do in FAANG.

Was going to ask how this integrates into Envoy but dug into the code it looks like proxywasm which must mean `envoy.bootstrap.wasm` ?

We’re using proxy-wasm and compiling to wasm32-wasip1, then mounting the .wasm binaries into Envoy as HTTP filters via envoy.filters.http.wasm. The line you're referring to:

vm_config: runtime: "envoy.wasm.runtime.v8" code: local: filename: "/etc/envoy/proxy-wasm-plugins/prompt_gateway.wasm"

…is where the integration happens. There's no need to modify envoy.bootstrap.wasm; instead, Arch loads the WASM modules at runtime using standard Envoy config templating. The filters (prompt_gateway for ingress, and llm_gateway for egress sit in the request path and do things like prompt inspection, model routing, header rewrites, and telemetry collection.

> how do i know that the CPU thing does not block inside my async io thing?

I think it's common sense to not interweave IO with long-running CPU, hence sans IO.

If you want to go that route, we already have solutions: goroutines and beam processes.

This was my point. With Go it does not matter, i can do IO or CPU both with Gos concurrency (CSP), but with async/await i usully cannot, i assume this is not something Zig is planning on, as it seems to be all about IO.

Aren't threads overkill for an IO workload? You can do a lot with 1 thread and epoll(7).