Yorick Peterse

A downside of using closures is that it gets a bit clunky if you want to produce multiple outputs as separate variables. In the guard approach you'd do something like...

To add to the above: Inkwell exposes basically everything as immutable types/methods, even though LLVM mutates things under the hoods. This means that even if we were to get things...

Regarding stack slots: based on how we use structure returns right now, and the fact that Inko values are heap allocated (apart from Int/Float/etc), I think stack slot reuse (or...

Another challenge: our FFI supports variadic function arguments, something that's needed to interface with certain C libraries (e.g. cURL). Per [this issue](https://github.com/bytecodealliance/wasmtime/issues/1030) Cranelift has no support for this whatsoever, and...

To add some context: LLVM doesn't optimize across modules unless you enable link time optimizations. LTO can drastically increase compile times, and doesn't always produce better results. Because of this,...

With Windows support being dropped, making this change is easier as we don't need to use completion ports of wepoll.

An approach I'm toying with is to move the low-level socket bits to the Inko standard library, only exposing some low-level bits to register sockets with the network poller, then...

To add to that: the runtime still needs to keep track of some socket related data (e.g. the "registered" flag), but much of the actual IO work would happen in...

Today I tried to update polling to 3.x, but this results in macOS socket test failures. The root cause is that the crate changed its implementation such that you can...

I'm going to open up this issue for contributions. While the work isn't necessarily easy, I think it should be suitable for somebody with decent knowledge of Rust looking to...