<p>Hi,</p>
<p>I'm a big fan of the Go language and use it as my primary tool for serverside backend or other CLI stuff.
But when I want to write a Desktop App, Go is kindly limited (unless you use cgo, which I find awful in term of performance and portability/crossplatforming).</p>
<p>In the last Golang team survey, we saw a great interest for a GUI library.
My main concern is that Google is designing Go for their use only, and see it more like a "serverside" language only than a true general-purposing language which can build anything.
As this, today I'm sticking with Python or C for building my desktop app.</p>
<p>I took a look at Kotlin also, which Google (even if it's a JetBrain language in fact) tends to market as a "multi-paradigm" (Desktop (JVM or native-binary), Server (JVM or native binary), Android (ART), iOS (native-binary)).</p>
<p>If you look at what Google opensourced, the de-facto language for all their non-web user-apps is still C++.
On the other side, Mozilla is developing Rust and already using it in Firefox (just for the example, I'm not a fan of Rust).</p>
<p>I don't know what time Python makes to switch from "mathematical/statistics/prototypal" language to a great language for the Desktop. Maybe Go is just too young.
But all initiative for bringing Go to desktop seems to fade-off and not be maintained. The only thing I saw for long-term purpose is to do Electron-like apps, which is un-negociable : Electron is the FlashPlayer of 2017.
Rust seems to have already a true binding from GTK+, officially supported, but I think it's more because the GNOME leaders seems to love the language than a real example.</p>
<p>I'm just talking about GUI here, but in fact, the subject is more toward <em>ALL</em> things that clientside need : Audio, Video, 3D engine, Manipulating hardware, etc. And without using Go as "glue-code language" and manipulating C/C++ libraries (appart from cons of cgo, this breaks the safety provided by using 100% pure-Go in your software, and the concurency is not used widely in your C/C++ code).</p>
<p>So:</p>
<p>1) Does Go have a chance out of the serverside/cli world?</p>
<p>2) Without counting your answer to 1), do you see Go as a server-language or a true general-purposing language?</p>
<p>3) Which programming languages and tools do you use outside of the CLI/serverside world?</p>
<hr/>**评论：**<br/><br/>faiface: <pre><p>It's a great myth that Google is designing Go to fit their needs. It's actually also a myth that Go is a Google product. It's not, Go was created by three guys who just happened to work at Google. Later, a whole open source community joined them.</p>
<p>Go is a truly general purpose language. All it lacks is rich libraries for tasks other than servers. However, we need to take into account, that Go is a young language and developing mature libraries takes a lot of time. Languages that posses plenty of libraries for a wide range of different tasks are usually the languages that have been around for a long time.</p>
<p>However, there is a lot of effort. Me and other guys are creating graphics/game libraries, such as Pixel, Ebiten or Engo. There's the Shiny GUI project. Other GUI projects will soon or later appear.</p>
<p>So, as time progresses, Go will have just as many high quality libraries as any other language, we just need to wait a bit. Or contribute to make it faster ;)</p></pre>DenzelM: <pre><p>Uhm, you're directly contradicting Rob Pike:</p>
<blockquote>
<p>Go is a programming language designed by Google to help solve Google's problems [...]</p>
</blockquote>
<p>From his <a href="https://talks.golang.org/2012/splash.article" rel="nofollow">Go at Google: Language Design in the Service of Software Engineering</a> talk.</p>
<p>And further:</p>
<blockquote>
<p>The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google.</p>
</blockquote>
<p>Call it a myth all you want, but Go was designed <em>explicitly</em> for Google, by Google, and you can see it in a number of the language's design decisions.</p></pre>ZicReddit: <pre><p>@fairface Feel free to share your project links, seems very interesting! ;)</p></pre>faiface: <pre><p>Alright, here they are:</p>
<ul>
<li>Pixel (my library): <a href="https://github.com/faiface/pixel" rel="nofollow">https://github.com/faiface/pixel</a></li>
<li>Ebiten (another nice game library, not mine): <a href="https://github.com/hajimehoshi/ebiten" rel="nofollow">https://github.com/hajimehoshi/ebiten</a></li>
<li>Engo (has most stars, but I don't really like it, not mine): <a href="https://github.com/EngoEngine/engo" rel="nofollow">https://github.com/EngoEngine/engo</a></li>
<li>Shiny: <a href="https://godoc.org/golang.org/x/exp/shiny" rel="nofollow">https://godoc.org/golang.org/x/exp/shiny</a></li>
</ul></pre>justinisrael: <pre><p>What is the actual downside you have found to something like github.com/therecipe/qt? Sure it is a binding to a C++ gui framework, but if you don't have to actually use any cgo or C types directly, does it matter? If you get high level access to Qt, isn't that good enough as anything, just like using Python and PyQt/PySide? </p></pre>ZicReddit: <pre><p>Nothing in fact. Just that this is not the first attempt to make Qt (or GTK) binding in Go (look at <a href="https://github.com/avelino/awesome-go#gui" rel="nofollow">https://github.com/avelino/awesome-go#gui</a> and all tentatives that are today, unmaintained). And this kind of initiatives tends to be unmaintained after the first years for all the other I found…
I just have cons against CGo, not against a proper binding of a library written in another language.
I'm playing with this binding actually, and I expect it will survive in the coming years.
If my skills were more polished, I will gladly try to contribute. But I'm more confident in the serverside programming for now.</p></pre>karlmutch: <pre><p>I believe Go has applicability well beyond servers. I used it recently for a make project using raspberry pi and arduinos. It was my first move into the make space and I found the language was completely in harmony with getting out of my way allowing me to learn about a completely new technology without creating tooling complexity, integration challenges etc. No other languages i have used allow that style of skills portability. </p>
<p>For those that adopt go I am convinced by this experience there will be as large payoff, even for domains outside of the stereotype of backends.</p>
<p>Other environments I am familiar with include C++ Java Python C#. I got into the world of Go after getting a role using it, I was also considering jobs using Rust.</p></pre>ZicReddit: <pre><p>Yup, I expect that Go will have a niche in embeded and IoT some day. But even if it's not the same world, it's part of "cli/backend" for me AKA not "user-facing apps".</p></pre>cameronjerrellnewton: <pre><p>when webasm becomes popular I imagine you could use it to write frontend code. It already has some similar features that I love in Javascript such as closures and first class functions.</p></pre>jimmjii: <pre><p>Most people are using go for plumbing AKA replacing Perl, Python or C code with Go on the server. Go will never be anything else because of the its limitations when it comes to writing shared libraries and the limitations of its type system itself, making it not adapted for a large number of tasks.</p></pre>ZicReddit: <pre><p>When you say "shared library", you're talking about the property of library in C to be used in <em>any</em> languages because C binding is easy to do compared to other languages?</p></pre>
