Author: Chris Siebenmann, Lin Hao
Editor: Zhang Xiaonan
“Go is Google's programming language, not the community? ” Do you agree or disagree with this view? Today, let us start a big discussion on this issue...
A few days ago, InfoQ posted a commentary on the Go blog on the official website (the blogger is a Go contributor to the Go language). Some of the views are “negative”, he believes that Go is Google’s programming language. Not the community. In the blogger's view, although the Go language has a contributor community, it is not a community project, just a Google project. So as long as it is something Google is against, no one can add this thing to the Go language.
After the publication of this article, there was a heated discussion among netizens. There were not many people who opposed it. Of course, some people strongly agreed with the blogger's point of view.
For the discussion triggered by this article, InfoQ reporters also contacted the author of “Go Concurrency Programming” and Hao Lin, the former head of the big data. The point is: Go is everyone's, only fake fans. The talks were abandoned. In Hao Lin's view, the official Go language team is a small team within Google, but almost all of its members are technical gods. So even if Google is dictatorial, we have reason to believe that they will do better with the Go language.
For the discussion triggered by whether “Go belongs to Google or belongs to the community”, we decided to present the foreign blogger and Hao Lin’s articles together. How do you think about this? You can read the original text at the end of the article to participate in the discussion, or leave a message in the comment area.
Go language is Google, not community
Author: Chris Siebenmann
I saw this on Twitter: There are a lot of people discussing Go's generics, why can't we have something like Java OpenJDK, like OpenGo, community members can implement generics themselves instead of waiting Officially launched generic?
Many people have answered this question, but there is a real voice that is not directly expressed, that is: Go is Google's programming language, not the community.
Of course, many community members contribute a lot of important and valuable things to the Go language, as evidenced by the diversity of contributors and submitters. But as the gatekeeper of the entire Go community, Google decides for itself what can be accepted by the Go language and what cannot be accepted.
Even if the community has a process to decide what can be added to the Go language, don't forget that there is a 800-pound gorilla in the room. As long as it is something Google is against, no one can let them join the Go language. Similarly, if Google decides to add something to the Go language, it is imperative.
One of the most obvious examples is what happened on the Go language module system. A member of the Google Go Language Core team abandoned a modular system developed by the external Go community because it used a different model. You can view the relevant history here.
In simple terms, the Go language has a contributor community, but it's not a community project, but a Google project. Whether you think this is a good thing or a bad thing, it is an indisputable fact that we need to accept this fact. If you think there are some important things that can be added to the Go language, then convincing the Go language core team is more effective than trying to reach a consensus in the community.
Contributors put a lot of time and energy into the community, but if the Go core team doesn't buy it, it's a waste of time. The best result is just to let the Go core team know more about these issues.
In general, the voice of the community is not very important for the development of the Go language, and we, outside of the Google Wall, just accept the facts. If you are lucky enough, what we want is exactly what Google wants, and the core development teams at Google and Go will pay more attention to these things and do the work in a timely manner. Fortunately, the Google and Go core teams are also concerned about the success of the Go language in the industry, so they are willing to pay the price to solve the pain.
In any case, the Go language is very good. It has a small core team. This team has a good taste and vision for this programming language, but they can't listen to the outside world, they are slow to move forward, they are not willing to hug. Variety.
I like the Go language for a while, and I am basically satisfied with the evolution of the Go language and the management capabilities of the Go language core team. I think it's not a bad thing to launch the generic function slowly, but the Go language module system event left a bad impression on me. I seem to regret it as a member of the Go language contributor, even if it is just a small change. Also not happy (in other words, I don't want to be a second-class citizen). If I find a bug, I will continue to submit bug reports, but it is also limited to this.
The Go language team claims that they care more about the entire community and want more people to get involved. This argument makes me feel ridiculous. I don't deny that they care about the community, but only care about certain aspects. I think the Go language team is not as good at making small moves as it is to be honest.
Google and Go Language Core Team:
You may ask, is Go language Google or Go core team? Although some aspects of the Go language are set by the core team, most or all of the core team members are Google employees, so it is impossible to distinguish them clearly in practice. If the Go core team has left Google and is actively establishing the future direction of the Go language, then we may be able to tell who the Go language belongs to. If this thing really happens, especially if most people are no longer working for Google, then the Go language may belong to this team. Like Python, Python has always been his programming language for whom Guido van Rossum works.
In practice, it is undeniable that Google provides a large amount of infrastructure and resources for the Go language, such as the domain name golang.org, and the Go language trademark is also on the Google trademark list.
The Go language is everyone's, only the pseudo-fans will talk about giving up.
Author: Lin Hao
1, Go language is open source
For most fans and developers, this is enough. Only those who have had a real contribution can truly appreciate that behind a programming language is "Monarchy", or "democracy", or "Union". But in any case, these programming languages are open source, and the official will respect the technology community that comes with it to some extent.
The current reality is that even if it is “the monarchy”, the creators of open source programming languages will pay enough attention to the community. Just like the Go language and the Python language. In addition, the community of the Java language is actually "union system", which is actually controlled by some technology companies. The community of Rust language is considered to be “democratic”.
2, Go language is paying more and more attention to the community
The official Go language team is a small team within Google. But almost all of its members are technical gods. Even if they are dictatorial, we have reason to believe that they will do better in the Go language. What's more, after the Go language team went through several versions and solved some key functional and performance issues, they also began to pay more attention to the community.
Of course, differences are inevitable because the Go language has its own mission, vision and values. Moreover, the Go language team's energy is limited. What I am seeing now is that the Go language team has begun to actively address some of the issues that the community is most concerned with, such as error handling and generics.
3, only the pseudo-fans will talk about giving up
If we change the angle, then we will find that only the pseudo-fans will talk about giving up. For example, we can divide the players who watch the game into four categories, namely: true fans, pseudo-fans, researchers and bystanders. Real fans will support the team they love. Even if this team is often at the bottom of the league, they will be like this. The fake fans are just pretending to love. They usually only support the good teams they think and the good players.
Only the pseudo-fans will frequently change the team he supports. For researchers, they are not watching the game, but the tactics, strategies and trends behind the game. So for them, I can't talk about which team I love. The onlookers only regard watching the game as a pastime. As for whether it is a basketball game or a football game, it is not so important. What they want to experience is something else.
Only true fans and fake fans will complain that a certain team is not satisfactory. But the difference is that true fans will continue to love and support after complaining, and pseudo-fans are likely to leave.
It is similar for programming enthusiasts. If you are a pseudo-lover of a programming language, then what you complain about is that the language does not have a certain feature or does not develop in the direction you imagine. And, after a few complaints, you are likely to move to other programming language camps. Although there is no good or bad relationship between true and false enthusiasts, it can affect your position in a technical community to some extent. Pseudo-fans often only wander around the edge of the community. The career development of frequent job hoppers is usually not very good, isn't it?
In addition, if you want to eat multiple programming languages, then develop yourself into a researcher, not a pseudo-lover.
4, the process is more important than the result
In the open source community, we should focus on the process of participation rather than the outcome of participation. What we are concerned about is: What capabilities have been enhanced and what opportunities have been gained through active participation. If we only pay attention to the results, then we are likely to be disappointed and even get nothing. Because every community has a system for each community. These systems may be justified in the eyes of some people, but may be unreasonable in the eyes of others. This is normal, and the angle of view of each person is almost the same, especially under the control of certain emotions.
Therefore, staring at a single point will only make you more entangled, such as “I hope that the Go language can increase support for custom generics”. Although the Go language team has begun to design generics, I think that many people have become blamed for it, and they continue to mourn every day, and some still leave in anger. This is completely unnecessary, isn't it?
In short, although the Go language is Google, but more importantly, it is an open source programming language. Like Java, Python, Rust, Julia, etc., they are all developers. At least we can use it for free and have the opportunity to participate and contribute. They are only different in the way the community is institutionalized and collaborative.
If we can observe at a higher level, we will find that we are consistent with their wishes, that is: I hope it will develop better and be closer to the higher peaks. As a non-core person, what we have to do is to actively participate and enhance our ability.