Go standard library provides os pacakge to trackle with os related concepts, for example, the working dir. Working dir is a os level concept rather than a concept maintained by os package. Indeed, os package doesn't reinvent the wheel but rely on the operation system to tackle it.
Working dir is a concept for a process rather than an executable. So statement "the working dir of binary ./bin/server is ~/workspace/server" is totally wrong.
Go language supports to put modules under a VCS, such as github. Usually, one git repo contains one go module and multiple packages under this module. However, this is not always correct because Go allows you to put multiple modules under the same project, and Go helps to find these modules via its path. A typical example is repository go.opentelemetry.io/otel, which contains huge amount of modules.
In my real senario, given a list of used modules parsing from go.mod, and a package name retrieving from import declaration, I want to know which module does this package belong to. strings.Contain isn't help at all because module paths have overlapped a lot.
This is a reading note to summarise the build list and dependency requirements of minimal version selection of go. If you want to learn more about minimal version select(MVS), please read the documentation and design docs below.
In short, MVS produces the build list as output, the list of module versions used for a build. The "minimal" in MVS means it selects the minimal version of each module that satisfies all requirements, instead of automatically choosing the highest available version. For example, if the requirements are "v1.1, v1.2, v1.3", the version v1.3 is the minimal version that satisfies all requirements. According to the MVS, v1.3 is selected.
Recently, I tried to write leetcode by rust. Everything goes well until I started to write code for linked list. The borrow check is quite verbose and I got stuck by the borrow check when handling Option<Box<LinkedNode>> more than the problem itself.
It's sad to find I don't understand the borrow check well, but it's also a good chance to find these missing knowledge for me.
This blog discusses about as_ref, as_mut and take of the Option.
Last week, users have reported a weird issue because they found:
This issue is complicated due to the involved components and the cross services. It takes me a lot of time to troubleshoot and finally I found the root cause successfully. The issue happened because user used gin.Context as context.Context directly inside a spawned go routine, however, gin tries to reuse the gin.Context for another request. As a result, the go routine spawned by previous request will be affected by the new request, and the request id mingles.