Google killed Golang. With a snap.
I've always been a big fan of Golang, the compiled programming language that Google created several years ago. It's a simple, high-performing language, it has a fast learning curve, and for an architect who wants to make a prototype, it's perfect. Sadly, google decided to kill it.
Before we talk about the why and what, let's talk about the how.
Every company has a "core business". The departments that have the core business are the "politically" stronger ones, the others suffer them. For example, the department that was responsible for Kubernetes obviously got a lot of exposure for google, which helps google, but in the event of a dispute with the core business, they would be fired.
What does it mean? It means that in case there is a lean period, there will be cuts: but they will NEVER impact the "core business". The other departments will always pay.
Now, Google's core business is to collect data and process it, both for private users (i.e. for advertising) and for US government agencies, who access Google systems (by law, in the US) and who buy (in "covered" way) the datamining systems, to process the data, in this way funding google. This latest income should not be underestimated, and there are those who think that the US giants could not live without the money from government agencies.
For this reason, the product or department that doesn't collect enough data is cut. You can find the list of products not collecting enough data here:
This "google graveyard" is the list of products which, due to lack of commercial success or technical characteristics, did not collect enough data for google to satisfy google's core business. At the moment of contention, that is, at the moment of distributing the budget to the departments, core business prevails and they are closed.
Core business doesn't always affect other departments this way. Some have the ability to amend, and start collecting data. An example, the one I'm talking about in this post, is golang, the programming language invented by google.
What happen? It happens that "core business" has forced golang to place instrumentation for telemetry in the compiler, and consequently also in the runtime engine of the software you compile with that compiler.
In practice, not only does google want to spy on the programmer, but it wants to spy on those who use software written in golang.
Here is the thread discussing it:
https://github.com/golang/go/discussions/58409
As you can see, first they try to convince everyone that “it would be good for programmers” (although golang already comes with a profiling tool), but they try to prove things like “GDPR only applies if you manage PII”, urban legend widespread in the USA, which has led to many misunderstandings:
All the discussion takes place in bad faith, and it is visible when it comes to opt-in and opt-out.
Providential users who call themselves "programmers" argue, in fact, that it would be better for the programmer if the opt-in were automatic, while the opt-out was voluntary.
- opt-in is the process by which the compiler starts spying on you. According to google, it must be the default, unless you disable it.
- opt-out is the process by which you stop using "telemetry", ie espionage, which must be voluntary, ie requires an action.
Why is it essential? Because a lot of the software you find on github, or even in my repository, is written in go and in the Dockerfile to create the image it just does “go build”. This means that, tomorrow if the compiler opts-in by default, all automatically compiled open source software will start doing telemetry.
In short, since open source software does not spy (or spy less) on users because the code is readable, they put the malicious code in the compiler and place it in the runtime at the time of the competition.
What do I think?
Let's get down to “why” this is wrong. The problem is that there are worlds (enterprise, corporate, telco, gas&oil, etc) where there are IT departments, which create rules to guarantee, if not security, some good practices that guarantee security.
A widely used architecture, for example, is the "3 tier" one, i.e. each system schematically looks like this:
As you see, Tier 1 has so-called frontends, (behind a firewall of course), which act as a separating element. Then, behind a second firewall, there's the business logic, which you maybe call "backend" when you say you're backend developers. Finally, behind another firewall, there is the data, i.e. the new oil.
The user is on the left in this diagram.
As you can imagine, the backend NEVER connects to the internet. It can read the database, but if it wants to communicate with the outside because it is necessary, it does so after asking for a "Security Exception", and through an outbound proxy that must necessarily be found in the frontend area. And it must have security tools, i.e. the firewall only lets it go in certain places.
I know programmers are now going to tell me “muh microservices”, and my answer is that you either stick them in the transaction tier or stick them up your ass, and no architect, operations department or security department cares about your opinion. At least, in no serious company.
Another way is to have multiple zones, and a real matrix of connections. You can think of this:
obviously, depending on the zones, they may or may not communicate with each other. It's a more modern, more flexible approach, but bear in mind that all beige sausages are, in fact, firewalls. This makes you realize how much paranoia there is.
After google puts its spyware in the compiler, we'll have to go and ask companies to put software into their networks that wants to talk to the outside world, from anywhere in their network.
You know what the operations and security departments will tell you? They will point you to the sign at the entrance to the department:
The telco world is even worse, because it is based on three concepts: inband, outband, offband. And there is a rule written and repeated by the LAW in all European countries, according to which ANY control plane system is offband. Ditto for anything that looks like it.
In practice, all OSS, BSS, EMS, and all administration and control interfaces must be offband. And there are plenty of firewalls and alarms about it: no one must enter from outside.
So imagine that at a certain point someone (for example: https://opennetworking.org/ ) finds himself with entire stacks written in golang, which he has to convince telcos (through system integrators or consulting firms) to place on the net. The 5G network is full of these middleware, and if you walk around the site you notice that they are written in golang.
Moral: they migrated from python to golang, and will now migrate to something else.
The problem of trust.
Sure, for now google offers a method to opt-out, but in the future it may change its mind. The trouble is that no manager or department wants to be caught out by a sudden decision by google, and have to migrate at any moment: consequently they will think about migrating away from golang, slowly, but preemptively.
Congrats google, you just killed your new language. And no one will notice, because having a 3% of the global market share, his death will go completely unnoticed.
Just another gravestone in the google graveyard.
So far the telemetry tool has not been inserted yet. There are other companies, like Apple, that have put the telemetry tool into their programming language. Guess how many corporate, enterprise or telco companies find languages written in this language that starts with s and ends with t. Apple. Point.
Mitigation.
There is also another go compiler, by LLVM, which is opensource and uses part of the gnu compiler. The first thing to do, for those who have to publish patches and more, after inserting the malware in the compiler, will be to keep the code but change the compiler.
https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gccgo/
Some code changes are needed, but it's financially viable.
Since google is also known for patent harassment, the moment is visible on the horizon when google will decide that golang is only its own. So this is a mitigation tool but not a solution.
The only real solution is migration.
towards where?
Given the type of backend written in go, there are languages "naturally" suitable for replacing it. Let's see them.
| Language | Pros | Against |
| Rust | Golang-like toolchain, safe threads, as efficient as go. Open source. | The programmer has to think a lot. It takes programmers with brains. They cost more than javascript or java monkeys. |
| ADA | It has evolved a lot and is comparable to golang. It is much safer in every respect. Produce efficient executables. It is highly tested and used in the aerospace and mission-critical world. He still has a huge fan base. Open source. | The programmer has to think a lot. It takes programmers with brains. They cost more than javascript or java monkeys. |
| C++ | It evolves continuously, moving away from C, and in terms of code efficiency it is practically unbeatable. It has an immense cardinality, which translates into an immense power. Open source. | The programmer has to think a lot. To use the latest versions it must be the equivalent of a Mandarin Chinese. It takes senior programmers with brains. They cost more than javascript or java monkeys. |
Personally I'm undecided between these. After all, one does not exclude the other, depending on the area.
What will happen to Kubernetes , Docker and all other systems written in golang?
Well, the thing is, when it comes to security and GDPR, customers get hysterical, and tend to get rid of the inconvenience. If the possibility of ending up in trouble because of these telemetries is aired, or will be aired, they will either demand (if possible) that everything be compiled without telemetry, or (when it will no longer be possible to opt-out) , they will simply migrate to something else.
