<p>I see people complain that Go is still too new or too small. What are some tools/libraries/projects that other languages have that Go is missing? What needs to happen for Go to be considered a language with a robust and thriving ecosystem?</p>
<hr/>**评论：**<br/><br/>brokedown: <pre><p>Go is mature and robust for the space it was designed for.</p>
<p>The big area where it is lacking is the GUI space. There are a bunch of libraries using Go's C bindings to interface with the common popular toolkits, but as soon as you're dealing with C you lose some of go's best features such as cross-compilation. If you have access to every platform you build for it isn't a big deal, but if you're a LInux guy trying to compile for Windows targets its a bit difficult, if you're trying to compile for Mac I'm not even sure that's possible yet.</p>
<p>With native Go (no C bindings) you can compile for any platform Go supports very easily.</p></pre>paul2048: <pre><blockquote>
<p>The big area where it is lacking is the GUI space</p>
</blockquote>
<p>Unless Go ships with something like openGL support in its std lib you'll always need C bindings.</p></pre>Creshal: <pre><p>Nothing wrong with that, tbh.</p></pre>brokedown: <pre><p>Which would be fine, and kind of what exp/shiny was doing. Problems with shiny are that the maintainer abandoned it, and they never got to the point of adding gui primitives. Great for going 3d smoke simulations though.</p></pre>LukeShu: <pre><p>They way OpenGL works at the OS level is that drivers provide their own implementations of libGL, which is: C calling convention. If Go does add OpenGL to the std lib, it would probably just be moving the C binding in to the std lib. I suppose they could do do some trickery to bang out the C calling convention from Go, similarly to with the <code>syscall</code> package.</p></pre>Simerty: <pre><blockquote>
<p>Go is mature and robust for the space it was designed for</p>
</blockquote>
<p>What space was it designed for? </p></pre>Tacticus: <pre><p>Distributed services connecting over well defined protocols doing a lot of work.</p>
<p>Back end services serving external clients. </p></pre>ChristophBerger: <pre><p>I'd extend this to general server-side applications and all sorts of command-line tools. Although I cannot say that this is what Go was <em>designed</em> for, Go is defintely very well suited for these areas.</p></pre>Tacticus: <pre><p>oh yeah command line tools in go are just light years better than most. Not ever having to worry about pip or gems or what version of the run time is on the prod box i need to run it on is just liberating. </p></pre>arp242: <pre><p>I wanted to write a terminal audio player last year; I wasn't able to find a:</p>
<ul>
<li>mature and maintained TUI library. termbox is very low-level, ncurses bindings had some specific issues (I forgot which, sorry);</li>
<li>library to decode compressed audio formats (mp3, vorbis, flac, etc.)</li>
<li>library to deal with the system's audio out in a cross-platform way (preferably through pulseaudio).</li>
</ul>
<p>I believe someone posted a project here the other day with some cool multimedia support, but as far as I could find last year that didn't exist for Go.</p>
<p>All of this is possible in Go of course; just needs someone to sit down and do it. Since this was a hobby project with a limited "time budget" I wanted to get things off the ground quickly. I ended up using Python.</p>
<hr/>
<p>Another issue that bit me very hard is the <a href="https://github.com/golang/go/issues/1435">inability to use setuid()</a>. It was very confusing as I was alternating between my Linux desktop and OpenBSD laptop at the time and was just learning Go. It only works incorrectly on Linux. Took me some time to figure out that it wasn't in fact <em>my</em> fault that files were being created with the wrong permissions!</p>
<p>It's kinda annoying because now I need to run my daemon as root just because I want it to listen on a privileged port :-/</p></pre>jerf: <pre><p>Do you mean you have to run as root in Linux or OpenBSD? In Linux the solution is <a href="https://wiki.apache.org/httpd/NonRootPortBinding" rel="nofollow">setcap</a>.</p>
<p>That does not remotely solve all setuid issues, but it does solve that one.</p></pre>arp242: <pre><p>In Linux; dropping privileges in OpenBSD works fine.</p>
<p>setcap is an option, but it shifts the configuration from the program author – who usually knows exactly what permissions the program needs – to the system administrator. Not a good idea IMHO, for various reasons.</p></pre>jerf: <pre><p>As I said, it does not remotely solve all the issues, but it does solve this one. Using the capabilities system is better than having your program run as root indefinitely. We don't always get to choose the choices that are offered to us.</p></pre>emersion_fr: <pre><p>Using this is better:</p>
<p><code>
setcap 'cap_net_bind_service=+ep' /path/to/program
</code></p></pre>kostix: <pre><p>Re. <code>setuid()</code> — there's little which can be done for this in Go because things like <code>setuid()</code> were invented with single process mentality in mind.</p>
<p>With Go on Linux, you should possibly use the <code>os/exec</code> to spawn <code>/proc/self/exe</code> with the appropiately set <code>SysProcAttr</code> field of the <code>exec.Cmd</code> struct used for execution.
There, the <code>syscall.SysProcAttr</code> contains the <code>Credential</code> field
which can be used to set specific UID, GID and a set of auxilliary groups for the process to be created.</p>
<p>The problem of passing the state between both processes exists
but it can be solved in a number of ways with communicating the data via an inherited file descriptor in some easy-to-parse wire format such as <code>gob</code>.</p></pre>LukeShu: <pre><p>The problem is that Linux <code>setuid(2)</code> <em>wasn't</em> invented with a single process mentality in mind; on Linux it's a per-thread operation (where on OpenBSD, and in POSIX, it is per-process); and since goroutines don't map 1:1 with OS threads. Which isn't really a problem, it just means that we need runtime support that doesn't exist. That runtime support is actually a source of bugs in libc implementations (<a href="http://ewontfix.com/17/" rel="nofollow">http://ewontfix.com/17/</a>), but since the Go runtime is managed, it should actually be simpler there; someone just needs to do it.</p>
<p>The problem with the <code>os/exec</code> approach is that you never fully drop the root privileges; you still have the root parent of the unprivileged process waiting for it; you can't tell it to not fork (<em>grumbles about needing a call that takes the same arguments as <code>syscall.ForkExec()</code> but doesn't fork</em>).</p>
<p>My approach has been to just have a C wrapper that takes care of calling setuid(), then exec()s the Go program.</p></pre>kostix: <pre><p>Thanks for providing this information! I stand corrected.</p></pre>tv64738: <pre><p>The right way to get setuid with Go, or really any heavily multithreaded program regardless of language, is to start a new process with the right uid: <a href="https://golang.org/pkg/os/exec/#Cmd.SysProcAttr" rel="nofollow">https://golang.org/pkg/os/exec/#Cmd.SysProcAttr</a> and <a href="https://golang.org/pkg/syscall/#Credential" rel="nofollow">https://golang.org/pkg/syscall/#Credential</a></p></pre>dinkumator: <pre><p>Robust scientific libraries (scipy, numpy, pandas, etc)</p></pre>chewxy: <pre><p>We're getting there! I've so far used gonum and gorgonia in production level services... and Go has replaced python for a lot of things I do (except the things that require interactivity- jupyter still wins but <a href="/u/dwhitena">/u/dwhitena</a> just showcased something this morning that I think will change the way Go is used in datasciences )</p></pre>kostix: <pre><p>@chewxy is correct: the most visible scientific-related project is <a href="https://github.com/gonum" rel="nofollow"><code>gonum</code></a> and there's <a href="https://go-hep.org/" rel="nofollow">Go HEP</a> ;-)</p></pre>sbinet: <pre><p>There's also (in alphabetical order):</p>
<ul>
<li><a href="https://github.com/astrogo" rel="nofollow">https://github.com/astrogo</a></li>
<li><a href="https://github.com/biogo" rel="nofollow">https://github.com/biogo</a></li>
</ul></pre>qu33ksilver: <pre><p>I recently needed some ffmpeg stuff to do. </p>
<p>I guess a Go native full ffmpeg clone will remain a dream, and I will have to do with <a href="https://github.com/giorgisio/goav" rel="nofollow">https://github.com/giorgisio/goav</a> for now.</p></pre>anacrolix: <pre><p>Why not just exec ffmpeg?</p></pre>qu33ksilver: <pre><p>It's not a very elegant solution. It's similar to running git commands in the shell and parsing the output instead of actually using a git library.</p></pre>anacrolix: <pre><p>I don't see the problem, when the command line interface is so familiar and dependable it's essentially an API. It's also the same regardless of language and OS.</p></pre>mBRoK7Ln1HAnzFvdGtE1: <pre><p>i tried doing this in a home security project i was working on. ffmpeg seems impossible to use.</p>
<p>theres a trillion different arguments and options, and the error messages are literally nonsensical. It would fail to transcode my camera and give vague errors about missing frames.</p>
<p>Trying to get help from others ended in "that message doesn't say enough"</p>
<p>well its all ffmpeg will give me.</p>
<p>It's not wonder 0 people have taken up the effort to write a Go native library for this, its a shitshow.</p></pre>anacrolix: <pre><p>Yeah after years of using ffmpeg I just wrap exec for it for all my projects. My latest project uses it in a lot of fancy ways, but is not open source. Here's an older project that wraps it: <a href="https://github.com/anacrolix/dms/tree/master/transcode" rel="nofollow">https://github.com/anacrolix/dms/tree/master/transcode</a>, and a standalone library that I use from all my other projects: <a href="https://github.com/anacrolix/ffprobe" rel="nofollow">https://github.com/anacrolix/ffprobe</a>.</p>
<p>At least the avconv/ffmpeg fork battle is over (c. 2013?), it was a nightmare when they took different flags.</p></pre>pinpinbo: <pre><p>If Go has a complete and stable libraries for Kerberos and HDFS, it could encroach Java territory even further.</p></pre>techos995: <pre><p>A mature toolchain for mobile dev. <a href="https://godoc.org/golang.org/x/mobile" rel="nofollow">https://godoc.org/golang.org/x/mobile</a> is a nice start, but still experimental.</p></pre>metamatic: <pre><p>It could use a full XPath implementation, followed by support for XML Normalization, XML Signature and XML Encryption. Then it would be possible to support SAML.</p></pre>killbot5000: <pre><p>Just a few generics.</p></pre>drvd: <pre><p>Haha! So cute.</p></pre>ineedmorealts: <pre><p>It's lacking the ability to interact with Xserver</p></pre>kostix: <pre><p>There's <a href="https://godoc.org/golang.org/x/exp/shiny" rel="nofollow"><code>golang.org/x/exp/shiny</code></a>
which makes use of <a href="https://godoc.org/github.com/BurntSushi/xgb" rel="nofollow"><code>github.com/BurntSushi/xgb</code></a>.</p></pre>KenjiTakahashi: <pre><p>In fact, the aforementioned <code>xgb</code> (+ <code>xgbutil</code>) libs by BurntSushi are the best X-comm libs I've ever used. And I've used all C/++, Python, Ruby, Lua ones, you name it.</p></pre>tv64738: <pre><p>I wrote <a href="https://github.com/tv42/quobar" rel="nofollow">https://github.com/tv42/quobar</a> with nothing but a low-level pure Go X11 communication library <a href="https://godoc.org/github.com/BurntSushi/xgb" rel="nofollow">https://godoc.org/github.com/BurntSushi/xgb</a> and it's perfectly doable.</p></pre>paul2048: <pre><p>a SOAP server? in general most of enterprise integration tools, protocols and co. There is a reason why Java steal leads the enterprise space.</p></pre>akerro: <pre><p>Jenkins (history of tests) and sonarQube.</p>
<p>Why the downvotes?</p></pre>nevyn: <pre><blockquote>
<p>Why the downvotes?</p>
</blockquote>
<p>Those both seem pretty niche things.</p></pre>akerro: <pre><p>CI/CD, test runner, graphical representation and tracker of failed/passed tests with detailed notifications about them?</p></pre>nevyn: <pre><p>There are roughly 666 CI/CD frameworks. Jenkins is not bad, but lack of an API to interact with it is not on the same level as "no viable GUI support".</p></pre>
