3 ms·
On the one hand this seems like a strange decision given that Go purposefully avoids asynchronous code. On the other hand, I think this project is trying to ge
by omginternets 10y ago
On the one hand this seems like a strange decision given that Go purposefully avoids asynchronous code. On the other hand, I think this project is trying to get at something that is (IMHO) a blind-spot for the Go community. Namely: I find it difficult to design abstract data-flow patterns and encapsulate behind a nice API.
Go is great for dealing with the nitty-gritty of concurrency, but I find it hard to express a high-level vision of what's going on in my app/lib. This is why this project almost feels good. There's a clear view of what we're manipulating and how we're positioned relative to the data.
Has anybody else struggled with this?
The closest thing I've found to a solution has been go-mangos[0], a native go implementation of the scalable protocols. This is extremely useful for designing the data-flow of an application when I'm shuffling bytes around, but what I find myself wanting is an equivalent system for raw (i.e.: unserialized) Go data-structures.
I want to be able to do something like this (assume a hypothetical library to this effect called `portal`):
p0, _ := portal.NewPortal(iface, portal.REP) // iface is a types.Interface
p0.Bind("foo")
p1, _ := portal.NewPortal(iface, portal.REP)
p1.Dial("foo")
go func() {
for {
i, _ := p0.Recv() // `i` guaranteed to satisfy the interface represented by `iface`
i.DoSomething()
p0.Send(i)
}
}()
p1.Send(iRequest)
iResult, _ := p1.Recv()
I'm very curious to get some feedback on this idea. It's been gnawing away at my brain for a while now.
[0] https://github.com/go-mangos/mangos https://github.com/go-mangos/mangos