PROGRAMMING

Why Golang Is Bad for Smart Programmers

An honest review of why Golang may be bad for experienced developers

Image for post
Source: dev.to

In recent months I use Go for the implementation of Proof of Concept in my leisure time, partly to study of Go programming language itself. Such “Hello World!” programs themselves are elementary and not the purpose of this article, but the experience of using Go itself deserves a few words about it.

Go promises to be the mainstream language for scalable severe code. The language was created by Google, in which it is actively used. To sum up, I honestly think that the design of Go is bad for smart programmers.

Golang — Designed for weak programmers?

Go is very easy to learn, so simple that it took me one evening to introduce it, and then I could write code productively. The book on which I have studied is called Go is An Introduction to Programming in Go. The book, like the Go source code itself, is easy to read, has good code examples, and contains about 150 pages that you can read at a time. This simplicity is refreshing at first, especially in a programming world full of overcomplicated technologies. But in the end, sooner or later, the thought arises: “Is this really so?”

Google claims that the simplicity of Go is a compelling trait, and the language is designed for maximum productivity in large teams, but I doubt it. There are features that are either lacking or overly detailed. And all due to the lack of trust in the developers, with the assumption that they are not able to do something right. This pursuit of simplicity was a conscious decision of the developers of the language. In order to fully understand what it was for, we must understand the motivation of the developers and what they were striving for in Go.

So why was it made so simple? Here are a couple of quotes from Rob Pike, who is one of the sponsors of Go language:

The key point here is that our programmers are not researchers. They are, as a rule, very young, they come to us after their studies, perhaps they studied Java, C / C ++ or Python. They can’t understand an outstanding language, but at the same time we want them to create good software. That is why their language should be easy for them to understand and learn.

It should be familiar, roughly similar to C. Programmers working at Google start their careers early and are mostly familiar with procedural languages, in particular the C family. The demand for speedy productivity in a new programming language means that the language doesn’t have to be too radical.

What? So Rob Pike, in essence, says that the developers at Google are not so good because they have created a language for idiots so that they can do something. What an arrogant look at your colleagues? I have always believed that Google’s developers are handpicked from the brightest and best on earth. Surely they can handle something more challenging?

1️⃣ Artifacts of excessive simplicity

Being simple is a worthy pursuit in any design, and trying to keep things simple is hard. However, when trying to solve (or even express) complex problems, sometimes a complex tool is needed. Complexity and confusion are not the best features of a programming language, but there is a golden mean in which it is possible to create elegant abstractions in the language that are easy to understand and use.

2️⃣ Not very expressive

Due to simplicity, Go lacks constructs that are perceived as something natural in other languages. This may seem like a good idea at first, but in practice, verbose code comes out. The reason for this should be apparent — you need to make it easy for developers to read someone else’s code, but in reality, these simplifications only harm readability. There is no shorthand in Go: either a lot or nothing.

For example, a console utility that reads stdin or a file from command line arguments would look like this:

While this code tries to be as general as possible, Go is forced verbosity gets in the way, and the result is a lot of code to solve a simple problem.

For example, here is a solution to the same problem with not so know D Lang:

And who is more readable now?

I’ll’ll give my vote D. Its code is much more readable as it more explicitly describes the actions. D uses concepts that are much more complex (alternate function calls and templates) than the Go example, but it is really not hard to figure them out.

3️⃣ Copy hell

A popular suggestion for improving Go is a generalization. This will at least avoid unnecessary copying of code to support all data types. For example, a function for summing a list of integers can be implemented in no other way, except as its copy-paste of its basic function for each integer type, there is no other way:

And this example doesn’t even work for signed types. This approach wholly violates the Don’t-Repeat-Repeat- Yourself (DRY) principle, one of the most well-known and apparent principles, ignoring which is the source of many mistakes. Why does Go do this? This is a terrible aspect of language.

The same example in D:

Simple, elegant, and straight to the point. Here is a function reducefor template type and predicate. This is again more difficult than the Go option, but not so tricky for smart programmers to understand. Which example is easier to maintain and more comfortable to read?

4️⃣ Simple type system traversal

As they read this, I suppose Go programmers will scream, “You don’t’ t do it like that!” With the foam in their mouths. Well, there is another way to make a generic function and types, but that completely breaks the type system!

Take a look at this example of a language fix to work around the problem:

This implementation Reducewas borrowed from the article Idiomatic generics in Go. Well, if it's idiomatic, I wouldn't want to see a non-idiomatic example. Usage interface{}is a farce, and in the language, it is only needed to bypass typing. It is an empty interface and all types implement it, allowing complete freedom for everyone. This style of programming is ugly, and that's not all. For acrobatic stunts like this, you need to use runtime reflection. Even Rob Pike doesn't like individuals who abuse it, as he mentioned in one of his talks:

“It is a powerful tool that must be used with care. It should be avoided unless strictly necessary.”

I would take D templates instead of this nonsense. How can someone say they are interface{}more readable or even type-safe?

5️⃣ The grief of dependency management

Go has a built-in dependency system built on top of the popular VCS hosting. The tools provided with Go are aware of these services and can download, build, and install code from them in one fell swoop. While this is great, there is a major versioning oversight!

Indeed, you can get the source code from services like GitHub or Bitbucket using the Go tools, but you cannot specify the version. And again, simplicity at the expense of utility. I am not able to understand the logic of such a decision.

After asking questions about fixing this issue, the Go development team created a forum thread that outlined how they were going to get around this issue. Their recommendation was to just once copy the entire repository into your project and leave it “as it is” “. What the hell are they thinking? We have awesome version control systems with great tagging and versioning that the Go people ignore and copy the source.

6️⃣ Cultural baggage from C

In my opinion, Go was developed by people who have used C all their lives and by those who did not want to try something new. The language can be described as C with training wheels. There are no new ideas in it, other than support for parallelism (which, by the way, is excellent), and this is a shame. You have excellent concurrency in a barely functional, limp language.

Another creaky problem is that Go is a procedural language (like the silent horror of C). You end up writing code in a procedural style that feels archaic and outdated. I know object-oriented programming is not a silver bullet, but it would be great to abstract the details into types and provide encapsulation.

7️⃣ Simplicity for its benefit

Go was designed to be simple, and it excels at that goal. It was written for weak programmers, using the old language as a template. It comes complete with simple tools for doing simple things. It is easy to read and easy to use.

It is incredibly verbose, lackluster, and bad for smart programmers.

Read More

If you found this article helpful, click the💚 or 👏 button below or share the article on Facebook so your friends can benefit from it too.

Bioinformatician at Oncobox Inc. (@oncobox). Research Associate at Moscow Institute of Physics and Technology (@mipt_eng).

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store