<p>i have recently hard switched to using arch linux full time on all my systems and not just servers, and felt like contributing and making applications or things to extend functionality within the linux ecosystem, i really am not keen to go back to c/c++ programming as go is so much more enjoyable to code in for me.</p>
<p>I have seen some projects offering c bindings for things like GTK3 etc. So it appears viable to make things but i was hoping someone has experience / feedback on the subject matter. I am not entirely sure what i want to make but i am curious what things would be a no go with golang (kernel is probably a no go for sure).</p>
<hr/>**评论：**<br/><br/>robvdl: <pre><p>I am not sure about the state of Gtk bindings, but I think some pretty decent Qt ones exist now.</p></pre>zanven42: <pre><p>yeah they looked pretty old from the commit log. thanks for Qt tip. </p></pre>epiris: <pre><p>Do you have anything more specific in mind? While much of the Linux user space is implemented in c / cpp / (shell, python and others though not relevant to your post), those are mostly just the primary clients of the associated user space functionality. Many of those systems such as dbus, X and common distro services like kde* have API's to consume that define a language agnostic protocol, or at the very least a local unix socket in var run that you can easily determine the structures needed to interact with. In cases that they don't you will find the CLI util symmetric with the user space library may have mutual inclusion with the system you want to interact with, meaning you can always just exec out to it. </p>
<p>When neither of those options are feasible you then have the various Linux kernel subsystems, devices, drivers, and many other things exposed in the virtual file systems such as sysfs mounted at /sys. You can use procfs mounted in every distro at /proc to correlate most these systems with the current kernel state and /dev for current device driver information.</p>
<p>With all of this I haven't needed to type import C for any of my local system utils I've made over the years. The only area you may struggle with is pure GUI applications, but much of the functionality around the GUI you can get by just exec out to CLI tools like the xdg-tools for basic X11 stuff. You can create simple notifications, do actions on clipboard changes, all kinds of stuff without a single C import. There are binding for Go for many things (xdg has some for example) when you can't get what you want from a shell. </p>
<p>Point is Go is great for this kind of thing. It's more secure in the sense that most every CLI tool is thousands of lines of string parsing with subtle annoying input / output differences and potential overflows laying dormant in them as well. Most everything (99.9999%) done in userspace doesn't need to be in c and the more tools written in Go the better the desktop experience will be. The world doesn't need 20k lines more of while(char) to shit out information already in a file in /proc/ in a more annoying but "readable" format using whatever flags tickled that developers fancy.</p>
<pre><code>cmdname -h
did you mean --help?
$ shutdown -h now
>realize I forgot to unmount my nfs that
isn't in fstab and is offline now anyways
but systemd is the most important diva
in the world and will make me watch
with no ability to get a tty despite
having zero technical reasons why it can't
be accessed at this point in the shutdown
process. Leaving it "waiting for a stop job
to finish", go to bed. Wake up. Same screen
as my mind explodes I turn off my pc and
realize when I reboot that system didn't
close device mapper for the luks part on
my raid array. Deal with latency for 3 days
while my raid array recovers.
</code></pre>
<p>So solutions like <a href="https://github.com/systemd/systemd/pull/5688#issuecomment-291092505">this</a> end up being implemented, a ton of setup / tear down for pthreads just to do:</p>
<pre><code>go func(ctx) { select <-Done() or <-umount() }
</code></pre>
<p>Which much of systemd <a href="https://github.com/systemd/systemd/search?utf8=%E2%9C%93&q=%2Fproc&type=">code</a> revolves around parsing the procfs in all the various places i.e. <a href="https://github.com/systemd/systemd/blob/d74edffa8b9c82a4de30eb2e513cb0411bdec4d3/src/core/umount.c">core/umount.c</a>, supported by <a href="https://github.com/systemd/systemd/tree/dd8352659c9428b196706d04399eec106a8917ed/src/basic">fifty-thousand</a> lines of various string parsing / handling.</p>
<p>Lol. A last note is that any system utilities I write, instead of:</p>
<pre><code>lsblk --format UUID,NAME
ps -o pid,user
top -o %CPU
w --no-header -s
kill -me
</code></pre>
<p>I just stream json arrays of whatever struct the cmd is for and filter / format using a few helper commands in Go or when I want to get a bit more precise I'll use <a href="https://stedolan.github.io/jq/">jq</a> and call it a day. I type:</p>
<pre><code>$ ls $(awk -F<DELIM> '{print $N}' | a | few | more | awks | toss in a | grep)
> ls: cannot access 'yourfilename': No such file or directory
> ls: cannot access 'had-a-space-lmao': No such file or directory
$ shutdown -h now
</code></pre>
<p>Much less these days.</p></pre>kostix: <pre><p>One more point: while I'm a Go aficionado, I'd recommend looking at <a href="https://wiki.gnome.org/Projects/Vala">Vala</a> for your Linux GUI gigs: while not being nearly as much pleasant to program as Go, it's still pretty much higher-level than C and C++ — on par with C# (from which it draws much of ideas).</p>
<p>Vala compiles down to C which uses Gtk and Glib (and other G-stuff), so you get pretty much "native" (in the sense of GTK-native) programs which fit nicely into the ecosystem.</p>
<p>There's even a <a href="https://elementary.io/">whole stab at creating a DE in it</a>.</p></pre>: <pre><p>[deleted]</p></pre>kostix: <pre><p>Thanks for the heads-up!</p></pre>shovelpost: <pre><p>As soon as you introduce C into your Go project, you can say goodbye to many nice Go features like memory safety, good tooling, easy cross compilation, testing, maintenance etc. Of course if you are only interested in Linux, the lack of easy cross compilation might not be such a big deal but you really lose so many other nice things. Personally I'd advise you to stick with writing simple command line tools and APIs in Go which combined together provide the end result. </p>
<p>If you really want a GUI, you can create a new project that acts as a frontend of your Go tools. That project can use any combination of languages. The difference is that in this case, the main bulk of the work will be done by pure Go code and the main logic will not be strongly coupled with the GUI. Another benefit is that in case the GUI becomes too hard to maintain in the long run, the Go tools will still survive and remain usable on their own.</p></pre>Simerty: <pre><p>What are some good ways to have the GUI interact with a go program assuming they are written in 2 entirely different languages?</p></pre>rimpy13: <pre><p>Depending on the application, a JSON API over a socket could work. Isn't that how gocode does it? It's totally likely I'm remembering wrong.</p></pre>daenney: <pre><p>Quite a few tools work that way nowadays, it's actually pretty neat. You can also use net/rpc for this I suppose or gRPC+protobuf etc. Just ensure you use a socket or always bind to localhost.</p></pre>sacado: <pre><p>You can make a .so library written in go and call its functions from a C/C++ frontend, too. Depends on what you are trying to make, actually.</p></pre>StyMaar: <pre><p>It may sounds like a troll, but I'm totally serious : have you thought about Rust for this purpose ?</p>
<p>People often see Go and Rust as competitors, but they aren't, they're just different tools for different jobs. And for what you want to do Rust is probably the best tool out there : you don't have to go back to C/C++, and it's been designed to interop gracefully with existing C code.</p>
<p>If you want to use GTK, you should have a look at <a href="https://github.com/gtk-rs/gtk">GTKrs</a> or <a href="http://relm.ml/relm-intro">Relm</a> Qt, and if you prefer Qt you have <a href="https://www.vandenoever.info/blog/2017/09/04/rust_qt_binding_generator.html">this</a>.</p>
<p>I don't want to look like a Rust Zealot here, because I'm not (I would never advise anyone to do back-end stuff in Rust instead of Go) but this is such a canonical example of “picking the right tool for the job” I couldn't help myself. I hope I don't offend any of you and don't start a language flamewar.</p></pre>zanven42: <pre><p>I haven't looked into rust at all besides what I've read on this sub, and if golang looked futile to use I definetly was going to investigate what rust is like. </p></pre>hobbified: <pre><p>What is a "program for the linux ecosystem" and how does it differ from every other program?</p></pre>zanven42: <pre><p>Linux community more critical of bloat / implementation details and different libraries to potentially work with I'd say is the only real unique things. But I mostly listed it like that incase people would bring up unique problems for Linux or best practices since I am very new to developing for Linux within its ecosystem of libraries etc, and for all I know it might be completely over complicated to run a go backend service doing all the logic with something else running the GUI. </p></pre>itsmontoya: <pre><p>My buddy <a href="/u/OneOfOne" rel="nofollow">/u/OneOfOne</a> has a great <a href="https://github.com/OneOfOne/webview" rel="nofollow">webkit2gtk library</a> for go. It might be a good reference point for you.</p></pre>kostix: <pre><p>May be you could spend your time contributing to <a href="https://godoc.org/golang.org/x/exp/shiny" rel="nofollow"><code>golang.org/exp/shiny</code></a> — this <em>is</em> a "blessed" attempt at creating a cross-platform solution offering GUI experience.</p>
<p>What's exceptionally good about it is that it's Go-style right from the start. That is, you write Go code when working with it, not a set of plugs for an event loop provided by the whatever GUI toolkit.</p></pre>theGeekPirate: <pre><p><a href="https://github.com/golang/exp/tree/master/shiny" rel="nofollow">shiny</a> was unfortunately ditched ~4 months ago afair, I believe there was a post about it on reddit previously.</p></pre>kostix: <pre><p>I fail to find it using the <code>https://www.google.com/search?q=shiny+site:https://www.reddit.com/r/golang/</code>query.</p>
<p>May be you have confused it with GXUI?</p></pre>theGeekPirate: <pre><p>Nope, I used to use GXUI as well (good times), you can check the repo I linked to see it hasn't been updated in ~4 months as well, I must have been wrong about where I found out from though...</p></pre>theGeekPirate: <pre><p>Found a recent message, I'm sure there's older ones, too lazy to check <a href="https://groups.google.com/d/msg/golang-nuts/Gazd5rzJM_s/1AneN5OkCAAJ" rel="nofollow">https://groups.google.com/d/msg/golang-nuts/Gazd5rzJM_s/1AneN5OkCAAJ</a></p></pre>kostix: <pre><p>Ah, thanks. I've read that thread but did not actually got the impression the project is dead.</p>
<p>But it's underpowered, yes.</p>
<p>And actually this means that having more fresh blood in its veins would be a very cool thing to have ;-)</p></pre>theGeekPirate: <pre><p>It's dead as far as using it in production is concerned =c</p>
<p>The author mentions another post for a new UI, you should check that one out, I'm sure the fresh blood would be appreciated there =)</p></pre>cjbprime: <pre><p>I think it's fine.</p></pre>bestform: <pre><p>You might be interested in Dave Cheney's article about this topic: <a href="https://dave.cheney.net/2016/01/18/cgo-is-not-go" rel="nofollow">https://dave.cheney.net/2016/01/18/cgo-is-not-go</a></p></pre>comrade-jim: <pre><p>I've written quite a few linux apps in Go and had no problems. </p></pre>
