This blog try to introduce the go list command and brief a refinement at go1.16. Moreover, we will explore the differences between go list -m all and go list all, and answer question why some of the module from go list -m all cannot be found by go mod why.
Finally, we will see the x/mod package and when it's useful.
This blog focuses on some practices to manage development dependencies, not library dependencies. Hence, it's not a blog to introduce how Go, Cpp or Rust compiler resolves the libraries to build or the linker finds the dll for linking.
Instead, it talks about how do we manage the tools during development. For example, when using protoc along with its several plugins, how to ensure all CLI tools are used as desired everywhere?
This blog introduces how foldr and foldl work for a better usage them. Understanding the accumulation and association support from them is crucial.
foldr: Right-associative fold of a structure, lazy in the accumulator.
foldl: Left-associative fold of a structure, lazy in the accumulator.
In short, it helps you to construct a left/right associative structure. One of the real cases is you want to construct a left associative structure inside a parser , but you parse it in a right recursive way.
Note that this is a simple note, which has been already covered by documentation, and I wrote it because at the beginning I misunderstand its feature, so I wrote some code to try.
Last time, when one of users asked me "could I set up a 100d in his yaml file for Go time.Duration", my first action is why he cannot search the documentation by himself. But then, another problem overwhelmed my mind because actually I'm not sure about it. I don't know it as well.
After seeing the source code, I got the answer. However, the important inspiration here is: "how to make knowledge cohesive", hence the blog comes. In short, you should understand several concepts here:
By enquiring these questions progressively, you can easily recognize how yaml works in a cohesive way instead of remembering some scattered knowledge about it.
In the open source framework, as long as maintainers can ensure the issues are caused by users instead of the framework, usually they could provide some suggestive guides and prevent themselves from delving into users code.
However, as a company scope framework maintainer, things differ greatly. As you claimed your framework helps them to write better code based on the company platforms, they're likely to rely on the maintainers to figure out some weird issues once it's related with the framework.
This blog records how I help to trouble shoot the weird issue of keeping restarting and failed to deploying caused by the log.Fatalf for our framework users, and my opinion why the log.Fatalf is bad.