I love Go. And I also hate Go (part 1)

I like Go from the beginning. Similar to C and Java, I feel very familiar with the examples, the tutorials are easy to understand so I can write code right away. I have wanted to study Go because of the popularity of this language in the last few years.

I Love Go

My first priority is to try not to become too stupid. I learned this from the real dev Go: they don't need to ask too many questions to be able to code. They do not follow any instructions. When I realized that the sensitivity of the 80-column width was not so interesting, I searched for 1 line length max. But no. However, I later discovered gofmt – a simple tool that Go recruited to free dev from the tyranny of the language's syntax. It supports Go code and brings it back to One True Style. I love it. I was born in the mechanical industry with an accurate style guide but any style guide has holes. When the moral "faction", style propagators face those who see the guide as living material. I have updated .vimrc from previous generations to gofmt. Go "dictators" are becoming my own authoritarian style.

One of the reasons I give up C ++ (98, 11, and 14) is because it is becoming more and more colorful. Meanwhile, Go is completely simple and this is exactly what I want. Libraries and examples are easy to understand. Error messages are not difficult to understand (in other words, they quickly resolve the confusion of methods with "pointer receivers") while opposing it, Rust has errors reading errors that cannot be solved. like floating.

The reason that Go is not inherited (like other OOP languages) is actually very easy to explain. Its interfaces are both meaningful and practical. You do not need to define a structure to implement an interface. You can use an interface to describe whatever is executing it. Simple, right? This feature is especially useful when you test. In a chaotic environment with components over control, you can apply interfaces to other people's code and then experiment.

The tool chain is also very easy to use – this is also the benefit of starting from zero. The tool chain will help you compile, test quickly and integrate easily with a good scale ecosystem. I no longer worry about dependencies, rebuilding … knowing that when Go runs, GO will find extremely fast errors wherever I have run those errors.

And I also hate Go

Go is a "stubborn" language. Most successful products are clearly delineated about what they are, what they don't have; while Go is a special individual. I was fascinated by Go's obvious characteristics, but for some arbitrary devs it would be weird and unpleasant.

After reading the official documents, I found myself in the middle of the phase being started with the phrase "is GOOS designed for plan9" (Plan-9 is an operating system, the new version of Unix, this project has not yet been determined to be true or not. Wow. As a nerd who studies the operating system, I feel a bit unfamiliar with this thought, but I have never seen Plan 9. I know that speculation about Plan 9 is to gather and create Golang. . It's great that their pop audiences don't stop them from solving the old B-sides. Although oddly, there is nothing wrong.

I want to test an immutable function, how do Go perform the assertions? Hey, you're a programmer. That's how it works. The authors Go always insisted on abused resources so often they refused to provide them. Therefore, some people use one or several libraries that can run.

I created an infinite recursion and got stack overflow. Go only for the first 100 frames stack. You can change it but I can't specify how to do it ("Go Stackoverflow" is the most useless thing you can find, you can search Go and Stackoverflow in turn). Someone might convince me that I only want the first 100 frames, not the last, not the same 4 frames over and over again. Finally I had to use runtime.debug.SetMaxStack () to limit the number of stack. Go has set it up to be too large to catch the proper frames and is too small to perform normal tasks

I tried to use other tools (ahem, DTrace) to print the stack but of course compiler Go ignores the pointers to the stack that the debugger cannot observe. Ditto arguments are based on non-standard ABI calling conventions but that is a different story. The changing environment GOEXPERIMENT = framepointer must be combined with the frame pointers, but to rebuild the whole is really a challenge. All the paths are leading me to a harsh conclusion from a former colleague: Golang is rubbish.

Although it is interesting to write code with Golang, debugging with Golang is not fun. Maybe because I don't know the right tool. But surely there will be no debugger with Go build ability to compile, Go test to testing and Go run to run.

Source: IDE Academy via Dtrace