Golang and Golang Accessories

Dev Zone Code
, ,
1

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?

5 Likes
2

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
3

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
4

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

1 Like
5

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
6

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:

2 Likes
7

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: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

3 Likes
8

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?

9

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
10

Oh, hi… I didn’t see this post before.

I have some questions about Go in general, I kinda like the idea behind it and being more modern it’s probably (not entirely sure) more likely to have job offers than C++ (which I’m currently learning).

I could duck it myself, but since you guys have a grasp on the language this might be easier…

Is it compiled into machine code / native binaries? Can you cross-compile it(maybe it’s the wrong term, but I mean “compiling into ARM using an x86 pc to build”)?

Is it simple to build from multiple source files? Is it OO like C++ or more functional like C itself?

Should I consider it? (That’s tricky, but I live in Brazil, where Java is absoulte king, but if it’s backed by Google we might see some growth on the next couple years)

11

Yes. And always opts to link libraries statically (does not link to an external library), meaning the binaries are usually completely stand-alone and have no dependencies. Unless there is no other option, sometimes you have to have a non-static link.

Yes, and does it really easily. Unless cgo is involved (ffi of Go), that’s sometimes tricky.

More like C that includes interfaces and GC, and a bunch more features. It has a hint of OOP due to having interfaces, and people make mistakes (one of my friends did this) and write in a similar style to OOP. That’s ugly as hell and that habit should die in a fire, you have to write in a style more similar to C to make it shine. And multiple file building is simpler, they’re picked up automatically.

You’ll learn that Go has all of it’s essential tools built in (compared to other languages, where you assemble your tool set – like linters, test libs etc – yourself for that specific project). Some people argue that you loose ability to choose, but Go has achieved something outstanding - every Go project on planet earth has the same style, and is built mostly the same (maybe structured somewhat differently but still), there is a lot less stopping you from jumping into the project and doing actual work.

IMO it’s going to take over a lot of the system level projects, tools etc. Enterprise be enterprise, that’s going to be Java, C# and whatever for decades more, I don’t expect too much surprises there. I don’t think it will ever take over webdev, unless we’re talking about highly performant and maintainable systems that care about tech of choice, it wipes floor with everything in that regard.

It’s not trivial to find a job with it for sure. Though it’s already exploded in popularity, and I want to introduce my company to it one way or another. It won’t be adopted fully I’m sure (not by a bunch of PHP developers not), there is a part of a system that could use it for. I either want to place myself so I could work with it or go somewhere where I could. I already hinted it to my manager, that I’m able to work on these things, I’ll see where this goes.

1 Like
12

Thank you for all the clarification! Sounds good tbh…

That’s quite impressive…

Heard ppl talking bout having it into google’s fuchsia, like a dash of it in a bowl full of flutter. It’s probably a good thing right?

13

I haven’t heard of that yet! I’ll need to read about it a bit, but from a quick glance it seems there are some challenges to overcome. I’ll watch with anticipation.

1 Like
14

Basically, anything new cloudy is written in Go. (etcd, docker, kubernetes, flannel, cockroachdb, …) . Everything old cloudy that was written in Java is very quickly stagnating and dying off (hadoop, mesos, …)

grpc is super helpful where you need to interface between languages these days

Mostly, like do you expose a write only typed channel+canelable context in an API, or something with an AdderCloser interface?

… or library things that would only exist once (but not strictly), but require initialization from the user, do you write a New that returns an instance, or do you write an Init that sets up the global instance?

… in both of these cases, one choice will make it easier to add one kind of functionality in the future vs a different kind of functionality.

1 Like
15

Coming from Python, I fucking love Go. It had been so long since I had worked with a strongly typed language that I forgot how nice it is. Adding in the decent built-in testing suite and forcing a style so every file I open is consistent really sold me on it. It’s also very easy to pick up - I have had contributions to popular open source projects merged even though I don’t have any professional experience with Go. Its main issue, dependency management, has largely been solved over the past couple of releases.

I cannot recommend Go enough.

2 Likes