chris6f

8 ms·

1.
by chris6f 3y ago
It's probably better to let the user/application decide what to do in these cases, and for this reason we allow them to register type-specific (de)serialization routines. In the case of network connections, the user could instead
2.
by chris6f 3y ago
It's a good point, but the entire program would have to be written this way (you can't use the standard library, or any other dependencies). What if there were tools to inspect and debug the coroutine state? That's an area we
3.
by chris6f 3y ago
The library provides a way to serialize coroutine state, and to later deserialize that state and resume a coroutine from its last yield point. Where you store this state (in a DB, in a queue, etc) is up to you!
4.
by chris6f 3y ago
A source-to-source compiler, and a library that bundles runtime implementation details, was the path of least resistance. We'd love to integrate this with the Go compiler (`go build -durable`, vs. `coroc && go build -tags durab
5.
by chris6f 3y ago
We have a solution already, and we're exploring a few more. The durable coroutine library is one part of a larger system we're releasing soon. See https://stealthrocket.tech/blog/fairy-tales-of-workflow-orch..
6.
Show HN: WebAssembly System Interface (WASI) with Sockets for Go(github.com)
9 points by chris6f 3y ago|0 comments
7.
by chris6f 4y ago
Vector length agnostic programming has its own share of problems. I'm not familiar with the RISC-V V extension, but I assume it's similar to ARM's SVE. There's a good critical look at SVE and VLA here: https:/&#x2F
8.
by chris6f 4y ago
We took a similar approach in our JSON decoder. We needed to support sets (JSON object keys) that aren't necessarily known until runtime, and strings that are up to 16 bytes in length. We got better performance with a linear scan and S