Besides building API's what else can I do with Go?

I'm in the process of learning Go because my new company uses it, but I'd like to know what other accomplishments people have released with the language and tools.

---

评论：

nexusbees:

Its possible to write the business logic of a mobile app in Go and then ship it on with only the UI written with native APIs. An example of this is Ivy - App Store and Play Store. Its a little cumbersome to pull off right now, but I think it will get easier with Go 1.6 and beyond.

You can find a bunch of cool Go projects at this page - awesome-go. My favourites are


Bolt - an embedded key-value store, inspired by LMDB.

A bittorrent client

Docker and Kubernetes, used for managing containers.

etcd - A highly-available key value store for shared configuration

And as mentioned by someone else, hugo, used for creating static sites.

PaulCapestany:

Somehow this is the first time I'd heard of Ivy... very cool.

PaulCapestany:

Besides awesome-go, this is another way to get an idea of interesting projects being built with Go:

https://github.com/trending?l=go&since=monthly

Also, if you like listening to podcasts, TheChangelog is a great podcast where developers of cool open source projects are interviewed and discuss what they're up to. Here are the episodes that are about Go projects: 

https://changelog.com/tagged/go/

cryp7ix:

Is the frontend code for Ivy a, or any other mobile gui available? I think a couple of good solid examples could really kick this off.

nexusbees:

I couldn't find the source for the mobile apps, but there is a talk that explains the process by Hana Kim. Some details have probably changed since she gave the talk though.

fr4nk3n:

The code for Ivy is available HERE

google_you:

You can write a compiler in Go

BoTuLoX:

Well it's shining on everything that's infrastructure that doesn't absolutely require well-written C levels of latency and throughput, Hugo has done a great job at promoting static sites where people used to roll with PHP and it's also found a niche among command-line tool development.

To mention a few.

DualRearWheels:

Sadly, you can't write competitive OpenGL games (calling C functions has significant overhead). If there was a way to use Go with C without overhead (even in thread/goroutine "simplified" mode) this would be near perfect language.

lapingvino:

Wouldn't it be possible to implement OpenGL completely natively?

DualRearWheels:

"OpenGL is a C standard, all OpenGL implementations only have C interfaces."

https://groups.google.com/forum/#!topic/golang-nuts/x-OoOlxi3o0

I don't know if it is true but I never met any native OpenGL lib in language other than C or using C bindings. I guess it is a huge undertaking to make it, and it would require constant updating as specs change.

Anyway, removing CGO overhead might benefit Go significantly. I don't know what are exact limitations.

On a side note, by using gccgo (gcc Go compiler) seems that there is no overhead, which is encouraging.

storm14k:

Has anyone done any benchmarking around some worthwhile game code to get a real world idea of the impact? I've been toying with OpenGL development in Go but haven't come anywhere close to anything complex enough to judge the bottleneck. I was mainly aiming to learn OpenGL and how engines work under the hood and considered moving to an established engine to work on games. But I like Go so much I'd like to stay and build out my own purpose built engine.

DualRearWheels:

Similar thread https://www.reddit.com/r/golang/comments/3w42nq/the_cost_and_complexity_of_cgo/

storm14k:

Thanks that's exactly what I was looking for. I'd been looking at the Azul project. I'd also been thinking about doing my work in C since most of the material I've been reading is C based. But for the stuff I'd be capable of doing in my spare time Go is probably fine. 

hesdeadjim:

I would love to experiment with taking a command buffer approach to C interop. The last rendering backend I did actually "rendered" commands into an API agnostic command buffer and then submitted the entire batch to the actual renderer backends. Taking a similar approach, one could do the command generation on the Go side and then pay the cost of crossing the language barrier once instead of each call.

DualRearWheels:

Yes, I tried something similar, instead of eg. 100 x glMultMatrix I would store 100 matrix data in buffer and call C function once that would go trough buffer and do the job. This avoids C overhead, but loading buffer adds overhead too. I didn't do comprehensive tests as I doubt it would work satisfactory with heavy load.

pkieltyka:

everything.

howeman:

A group of us has been building scientific libraries for Go. (github.com/gonum)

gopherGator:

you can build API that builds APIs ?