Why Go is doomed to success (updated)

TL; DR Golang was designed specifically to thrive in large projects that write large groups of programmers at various levels, and there is no such group in the world more than the open-source community.

Absolutely everything in life is based on compromises - the first law of thermodynamics proves this, and programming languages ​​are no exception. Compromises in Go are not unique, but precisely because of their successful combination, Go happened . The laws of physics also claim that every action generates opposition, and with increasing popularity, the amount of criticism of the language also increases, sometimes justified , sometimes not very much . Let me explain why I believe that this criticism is not important, and Go is doomed to success no matter what.

Raison d'être

To understand why Go is what it is, first you must understand the reason for its appearance.

The goal of the Go project was to eliminate the slowness and clumsiness of software development at Google, and thus make the process more productive and scalable. The language was developed by people and for people who write — and read, and debug and support — large software systems.

( source )

This is the only reason for creating Go, and no more. It was not a 20% entertainment project that accidentally hit the stream; it was not an attempt to achieve something that had not been done before. It was simply created from disappointment with the complexity that was inevitably created by large teams working on large pieces of code written in languages ​​with large feature sets. And every compromise was chosen because it follows these interests. And if you are unhappy with these compromises, most likely your interests simply do not coincide and you do not need to use Go.
')
Although one of the most significant features of Go is compilation speed or easy concurrency, the main feature that makes Go special is its incredible simplicity. Go seeks to reduce the complexity of large Google projects in all ways, and does so by sacrificing some things — many things — sometimes even principles that you have always considered unshakable, like DRY . Go is not the same as Python or Ruby, which “allow” you to write clear code. In Go, you simply have no other choice.

I will try to portray by example. Go is your friend, but not the friend who asks you not to get behind the wheel after the party, but to call a taxi, Go is the friend who interrupts your party, telling you that he threw all your alcohol out the window. Go does not allow you to abstract yourself in the foot ( abstract yourself in the foot. - orig )

The remaining compromises are orthogonal. Yes, Go will not always save you from “race conditions”, as Erlang will do, but Erlang gives you this safety at the price of constantly copying your data, losing significantly in speed - TANSTAAFL .

Me critic

When you read critics, and this applies to many other topics, you can usually divide them into two categories:

1. Complains that Go does not optimally solve the tasks that were put before Go
2. Complains that Go doesn’t optimally solve personal goals

And there really is valid criticism, which falls entirely into the first category. Sometimes it's a matter of preference. Sometimes things are much more complicated than people imagine . Sometimes the authors of Go, who are the same people as everyone else, simply did not do it completely.

But most of the critics I meet are entirely in the second category. And the answer to such critics is always the same: “Go is simply not for you.” Some people see in this attitude the community's intransigence and unwillingness to improve what Go will kill in the long run. They simply do not realize that other people want other things from the language.

A very simple way to detect these discrepancies of interest is to analyze the use of the word “I”. The critic is usually disappointed, because “I” cannot do what “I” want, “I” cannot express it as I want. Very rarely do you hear complaints about what we are doing.

If you are disappointed that the code becomes unreadable after 5 different people have worked on it at different times, or even your own code from the past, then Go is for you. If you are disappointed by the inability to use ClojureScript tricks , then Go is not what you are looking for. If you are disappointed by the impossibility of proving that you are better than others , then Go is definitely not for you.

Open source

But let us leave aside personal preferences, there is one group that undoubtedly wins much more Google here from the simplicity and friendliness of Go - this is the open-source community.

Open-source projects exist thanks to community input. A very small number of successful projects created by one developer. In the open source world, you don’t hire your developers, they must come to you themselves, and although you can choose which pull requests / patches to take, the more you get, the faster you grow.

And this is where Go has no equal.

Go shines, in particular, in three aspects:

He encourages learning another code.

If you and I are similar, then you will often look at the sources of other people's projects on Github. Just out of curiosity or need, but you will regularly study someone else's code to understand how everything works there. Sometimes you will find a simple and understandable code, sometimes you have to climb deeper level by level to decrypt the code. Projects on Go will mostly be in the first group.

Even if I am not going to touch the code, I always prefer certain open-source software to another simply because the fact that it is written in Go gives me a sense of much greater control over it. I feel that in the event of any problems, I do not depend entirely on its author, who alone can solve them. And I do not have the same feeling with projects written in languages ​​that I have known for much longer. For open-source projects, being written on Go is already an advantage in itself.

Go makes community contributions easier.

Equal rules of the game also give a special benefit if you are the author of an open-source project. Go makes the process of reviewing merge requests much less tedious. Utilities like go fmt , golint and go vet leave very little space for personal preferences in code formatting. And in general, Go will not allow so easily to turn your project into a monster with a thousand ways to do the same thing. If you have to check the code of random people from the Internet, you do not want a language with tricks and, most likely, you do not want people who are trying to prove how cool they are. You want something as clear and obvious as possible. Perhaps even local error handling.

Go reduces fear of opening source code

This is a well-known point that in order to open the source code of your project, you must either be a rock star in programming or have an ego like a rock star to withstand criticism. And in fact, it does not matter how well you write the code - there will always be someone who will hate it and will be convinced that it has brought it to you. This is a bad moment, which stresses good people doing altruistic things, which is why a huge amount of source codes remain in the dark because their authors are afraid that it is not good enough for the open-source release stage.

The Go code, as a rule, looks ready for public discovery much earlier and faster than in other languages, it gives a much stronger sense of confidence and comfort to the developer, and the community makes simple and small decisions, preferring them to be large and complex. In general, Go dilutes the uncertainty of the developers with a large amount of code that comes out of the darkness.

Final thoughts

Go success, in fact, has already taken place. Many important system software coming out these days is written in Go. OSS companies such as Docker , CoreOS or Hashicorp make revolutions in servers, using Go as the main tool. More and more databases , search engines , http-proxy or monitoring systems appear. Go is already a big player in the world of server software and this only increases its wealth.

If you have a claim to Go, which does not optimally achieve its goals, even reasonable ones, just accept that the language will not be changed. The Go authors team has clearly and repeatedly made it clear that the language is stable and finished for the near foreseeable future. You are late for the party. Some may complain and cry because of this, but this promise not to break compatibility gives a much greater gain in the long run than any conceivable change in language. Breaking compatibility changes, even well-meaning ones, are far from always desired, even in the wild west of Javascript development .

What if you really like simplicity, but a couple of Go compromises just seem unbearable to you? Then, I'm really sorry, you can either continue on with a search for a language that is perfect for your needs, or, if you are talented enough, even create your own language . Who knows, if enough people need the same, it may even get support .

Update Jun 14, 2015

Looks like this article has made some noise. About 40K visits in the first 24 hours, and I received a lot of feedback, direct and indirect. I am not going to argue with the Internet, but I would like to add some belated remarks for those who come across this article in the future.

On the meaning of the word "success"

By the word "success" I do not mean that Go will replace all other existing languages. That would be stupid. By success, I mean that quite a large part of the life of the developers will be, if not writing code on Go, then at least using software written on Go. This is my understanding of a successful programming language.

About the proof of my statements

This article was originally posted on the Golang subredite , and is intended for an audience already familiar with the language. Proving that Go code is simple and easy to support is beyond the scope of the article, and as far as I know, nobody argues with this. My statements may be absolutely obvious to those who used Go, but may look like absolute propaganda for those who don't know anything about him.

I am not competent to formally prove Go achievements in terms of simplicity. I just feel them in my experience. If you really want to know if I'm right, I suggest you go through the Go tour and look at the popular Go repositories on Github. I also recommend taking a look at Rob Pike’s “ Less is exponentially more ” article, where he describes and discusses many of Go’s simplifications.