Why I refuse to program in Go
Table of Contents
Prologue
I've been stuck in a dilemma lately, I am working in a side project
where I am using tshark but I need a wireshark feature,
well… not at all, I need a specific feature that could be easily
built in termshark (So yeah… I need a wireshark feature
anyways). My point is that I could build a new feature in termshark,
which is built in Go, but I do not want to do that due to the Go
programming language. Why not just use wireshark? I do not want to
install wireshark due to its graphical interface and qt
dependencies, I like to live within a CLI environment.
So, I have few options, some are too complex to be considered as options and other are inherently flawed. I am not going to reinvent the wheel making a new tshark frontend, to program in Go, and to use C wrappers in Go to achieve what I want.
Why I refuse to program in Go
It is not a technical matter, it is a privacy and dependency
matter. As stated in Drew Devault's blog [1], Go makes at least one
connection every time a module is fetched, and looks like there is no
way to disable it. Go's official documentation mention that the
variable GONOPROXY should be set with the URIs where the proxy
feature is not desired, however, it also says that the proxy feature
is defaulted to proxy.golang.org if the user defined proxies do not
return a successful response, this do not specify if the same happen
for URIs added in the GONOPROXY variable.
Telemetry
Looks like the Go team wants to add telemetry to Go[2], as if the unnecessary proxy connections are not enough.
My thoughts on telemetry
I think telemetry is a euphemism of surveillance, presented as a necessary mechanism to improve the development of a computer program. I think telemetry per se is bad, why? because it cannot be achieved without overhead, it is intrusive and it may not help at all; all of this done to improve software development, however, projects that use telemetry could be improved by better software development practices and clear goals.
Let me explain, any big project could be improved with a clear set of goals that could lead to good quality forks or at least a good alternative with different purposes, pretty good examples are OpenBSD, FreeBSD and NetBSD. These *BSDs operating systems are a fork of the BSD idea (and OpenBSD a fork of NetBSD), each *BSD has its own set of goals, which help users to find and use whatever suit them better.
Telemetry could be avoided with better practices like better modularization. Big projects like operating systems are a good example, each subsystem is maintained by different people and each subsystem is updated or improved at its own pace, which is not entirely true if a big refactor or incompatible change is introduced, this could lead to a big collaboration to update all or at least most of the subsystems. My point is that a clear and good separation, and modularization of tasks, subsystem, or whatever you want to call it is better that telemetry because each part of the program can be developed by people who need or use those subsystems.
My two previous ideas convey to the idea of collaboration, the main point is that a project with clear goals can work in things that matter to the project, and maybe time to time add features that are not priority, and let other people to contribute or maintained staled or outdated parts of the program on demand.
I think pretty good data can be collected through telemetry[3] like cache misses, the problem is that data like this is ultimately an intrinsic problem of Computer Science or a problem of the specific implementation of a programming language. Cache is a big problem of computer science, and most of the time is outside of our control, it is related to the architecture or operative system in use, I am not saying that data like that is useless, there is always room for improvements, but sometimes we are limited for things out of our control.
Dependency hell and chain of trust
Go suffers the same fate of all new programming language with a package manager: lot of dependencies and blind trust of third party packages (modules in the Go parlance). This is good and also bad, third party modules help to quickly develop programs, but it is based on a model of trust than has been broken several times in the past.
It may be that I am the flawed one
I program most of the time in C, perhaps I am in a C bubble, perhaps it is the correct way to do things, ultimately, everything is a tool and we decide when and how to use them. Even C use a lot of dependencies (Most of the GUI programs), but those dependencies feel curated and more secure, it could be my imagination.
Conclusion
I did absolutely nothing! I wanted a program to export specific
packets from a pcapng file to another pcapng file, after some
research I found editcap (a program part of the wireshark suite)
which does what I want. Nonetheless, this blog post still explains and
develops my thoughts about Go and why I do not like it.