Ask HN: Why is Go lang so popular for cloud infrastructure
24 comments
Go is a decent language, with some really good built in protections (great concurrency model), a massive standard library, and a single binary output that's immensely portable (compared to pretty much anything other than C/C++/D, etc).
Those are some of the main reasons... it's great for pushing data with relatively low overhead, and relatively high safety.
Compared to Rust, you could do very similar, but the language is a much larger break from what most are used to.
Compared to Java/C#, you don't have a relatively large runtime to install, not nearly as portable. I really like C# myself, but it's not for all use cases, and the framework need make it a poorer choice for infrastructure tooling. Also the concurrency model is more transparent in go... in C#, for example, you can use pooling techniques, but they take more thought and planning. Java has a history of huge overhead and tooling as well.
Compared to scripted languages, not worth even considering.
It really depends on your needs, but the fact is that Go and Rust are fairly new, but build with specific needs in mind and do most of them better than other options, with better safety and more transparent ease of use. Go tends to be better for networking/communications, and Rust tends to be better with interacting on system internals.
This is from a conscientious observer. I haven't had a good use case for either, but may have one for go coming up, so looking forward to that.
Those are some of the main reasons... it's great for pushing data with relatively low overhead, and relatively high safety.
Compared to Rust, you could do very similar, but the language is a much larger break from what most are used to.
Compared to Java/C#, you don't have a relatively large runtime to install, not nearly as portable. I really like C# myself, but it's not for all use cases, and the framework need make it a poorer choice for infrastructure tooling. Also the concurrency model is more transparent in go... in C#, for example, you can use pooling techniques, but they take more thought and planning. Java has a history of huge overhead and tooling as well.
Compared to scripted languages, not worth even considering.
It really depends on your needs, but the fact is that Go and Rust are fairly new, but build with specific needs in mind and do most of them better than other options, with better safety and more transparent ease of use. Go tends to be better for networking/communications, and Rust tends to be better with interacting on system internals.
This is from a conscientious observer. I haven't had a good use case for either, but may have one for go coming up, so looking forward to that.
Compared to Rust the compiler is also really fast.
I think the 1.0 compatibility promise, the simplicity of the language, and great standard library let people focus more on the problem than other languages.
I wrote my own zero allocation xml parser in Go the other day and it is 2-3 times faster than the standard library. It was not difficult to do mainly because I could reference what the standard library was doing. The code is easy to read and understand.
I wrote my own zero allocation xml parser in Go the other day and it is 2-3 times faster than the standard library. It was not difficult to do mainly because I could reference what the standard library was doing. The code is easy to read and understand.
As someone that's not a developer I like Go because I'm able to start fast and get binaries for any major platform without having to install external dependencies.
I code and test on a Windows box and I deploy to Linux without any changes.
You could say the same about Python, but not really. With Python I have to maintain the Python environment anywhere I want to run my software. With Go I only have to maintain it where I compile the code, so the final machine where it's deployed could even not have Go installed and still run my Go silly tools.
I code and test on a Windows box and I deploy to Linux without any changes.
You could say the same about Python, but not really. With Python I have to maintain the Python environment anywhere I want to run my software. With Go I only have to maintain it where I compile the code, so the final machine where it's deployed could even not have Go installed and still run my Go silly tools.
Golang is cross-platform unlike C#, doesn't have a large start-up time like Java or C#, is more mature than Rust and higher level than C/C++. A large part of its popularity was that it was picked up by the python and ruby community, many of whom highly dislike Java, C# and C.
IMO go is all about simplicity with a decent stdlib. Fast, single binary to distribute... Can't go wrong really.
Rust is less seasoned.
C# is fine on Windows, Linux support is second priority.
C/C++ takes a bit more work and skill (IMO).
Java is probably very widespread, but less popular from a publicity standpoint.
Go is equally stable on Win and Linux, decent standard library, easy to pick up for Python, Ruby, Java, C or C++ devs, has a simple deployment model, had a good concurrency model, and provides fast builds. It has its detractors due to features not in other languages, but fits the need for a wide variety of others.
C# is fine on Windows, Linux support is second priority.
C/C++ takes a bit more work and skill (IMO).
Java is probably very widespread, but less popular from a publicity standpoint.
Go is equally stable on Win and Linux, decent standard library, easy to pick up for Python, Ruby, Java, C or C++ devs, has a simple deployment model, had a good concurrency model, and provides fast builds. It has its detractors due to features not in other languages, but fits the need for a wide variety of others.
I think for infrastructure tooling, the single binary output is probably a really big thing over Java (and C#), which have a separate, huge runtime that switching versions on a system is problematic for.
From a practical perspective, building your java app into a single fat jar isn't much different. Yeah, you need java installed... big deal.
Installing Java is a pretty big deal... multiple versions, bigger deal... Also, the runtime is relatively huge. I don't think you'd want to do CoreOS/etcd/Kubernetes tooling in Java.
I disagree, based on my own experience having worked with Java off and on since 1996. It was a big deal then. Today, not so much.
Multiple versions? The JVM is generally backwards compatible. It's pretty rare where an "old version" it is actually required. Plus. Java 8 has been out for over 2.5 years, which is practically an eternity in development time. In the event you do actually need multiple versions, setting JAVA_HOME and maybe your PATH is hardly rocket science.
Multiple versions? The JVM is generally backwards compatible. It's pretty rare where an "old version" it is actually required. Plus. Java 8 has been out for over 2.5 years, which is practically an eternity in development time. In the event you do actually need multiple versions, setting JAVA_HOME and maybe your PATH is hardly rocket science.
You don't have to worry about Java_home or the clr being installed at all... also, you can build it and deploy it wherever... with Java/.Net built with newer tooling, then install it on a server that wasn't updated? That isn't a problem with go...
There's a HUGE class of problems that you simply don't have by using go...
Don't get me wrong... I really like C# (not a fan of Java), but I wouldn't consider using it for a lot of the places where Go or Rust are used very well. Frankly, I'd just assume use node for any higher level stuff, Go for anything node isn't a good enough fit for, and Rust for anything system (Ie os/hardware) related.
There's a HUGE class of problems that you simply don't have by using go...
Don't get me wrong... I really like C# (not a fan of Java), but I wouldn't consider using it for a lot of the places where Go or Rust are used very well. Frankly, I'd just assume use node for any higher level stuff, Go for anything node isn't a good enough fit for, and Rust for anything system (Ie os/hardware) related.
In case anyone who is not a Java dev wonders, "what is a fat jar"?
A fat jar is a single runnable binary. It makes deploying Java super simple and is roughly equivalent to Go's single binary.
A fat jar is a single runnable binary. It makes deploying Java super simple and is roughly equivalent to Go's single binary.
Why I chose Go for a network application, in no particular order:
- easy concurrency with CSP/channels
- decent documentation
- cgo makes it almost trivial to link to C dependencies
- strong UTF-8 support, native distinction between bytes and "Runes"
- multiple return values make it easy to deal with return values and error codes in the same function instead of having to resort to a by-reference parameter to capture one or the other
- has a lot of the simplicity of C, with a lot less of the ambiguity
- gets a lot of love from Google, substantial improvements in almost every release
- easy concurrency with CSP/channels
- decent documentation
- cgo makes it almost trivial to link to C dependencies
- strong UTF-8 support, native distinction between bytes and "Runes"
- multiple return values make it easy to deal with return values and error codes in the same function instead of having to resort to a by-reference parameter to capture one or the other
- has a lot of the simplicity of C, with a lot less of the ambiguity
- gets a lot of love from Google, substantial improvements in almost every release
Performance, easy concurrency, and because the language itself is very "straightforward".
It's incredible standard library is probably the thing that motivates me the most. Beyond that, fast builds, good package availability, easy to compile for multiple platforms and great community support.
There is probably more C# and Java tools than Go. There has been more time for libraries to build up.
But to the general thrust of your question, because that's the problem Google was trying to solve? The built in libraries make it quite easy to write applications that speak HTTP/HTTPS in a reasonably scalable way.
Rust will probably be comparable in the future, but isn't quite there yet. C/C++ remains a bit difficult, although it should become a lot easier if the C++ networking TS makes it in.
But to the general thrust of your question, because that's the problem Google was trying to solve? The built in libraries make it quite easy to write applications that speak HTTP/HTTPS in a reasonably scalable way.
Rust will probably be comparable in the future, but isn't quite there yet. C/C++ remains a bit difficult, although it should become a lot easier if the C++ networking TS makes it in.
C# lol. Anyway its fast and the library is made for the web it just fits perfectly and even has many libs to extend existing applications in other languages easily. Like making stuff in Go for rails apps just works
Because it seems like Java without having to deal with JVM.
Like Java, it is not a good choice... but people stick to what they know.
Like Java, it is not a good choice... but people stick to what they know.
I'm curious... what is a good choice?
Depends of your goal. For low level stuff : Rust.
For scripting systems that are simple to write, Python or Ruby are quite great.
If you want some OO but better, Scala or OCaml are around for a long time and deal with concurrency better.
If you really want concurrency and parallelism, Elixir/Erlang are there and Pony is growing slowly.
They are all better than Go at what Go aim for, without the hurtful decisions. And they are better supported on a wide amount of systems.
For scripting systems that are simple to write, Python or Ruby are quite great.
If you want some OO but better, Scala or OCaml are around for a long time and deal with concurrency better.
If you really want concurrency and parallelism, Elixir/Erlang are there and Pony is growing slowly.
They are all better than Go at what Go aim for, without the hurtful decisions. And they are better supported on a wide amount of systems.
Lots of technical choices are made based on cool-factor, not technical or business merit, especially in startups. Go is often a perfectly reasonable choice... but is often chosen for the wrong reasons.
Can you please elaborate and provide some context?
You can read some of the comments here, e.g. "Java is probably very widespread, but less popular from a publicity standpoint." Java is objectively vastly more popular than Go (just do some Googling), and who cares about publicity when writing code? It's about business results. I don't care what language the website I'm using is written in, I want it to do what I want and be fast and have good UX.
So translated into objective facts that statement is just "Go is cooler than Java."
At DockerCon EU a couple years ago someone who worked in VC firm mentioned that every startup they were talking to was choosing Go. Go is better than Python in some cases, better than Java in others... but in many cases you could just use Python or just use Java and it'd be just fine. Often Python is better (much more libraries) or Java is better (much more libraries, and has generics unlike Go's "let's reinvent all of Java 1.0's faults" design).
But Python and Java aren't trendy.
So translated into objective facts that statement is just "Go is cooler than Java."
At DockerCon EU a couple years ago someone who worked in VC firm mentioned that every startup they were talking to was choosing Go. Go is better than Python in some cases, better than Java in others... but in many cases you could just use Python or just use Java and it'd be just fine. Often Python is better (much more libraries) or Java is better (much more libraries, and has generics unlike Go's "let's reinvent all of Java 1.0's faults" design).
But Python and Java aren't trendy.
What motivates people to pick Go instead of the others which are more stable and seasoned or more performant ?