Ask HN: What's the big deal with Go (Golang)?
Looking to the wisdom of the masses here, and trying to understand the use case for Go (as opposed to other languages).
I have heard that it has faster compile times. I have heard that it's low-level. But I don't get why I should choose it over a language that I enjoy, such as C++ (for low-level control, particularly the modern incarnations of it).
Can you help me to understand what the killer feature of Go is and under what circumstances I should consider using it? Likewise, what would be a poor application of the language?
(Context: I'm not necessarily a language snob. I use C++, Python, JavaScript, Java, etc., and I know which I prefer for solving particular types of problems. I just don't understand why I might need Go. There's a longer story as to why I'm so concerned about using it or not, but that is for another time.)
Thanks for your comments!
19 comments
[ 4.9 ms ] story [ 30.5 ms ] threadas an aside, passing unique build / vcs / version ids as preprocessor directives are a great way to stymie these kind of systems.
I used it for pushing data around on a server and a cli. The easy concurrency was the killer feature for the server, and single binary distribution for the cli.
Another thing about Go is that it is a balanced language in my opinion (both high and low level depending on use case). You can build a cli, a full stack web app or write low level network code. I love it.
For the most part, the build process is very simple, no "dll hell".
Very stable API. With the Go 1 promise, code written 10 years ago still just works.
Others mentioned the statically linked binaries. That's huge. We compile a binary targeting Linux, throw it in s3, that gets pulled to production. Whole thing just works. No dependencies.
Killer "features" of Go:
writing fronttend backend web apps? id go with typescript for react and nodejs.
writing scale efficient backend services, go or kotlin or java makes sense.
writing performance freak modules and software or embeddes or similar, go rust or cpp or c.
you wanna get down to the trade offs. where are you exactly in the stage of development, who your users are, the platforms you are targetting, such and such.
i use typescript. but my ts code imports uwebsockets.js which lets me use a web server written in cpp and c. for caching we use redis. for routing we use caddy.
you wanna take advantage of other languages and premade solutions by other people on where they excell.
[1] https://go.dev/solutions/
A poor application of Golang that I have seen are full featured web frameworks like the ones you find in interpreted languages (Rails, Django, Lavarel, Phoenix, etc).
I feel like Ruby and Python are better & easier for applications that perform text ETL, text scraping, etc.
At the end of the day though, use whatever works for your style. C++ isn't going anywhere. But I am noticing a lot of people talking about the importance of type safety when Rust development was allowed in the Linux kernel.
Interfacing to hardware? Bit-flipping in registers on a peripheral chip? I'd use C++ for that.
Something with lots of dynamic memory usage? I'd at least consider Go because of the garbage collection. That makes an entire set of problems just go away.
Something with a ton of network connections? Again, I'd consider Go.
Something where I need the last drop of performance? C++.
ps: I wrote a data processing benchmark[1] and go is currently leading the charts. I ported it to c++ but it's not performing as expected. Take a look if you have the time.
[1]: https://github.com/jinyus/related_post_gen
1. simple syntax, you can pick up the language quickly and reading code is easy.
2. backward compatibility for 1.0. This has made it easy to just recompile and get any compiler performance improvements.
3. batteries included standard library. Testing, benchmarking, json, xml, http server all build into the standard library
https://github.com/jpillora/chisel https://github.com/DominicBreuker/pspy
When you deploy them they just work. Compare that to compiled C++ code you often face issues with the deployment in my experience. And production machines usually do not ship compilers.