<p>I am looking for input for my thesis about "Concurrent programming in go". It is about a comparison between classical multithreading and go's concurrency features. I have already some ideas but i would also like to hear your input.</p>
<p>I am looking for:</p>
<ul>
<li><p>Points why go is better suited for concurrent programming tasks and also sample algorithms and programs, that support these points. </p></li>
<li><p>Design patterns for concurrent programs in a "classical" language compared to patterns/idioms in go.</p></li>
<li><p>Good ideas on how to compare two programming languages in different ways. Obviously i need good arguments why something is better or worse.</p></li>
<li><p>Fair benchmarks, that highlight real-world performance of an average go program compared to a classical program. I want to test a go program that a average go dev would write rather than a highly optimized one.</p></li>
<li><p>Good literature especially on classical parallel programming (I already read "The Go Porgramming Language" and "Concurrency in Go")</p></li>
<li><p>What conclusion would you expect from such a comparison?</p></li>
<li><p>Possible shortcomings of go (yes I know where I am posting).</p></li>
</ul>
<p>I hope you have some good ideas for me, thank you very much:)</p>
<p>Edit1: Also if you know about any good papers on that topic.</p>
<hr/>**评论：**<br/><br/>exch: <pre><p>I don't know if you are aware if this, but Go's concurrency model is based on <a href="http://www.usingcsp.com/" rel="nofollow">Tony Hoare's Communicating Sequential Processes (CSP)</a>. This page links to a PDF with his paper.</p></pre>p0intl3ss: <pre><p>Thank you, I was aware that it was based on CSP but I still have to read the Paper.</p></pre>govision: <pre><p>Maybe this will help?</p>
<p><a href="https://youtu.be/cN_DpYBzKso" rel="nofollow">https://youtu.be/cN_DpYBzKso</a></p>
<p><a href="https://youtu.be/f6kdp27TYZs" rel="nofollow">https://youtu.be/f6kdp27TYZs</a></p>
<p><a href="https://youtu.be/7VcArS4Wpqk" rel="nofollow">https://youtu.be/7VcArS4Wpqk</a></p>
<p>I think though part of it is that this story of simplicity isn't done yet. It's not so much that go is better but that from a developer standpoint it can be better in some situations. Meaning that the design of the language was specific. Which some might say is bad but in reality it comes down to engineering for modules of languages instead of a heavy load on the developer to weild a Swiss army knife language. If for instance you see js now getting wait groups and this whole wasm thing trying to de-engineer go's concurrency model without the great type system or c# trying to muck their way with talking points through getting the same model as well, you start to see what Rob was explaining. That for whatever reason those languages had a certain philosophy and when a new paradigm comes along, they simply copy paste. Which those fundamentalist to those languages love but don't understand that when picking up the language, this new copy paste paradigm that's been inserted into their philosophy sticks out like a sore thumb. It's not so much that things are so novel in go, but that the philosophy is. This is why it's important to do things with not only a very specific purpose but also the years of experience and forsight to midigate these engineering design is possible. Or so that's my view on it but I think talking to actual language engineers will produce you better results instead of a random person on Reddit.</p></pre>_youtubot_: <pre><p>Videos linked by <a href="/u/govision" rel="nofollow">/u/govision</a>:</p>
<table><thead>
<tr>
<th align="center">Title</th>
<th align="center">Channel</th>
<th align="center">Published</th>
<th align="center">Duration</th>
<th align="center">Likes</th>
<th align="center">Total Views</th>
</tr>
</thead><tbody>
<tr>
<td align="center"><a href="https://youtu.be/cN_DpYBzKso" rel="nofollow">Rob Pike - 'Concurrency Is Not Parallelism'</a></td>
<td align="center">afriza na</td>
<td align="center">2013-10-20</td>
<td align="center">0:31:22</td>
<td align="center">1,769+ (98%)</td>
<td align="center">123,444</td>
</tr>
<tr>
<td align="center"><a href="https://youtu.be/f6kdp27TYZs" rel="nofollow">Google I/O 2012 - Go Concurrency Patterns</a></td>
<td align="center">Google Developers</td>
<td align="center">2012-07-02</td>
<td align="center">0:51:27</td>
<td align="center">2,224+ (98%)</td>
<td align="center">442,999</td>
</tr>
<tr>
<td align="center"><a href="https://youtu.be/7VcArS4Wpqk" rel="nofollow">Another Go at Language Design</a></td>
<td align="center">Stanford</td>
<td align="center">2010-08-27</td>
<td align="center">1:15:44</td>
<td align="center">152+ (95%)</td>
<td align="center">19,524</td>
</tr>
</tbody></table>
<hr/>
<p><a href="https://np.reddit.com/r/youtubot/wiki/index" rel="nofollow"><sup>Info</sup></a> <sup>|</sup> <a href="https://np.reddit.com/message/compose/?to=_youtubot_&subject=delete%20comment&message=dtrw1n5%0A%0AReason%3A%20%2A%2Aplease+help+us+improve%2A%2A" rel="nofollow"><sup>/u/govision</sup> <sup>can</sup> <sup>delete</sup></a> <sup>|</sup> <sup>v2.0.0</sup></p></pre>p0intl3ss: <pre><p>I will definitely watch these.</p>
<p>I see your point, I felt the same way since I first started learning Go.</p></pre>jackmott2: <pre><p>This paper is a must read before discussing anything procs/cons of concurrency/parallelism systems:</p>
<p><a href="https://www.usenix.org/system/files/conference/hotos15/hotos15-paper-mcsherry.pdf" rel="nofollow">https://www.usenix.org/system/files/conference/hotos15/hotos15-paper-mcsherry.pdf</a></p></pre>p0intl3ss: <pre><p>Thank you I didn't know that one yet:)</p></pre>_nefario_: <pre><p>sounds like you want us to write your thesis. </p></pre>p0intl3ss: <pre><p>That is not my intention.</p>
<p>I am currently writing the thesis but I am also looking for some input form experienced gophers since I have not much practical go programming experience myself. </p>
<p>It is still me who is writing the thesis but there is a fair chance I am missing some important points, that is why I asked for help.</p></pre>epiris: <pre><p>Your points look great, now research them to form your own premises and conclusions. We will gladly give you feedback after <em>you</em> have gone through deductive reasoning on your questions here. If you have specific questions like: is this benchmark properly measuring doing X in each language? This is a great place to ask.</p></pre>hell_0n_wheel: <pre><blockquote>
<p>I have not much practical go programming experience myself.</p>
</blockquote>
<p>Isn't that supposed to be part of your research, to develop your experience?</p></pre>p0intl3ss: <pre><p>What I am saying is that go is not my primary programming language and I have never written commercial code nor worked on a bigger project. I have already written some programs (mostly REST services) for smaller projects.</p></pre>ChristophBerger: <pre><p>Writing a thesis involves research, and research involves asking.<br/>
Asking and reading and thinking and writing. Rinse and repeat.</p></pre>earthboundkid: <pre><p>Go is good at multithreading and asyncio, but I don't think it does much if any SIMD yet. (So for example, if you want fast image resizing, you'll probably end up wanting to use Cgo.) That could be an area to explore.</p></pre>maus80: <pre><p>I would like to see a graph of memory usage vs number of parallel executed processes of various programming environments. Also the cost/overhead of context switching between these processes would interest me.</p></pre>p0intl3ss: <pre><p>I am planning on benchmarking both a CPU bound task (a mandelbrot set) and an IO bound task (http static file server) in both go and C# and compare the results.</p>
<p>Not really sure how detailed results about context switches/overhead I will get from that but I saw a youtube video about the go tracer witch might help me out a lot.</p></pre>maus80: <pre><p>There may be or is a class of problems that you can solve with say a million go routines where a million threads would fail, due to out of memory, because threads take more memory than go routines. You won't find that by benchmarking these two problems I'm afraid. So it ultimately is about the style of programming that the system allows you, as a result of the small memory footprint of go routines. If you would address this in your paper, it would stand out imho.</p></pre>ChristophBerger: <pre><p>Concurrency in Go is an excellent book.</p>
<p>To get a broader view on concurrency, I'd recommend "Seven Concurrency Models in Seven Weeks" by Paul Butcher.</p>
<p>And as you asked for papers, here are two summaries of papers around Go's concurrency model by "The Morning Paper":</p>
<p><a href="https://blog.acolyer.org/2018/01/25/a-static-verification-framework-for-message-passing-in-go-using-behavioural-types/" rel="nofollow">https://blog.acolyer.org/2018/01/25/a-static-verification-framework-for-message-passing-in-go-using-behavioural-types/</a></p>
<p><a href="https://blog.acolyer.org/2017/02/02/fencing-off-go-liveness-and-safety-for-channel-based-programming/" rel="nofollow">https://blog.acolyer.org/2017/02/02/fencing-off-go-liveness-and-safety-for-channel-based-programming/</a></p>
<p><em>(edit: typo & wording)</em></p></pre>k_z-: <pre><p>Compare with Ada concurrency model.</p></pre>forfunc: <pre><p>I think it's good to compare against java, elixir.</p></pre>p0intl3ss: <pre><p>I was thinking about comparing it to C# simply because it is one primary programming languages.</p></pre>Antshockey: <pre><p>Erlang/Elixir have message passing and soft threads. Certainly worth comparing with Go. C# is a lot more traditional for comparison though </p></pre>forfunc: <pre><p>That's a good comparison aswell instead of java. I would try to include OTP and elixir/erlang because it's also build on the concept of CSP, only way different than how go does it. Could be interesting for a thesis on what the actual differences, up and downsides of the implementations are.</p>
<p>Note that english is not my first language, sorry for any grammar mistakes.</p></pre>p0intl3ss: <pre><p>Sure would be interesting but probably a whole new topic for a separate theses. I am not sure if I want to go too much into that direction, I am trying to focus on a detailed comparison of go vs classical and not add to many extra languages.</p>
<p>English isn't my first language either.</p></pre>Thaxll: <pre><p>Possible shortcomings of go:</p>
<p>If your OS doesn't support async operations for low level things like I/O you will have a bad time since the scheduler starts an OS thread whenever something blocks.</p>
<p>In reality it's not a problem since all modern OS support async operations.</p></pre>epiris: <pre><p>What do you mean? No one “had a bad time” before AIO support for net was pulled in. If you are thinking all system calls cause a new thread to be created that is incorrect, you should read the <a href="https://golang.org/src/runtime/HACKING.md" rel="nofollow">HACKING.md</a> file in the Go runtime folder for clarification.</p></pre>
