After learning Go, what made you stay with it rather than use a different language?

autoferrit profile image Shawn McElroy ・1 min read

What language features made it worth it to stay? Or what about the tooling or community made it stick?


markdown guide

I never "learned" Go to a great extent, but what made me stick around long enough to get something done was finding a library that was written in Go and really wanting to play around with it. Go seems to have a lot of great applied tools.

Also, the Go community seems awesome. I want to get more immersed for that alone. I'm jealous of everybody at GopherCon right now.


I was into Python a long time until I heard about Go a few years ago.

I code in Windows. Go was an immediately useful to me as a Windows user because I didn't have to worry about weird ecosystem things (Python requiring Admin to install, Python requiring prepackaged science libraries). Also Go was awesome because packages were so much easier to understand and create (just upload to Github with a header "package X"). And with Go I could write programs that my non-dev friends could run (Python required me telling them to install Python, pip, x, y, z, etc., whereas Go I just sent them a binary).

Despite the negative press, I also love GOPATH. GOPATH lets me essentially work "in the cloud." Since almost everything I do is in the GOPATH (this has never been a problem for any of my many projects), I can rest assured that I can easily delete the entire directory and bring it back up with a simple "go get".

In Python there are too many ways to do tooling - too many testing paradigms, too many packaging paradigms, too many formatters (though its starting to come to a head). I love that in Go, all of this has been done, and its done well because I never have to worry about these things and actually I tend to enjoy writing tests, making packages, formatting code.

This is more of a Python vs Go, but that's my experience. I will say I still love Python, and the one thing that keeps me from writing Go only is that its so much easier to do JSON in Python (Go requires building structs beforehand and it becomes inflexible unless you want to give into reflection).


I actually like the GOPATH setup too. i already had something similar so it was easy to go with


How is that better than rust's cargo or node's pnpm?


Personally, I do like GOPATH a lot better than node_modules because of the global dependencies. In NPM you have a dependency repo for every project which is not so bad, except the culture of Node is to have a module with 3 lines of code and 300 lines of tests so every single project has hundreds of MB's of node_modules... I also like GOPATH a tiny tiny bit better than .cargo because I only have to keep track of one directory (GOPATH) instead of two directories (.cargo and whatever directory I'm currently working in).


I have two favorite parts about Go.

It's opinionated.

If the Go team doesn't like a certain practice, they don't let you do it. For instance, the Go team realizes that any code that relies on a threadID is unsafe. So with their built-in (and ONLY) way to execute something asynchronously, they don't provide a goroutineID to cancel it. Instead you must use external means (a shared boolean, channel, context, etc) in which you periodically check to see if the goroutine should exit, and gracefully return if it should.

It's a good mix between higher and lower level programming.

It seems like Go's philosophy is that anything that is simple, but extremely error prone, should be abstracted away.

Go has pointers, which are generally considered pretty low-level, despite how simple they really are! In C/C++ they can get really complicated though. You need to make sure your pointers to the stack are never used out of scope, and you need to free your pointers to the heap.

In Go, there's no "stack pointers" or "heap pointers", all pointers can be passed along to anywhere, returned, stored, etc. The compiler puts the variables on the stack if it can, otherwise puts it on the heap. That way, if you type &value, it will be a pointer to value, and you can safely use it anywhere. Go is also garbage collected, so no need to free your memory after using it!


A project requirement made me use golang. I discovery that golang is more productive and efficient than c and c++ (stupid pointers).Compilable, efficient, concurrency, garbage collection,certain ecology made me choose golang.


It's simple and performant. That's it. You can start coding from day 1


I didn't like it in the beginning, it took me a while to decide to invest time in it. On the surface I didn't like the GOPATH requirement, neither the error handling, nor the strict typing system that much.

I decided to give it another try and stuck around. The GOPATH I still hate, the typing system can be a pain with json, the error handling can be verbose but it makes sense.

The standard library is great, they recently introduced a nice alternative to the GOPATH, the binary compilation is so handy, you can fit it in Docker images sized 15 megabytes, and it's fast, you notice it even with web apps that are mostly io bound. Deployment is also quite easy, you just need the binary.

Try brew install influxdb which is a time series db written in go, basically the only thing that is shipped is the binary ☀️

I don't think Go fits everything but I would define it as fast general purpose language with a great standard library and short compile time.

ps. I don't think I still understand how to use interfaces properly yet but that's just me 😂


Honestly, Go has been the easiest of the bunch of languages that have propped up in the last decade or so.

My main takeaways are

  • It doesn't surprise you.
  • Code is instantly readable (or, you can write really beautiful code in Go)
  • It all bottles down to one little binary when it's time to run it.

Switched from script languages to Go on production servers and never was so happy before.

Go is simple, statically typed, has minimum magic under the hood. For most parts if you wrote something, didn't abused pointers for no reason, tested it, than it would work just like you designed.


I absolutely love that it's just so easy to read. You take someone's project, open it up and can understand what's going on in a few moments.