Return to

Golang and Golang Accessories


Continuing from here:

@mini I agree with your comment. It’s really simple to grasp if you come from a Java, C, or Python background. The Language Specification, while worded very oddly at first, is a dream to work with once you understand the vernacular and language of it all.

Some pros of Go are the CLI tools, the standard library, the mascot, and the documentation. I read a while back that the documentation was made and then the language was built.

The minds behind Unix and C designed and built the Go Programming Language. Enough said? :wink:

The CLI tools allow you to grab third party libraries, run the program before compilation, test the program, compile the program, and install the program, among other things. The installation is unique to my experience, as not only does it compile the code into a binary, but with a proper $GOPATH, that binary is added to your shell path, providing you another tool to run on the command line.

The standard library may seem like a strange thing to gush over with a language, but it does a great job at encompassing majority of things you are going to deal with, including web servers and graphics. You can build very high performing and robust applications with a small set of imports. You won’t find yourself in dependency hell or failing to compile on another platform (no unistd refactoring for Windows, for example).

Go is also very well documented compared to a lot of other languages out there. The documentation is on par with, and even exceeds the Microsoft documentation in some respects. You won’t find any lacking components or lacking examples (looking at you Docker and Datadog :rage: ). You have the Go Playground, The Language Specification, Go by Example, and a ton of other options.

Go is also one of the highest paid languages right now :wink: At least in the U.S. So it’s worth learning if you’re looking for a raise, or even to change industries.

If you’re interested in learning Go, I have two recommendations:

The Go Programming Language by Donovan and Kernighan is great. A bit dated, but not by much at this point. However, it is very difficult. I recommend having some experience under your belt. Understanding how accessing the heap works, having a basic understanding of memory management, pointers, and control flow is a must to dive into this book.

If you are a true beginner, Todd McLeod has a fantastic course on Go. He’s worked directly with Rob Pike and Brian Kernighan using Go and really knows his stuff with respect to Computer Science.

The book

The course

Looking forward to your thoughts and experience with the language! What have you built with it?



What is the best use case for Go?

Would you recommend Go for someone who has some basic experience in programming but would still consider himself to be a beginner? :thinking:

1 Like


Systems programming, web development, and development tools (web scraper, command line tool, query, network tool, etc.). Anything that you need to compile and run forever (exaggeration) pretty much.

Maybe, if you’re wanting to spend time learning and willing to rely heavily on documentation you may not fully understand in the beginning, then yeah. If you want to practice a lot with something that’s easy to understand then probably not, I’d go Python or Ruby, first.

Go is more accessible than man pages, but not as accessible as Python or JavaScript, in my opinion. You can’t be intimidated by documentation or pointers, because that’s majority of what you’ll be dealing with lol.

1 Like


Thanks, I’ll keep on experimenting with Python, Java and JavaScript for now since those are the ones I’ve used.

1 Like


Yeah dude, ain’t nothing wrong with those. You can go your whole career with just that in your toolbox and go far :ok_hand:

1 Like


Been using Go here and there for a few years. I’m thinking to switch back to being a Developer again (I’m DevOps now, don’t code too much anymore :frowning: ), used to code C# :smile:. Didn’t ever do anything serious with Go, changing that now. Currently experimenting with writing a simple game engine with Vulkan. So far so good, still not much done, at the “trying to load models” stage. I have lots of ideas to try, including:

  • What can i do about the cgo tax to not faceplant when having many draw calls (heard that gccgo compiler has no such overhead, didn’t investigate too much here)
  • Go is really easy to do concurrency with, and Vulkan lends itself to it well. Imma try to make a baby of these two properties
  • Resource streaming from memory mapped files. I’ll try using the standard library and gob decoder (possibly all resources on a tar file, that is in the standard library too) to see what I can do in that area
  • Try to use the plugin system provided in Go (if I have need/wish I might embed Lua, but that’s off the table for now). I’m hoping to have gccgo binary to handle all the Vulkan interaction, while the regular does game logic, not sure if this will work, if it doesn’t, don’t really care
  • Personal goal is to get better acquainted with graphics programming in general
  • Do some sort of basic sound system, just to have sound. If I’ll have the motivation I’ll try Steam Audio (that’s off the table for now)
  • Try running on Android perhaps
  • Lots more, less complicated things.

The most annoying gripe so far is casting pointers, as sometimes required when working with C libs. Using unsafe + slices, casting back and forth. That code looks about as pretty as a puddle of sick, but that’s only a small amount, so I can live with that.

I’m unsure if any sort of performant engine will be had, as the renderer code is very cgo heavy (well, the bindings are, not my code), and those transformations between Go types and C types don’t look too great for performance, the draw commands look pretty efficient though. Anyway, I’m very happy with how efficiently I can work with this language, happy gopher here :smiley:

1 Like


So, sadly not much. Tax is a result of go having resizable/relocatable stacks, which is a necessity if you want to support a gazillion goroutines… You just can’t afford a 2MB stack per gouroutine like you can with a small number of threads. What happens in cgo is that a new stack is allocated to allow you to call c code that expects a bigger stack and expects it to not move around.

For hi performance stuff at work, we’ve either rewritten whatever libraries we had in native go, or we ended up exposing c++ APIs as servers thus replacing cgo tax with RPC tax.

Sorry for not having better news.

There’s one thing that’s hacky and dangerous but might work for you I you’re really careful. It should become clear by the end of this blog post, but might require some assembly code:



Thank you, that was a great read!

Looks pretty grim, that approach would be pretty cool to play around with though. The Vulkan bindings that I’m using are generated via c-for-go, I could imagine it having an “experimental mode” for generating small stack bindings, might be useful for some, small libraries, not unlike vDSO.

Although it’s reasonable to hope that Vulkan only needs small stacks (it is meant to be as close to the metal as possible after all), I’d be very much afraid to distribute an application with such bindings. Vulkan resides in drivers, meaning each manufacturer will have his own implementation. I’d imagine you could heuristically find a sweet spot, but it might just break on another system with another manufacturer’s drivers. Heck, a driver update (or just an old driver that was not tested) could break this. Who knows what’s in the driver too, different cards might actually have different implementations in there, thus need differently sized stacks. I’d end up like that guy in the blog, with an application that works depending on weather. Unless I just keep my “I’m experimenting here” cap on, probably not a good idea :smiley:.

I’m sort of hoping I’m not going to be pushing any boundaries any time soon and can probably just live with that tax anyway. I have some options. The Vulkan advantage that I have here is, I can completely control how those draw calls are laid out, to the letter. I won’t be stuck suffering a bad fate, there’s some to explore, other than a rewrite. I’ve learned already how Vulkan achieves multi-threading. If I’ll be clever with both reducing the number of those calls and spreading them out well, the worst I will encounter is higher CPU usage, I think :smiley:

Would be quite interesting to find out how much that would be. I’ll come back with some numbers when I have a good candidate to benchmark. That might take awhile though, It’s still just my “since I’ve got nothing better to do today” project. I’m somewhat close to just throwing a bunch of models on it and seeing how it copes, I’d want there to be some decent profiling first, though. I’d like to track it constantly and see what works.

@risk how much improvement did you observe with RPC? Was it a terrible deal-breaker before?



The benefit of RPC approach was that it was a cleaner language neutral API that meant that you didn’t have to rewrite the client libraries or think about memory across two programing languages. It was used to wrap higher level abstractions to go idioms.

You’re paying for serialization/write/deserialization/read, typically you can avoid mallocs by using syncpools and arenas and other stuff.

It’s very dependent on the rpc framework … try to benchmark it

I think for your use case if you could come up with something that expands the stack to e.g. 2M and can have a couple of pointer dereferences (blind jumps into c code) , it’ll definitely be more performant… And potentially a good candidate for a contribution to golang. It’s doable as long as you’re not expanding the stack of more than a handful of goroutines

1 Like