28 ms·

I don't see the link between golangs go statement and goto except they cause a fork in control paths. Go's go statement is not bad. I wrote a userspace M:N sch

I don't see the link between golangs go statement and goto except they cause a fork in control paths. Go's go statement is not bad. I wrote a userspace M:N scheduler which multiplexes N lightweight threads onto M kernel threads. It currently preempts lightweight threads and tight loops round robin fashion but I could implement channels between lightweight threads and implement CSP. I created a construct for writing scalable systems concurrently called Crossmerge. It allows blocking synchronous code to be intermingled with while (true) loops and still make progress and join as a nursery does. There is a logical link and orthogonality between blocking and non-blocking and sometimes you need both in the same program. https://github.com/samsquire/ideas4#118-cross-merge https://github.com/samsquire/ideas4#118-cross-merge https://GitHub.com/samsquire/preemptible-thread https://GitHub.com/samsquire/preemptible-thread I added a multiconsumer multiproducer RingBuffer ala LMAX disruptor to the M:N thread multiplexer and it handles IO in a separate thread. If I add epoll and io_uring I could also handle asynchronous IO. My goal is to add an LLVM JIT and then I have an application server. I write a lot of concurrency and parallelism in ideas4 HTTPS://GitHub.com/samsquire/ideas4

gwd 4y ago
> I don't see the link between golangs go statement and goto except they cause a fork in control paths. This is a lot of why he goes into the history of "old-school goto" and its problems in the post. One of the issues with "old-school goto" is that you could never be sure if you called into a function whether it would actually return out of that function, or end up "goto"-ing somewhere else completely different, without going into it and inspecting it. Similarly, one of the issues with calling a function in Golang is that you can't be sure it didn't spin off a goroutine which is still doing some random work or other. I mean, yeah, you shouldn't just randomly fork off a goroutine which retains references to state passed into a function without clearly documenting it. But there's nothing to stop you from doing it.
- Spivak 4y ago
  > But there's nothing to stop you from doing it. And the crucial point is that because you can do it languages have to have weaker guarantees because they have to assume you could do it.

gwd 4y ago

> I don't see the link between golangs go statement and goto except they cause a fork in control paths. This is a lot of why he goes into the history of "old-school goto" and its problems in the post. One of the issues with "old-school goto" is that you could never be sure if you called into a function whether it would actually return out of that function, or end up "goto"-ing somewhere else completely different, without going into it and inspecting it. Similarly, one of the issues with calling a function in Golang is that you can't be sure it didn't spin off a goroutine which is still doing some random work or other. I mean, yeah, you shouldn't just randomly fork off a goroutine which retains references to state passed into a function without clearly documenting it. But there's nothing to stop you from doing it.

Spivak 4y ago
> But there's nothing to stop you from doing it. And the crucial point is that because you can do it languages have to have weaker guarantees because they have to assume you could do it.