Post 9jwdZPMF0bfnrdzfBA by kast@mastodon.technology
(DIR) More posts by kast@mastodon.technology
(DIR) Post #9jwZXaRKR3Rxq4FWCG by sir@cmpwn.com
2019-06-17T16:48:05Z
0 likes, 0 repeats
Go, the bad parts: the runtime; goroutinesGo, the good parts: everything else; the small featureset
(DIR) Post #9jwZcxmn3vTph3qrNg by PresidentTrumpAwesome@mastodon.technology
2019-06-17T16:48:54Z
0 likes, 0 repeats
@sir Things I hate: feminism, gays, blacks, socialism, welfare, and poor peopleThings I love: President Trump, capitalism, money, and banging hot escorts
(DIR) Post #9jwaUkg218fkfrL3MO by biosmarcel@niu.moe
2019-06-17T16:58:31Z
0 likes, 0 repeats
@sir What's wrong with goroutines
(DIR) Post #9jwakrDBUOBZZgWcam by sir@cmpwn.com
2019-06-17T17:01:29Z
0 likes, 0 repeats
@biosmarcel I want my code to be explicitly cooperative or explicitly preemptive, not neither
(DIR) Post #9jwapauDXdhgRzucqW by biosmarcel@niu.moe
2019-06-17T17:02:06Z
0 likes, 0 repeats
@sir It's because I don't know enough about programming or that I am not a native speaker, but I have no clue what that means :)
(DIR) Post #9jwavwiTMaPtpfRoEy by sir@cmpwn.com
2019-06-17T17:03:36Z
0 likes, 0 repeats
@biosmarcel cooperative multitasking means that your code yields to another task when it chooses to. Preemptive multitasking means that your code is "pre-empted", meaning that it can be interrupted at any time to transfer control to your other tasks. The former is much easier to reason about
(DIR) Post #9jwbFEXVK0HkbzVwBs by biosmarcel@niu.moe
2019-06-17T17:07:04Z
0 likes, 0 repeats
So you want to be able to pause or stop a goroutine from the outside of a goroutine?
(DIR) Post #9jwboqFR77mthM2gZk by sir@cmpwn.com
2019-06-17T17:13:32Z
0 likes, 0 repeats
@biosmarcel no, I want the opposite. Goroutines are magic, they're both cooperative and preemptive and therefore you are required to use more complex syncronization strategies because the runtime could decide at any time to run your code preemptively. I generally avoid preemptive multitasking as it's not worth the complexity but in Go you cannot avoid it
(DIR) Post #9jwbzhin9i9cRHx8Ge by biosmarcel@niu.moe
2019-06-17T17:15:25Z
0 likes, 0 repeats
@sir I see. I never had any problems with the way it works. Or maybe I just accepted it, as I come from java where multithreading is fucking ass :ablobowo:
(DIR) Post #9jwc4zSqcEIAup11xA by stsquad@mastodon.org.uk
2019-06-17T17:16:13Z
0 likes, 0 repeats
@sir so are goroutines like coroutines? Or are they some sort of hybrid thing? I only mention this because #qemu uses coroutines quite heavily for it's up stuff but I find it fairly impenetrable.@biosmarcel
(DIR) Post #9jwcEN1KP65qa0cGrQ by sir@cmpwn.com
2019-06-17T17:18:01Z
0 likes, 0 repeats
@stsquad @biosmarcel goroutines are hybrids, they can be either cooperative or preemptive and you don't really have a say in it. This also has grave consequences for the complexity of the runtime
(DIR) Post #9jwcIUZWGlxZ9tZg3c by sir@cmpwn.com
2019-06-17T17:18:24Z
0 likes, 0 repeats
@stsquad @biosmarcel they can also change from cooperative to preemptive at any time, and even move between CPUs
(DIR) Post #9jwcbGHLdR3KKc1bKy by biosmarcel@niu.moe
2019-06-17T17:22:11Z
0 likes, 0 repeats
@sir @stsquad Well, that's kinda part of philosophy behind them. You shouldn't have to worry whether a goroutine is actually a thread, what core it runs on and yare yare yare. It's abstracts such things away. Can be seen as good and as bad.
(DIR) Post #9jwd2nLylw1ijIJu2y by stsquad@mastodon.org.uk
2019-06-17T17:24:20Z
0 likes, 0 repeats
@biosmarcel so what protects the data a goroutine is accessing from race? AIUI #rust does this with ownership - so only one code path at a time owns the right to access the data and there is safe passing of ownership between things built into the language.@sir
(DIR) Post #9jwd2nZRxqnnP4cf2m by sir@cmpwn.com
2019-06-17T17:25:13Z
0 likes, 0 repeats
@stsquad @biosmarcel nothing, you have to use mutexes or or atomics or channels (the latter being a message passing primitive built into the langauge, and the preferred way)
(DIR) Post #9jwdZPMF0bfnrdzfBA by kast@mastodon.technology
2019-06-17T17:29:26Z
0 likes, 0 repeats
@sir @stsquad @biosmarcel goroutines are pretty easy to use as long as you're using channels only to synchronize them
(DIR) Post #9jwdmyI4RP2pyFVhwG by sir@cmpwn.com
2019-06-17T17:32:05Z
0 likes, 0 repeats
@kast @stsquad @biosmarcel but it's still magic, and magic is not good. My code should do what I tell it to, not what the runtime decides is best for it.
(DIR) Post #9jwfnsS5piPY3rl3hI by kast@mastodon.technology
2019-06-17T17:58:09Z
0 likes, 0 repeats
@sir @stsquad @biosmarcel Golang expects programmers to embrace CSP https://en.wikipedia.org/wiki/Communicating_sequential_processes . There's a whole theory behind this thing: http://usingcsp.com/cspbook.pdfNot exactly magic, but yes, there is a lot of non-obvious things happening under the hood to make it work.
(DIR) Post #9jwg29k6LPfRjzzR8S by sir@cmpwn.com
2019-06-17T17:59:45Z
0 likes, 0 repeats
@kast @stsquad @biosmarcel I am fully aware of that, and yet I still think it's a bad design. Encouraging programmers to use CSP while making preemptive/cooperative multitasking explicit would be great. Magic is never good
(DIR) Post #9jxiqFneUYRO4ZcvTM by mprymek@nerdica.net
2019-06-18T06:06:38Z
0 likes, 0 repeats
@sir @stsquad @biosmarcel Is Erlang's design bad then?I tend to agree with @kast - the real problem with concurrency imho is shared state. When you do not have shared state, there's no difference in preemptive/cooperative. Or to put it another way: you don't need to worry about context switch at all so preemptive is better because you don't have to be explicit.Erlang doesn't have shared state (beside DB-like things) and that's imho the primary reason it's not bad design, rather excellent design.