What kinds of problems is Go good at solving?

<p>As any experienced programmer will tell you when asking about programming languages (I&#39;m not experienced, I&#39;ve asked) &#34;There is no BEST language, there are only MORE ADEQUATE languages for a job.&#34;</p> <p>So here I am, asking what I believe to be the right question. What kind of problems should Go be used for? Are there any aspects of the language that make it better or worse from some jobs?</p> <hr/>**评论：**<br/><br/>shovelpost: <pre><p>Please read: <a href="https://talks.golang.org/2012/splash.article" rel="nofollow">Go at Google</a>. It has all the answers you seek.</p></pre>karl-tanner: <pre><p>There&#39;s so much wisdom in this article.</p></pre>PaluMacil: <pre><p>It&#39;s my favorite for commandline utilities and web-based APIs because I can accomplish a lot within the standard library, which is very good and complete. One of the big advantages it has is simple concurrency primitives, so there are processing services that one might prefer to write in Go. Overall, I find the small set of keywords and simple choices to be good for quickly understanding source code. Good documentation, quick compilation, and static linking into a single file with cross compilation make it quite smooth to develop and deploy.</p> <p>I don&#39;t tend to use Go for desktop GUIs because there is already so much available in either C# or via Electron, but desktop applications aren&#39;t central to what I tend to work on anymore anyway. If I were to be doing a lot of math and statistics, I&#39;d probably use Python. I use C# a fair bit because it&#39;s what I know best, and often I can find a library to use or buy for whatever I need to do. It is far more complex than Go, but when I know I&#39;ll be sorting and shuffling a ton of user defined types, the generics in C# are often too tempting (Linq). If .Net hadn&#39;t come out with .Net Core, the comparison would be a lot more lopsided in Go&#39;s favor, but it&#39;s lovely too.</p> <p>Overall, you&#39;ll only benefit from learning more than one language. Go is simple enough that you&#39;ll (in my opinion) benefit more from the small amount of time needed to learn Go than you will benefit from spending a similar amount of time in a more complex language.</p></pre>allowthere: <pre><blockquote> <p>I don&#39;t tend to use Go for desktop GUIs because there is already so much available in either C# or via Electron</p> </blockquote> <p>Unfortunately, there&#39;s not much in the way of GUI on Go anyways.</p></pre>PaluMacil: <pre><p>While I treasure pure Go applications for ease of other user contributions, I keep various GCC installs around, so I don&#39;t mind Go libraries that wrap C libraries as much as a lot of people do. I&#39;ve played with the hello world app demos of half a dozen Go gui libraries <a href="https://github.com/PaluMacil/misc" rel="nofollow">in my misc repo</a>. Overall, I like Andlabs for the tiny filesize, and wxGo has all the features you could possibly want in a permissive license too! Still, though, for a GUI I&#39;d use a more mature library on a different platform.</p></pre>tmornini: <pre><p>There&#39;s always HTML/CSS/JS + Go backend, all running locally. :-)</p></pre>int32_t: <pre><ol> <li><p>Networking.</p></li> <li><p>Large automation scripts that need long-term maintenance. And due to the amount of jobs, exploiting parallelism is important. The things that typically resort to complicated Makefiles.</p></li> <li><p>Trading engine/simulator, or something similar that gathers large data inputs from outside constantly and you have many non-trivial, customizable state machines processing the data. In Go you can have the algorithmic trading agents to utilize channels for inputs (the time series) and outputs (the orders), rather than messing up too much with interleaved callbacks and globals.</p></li> <li><p>The backend of a text editor. It&#39;s kind of similar to a trading engine. The program receives inputs, processed by various state machines(or a complicated, large one), and some actions must be responded accordingly. All have to (preferably) be done asynchronously or concurrently.</p></li> <li><p>Cross-compilation matters from the beginning. </p></li> </ol></pre>tmornini: <pre><p>Anything that needs to be extremely CPU efficient (though not optimal like C/C++) and make use of multiple CPU cores *even for problems that are not embarrassingly parallel.</p></pre>