Golang Go
Fleetinggolang
Optimizing Memory Management in Go with GOMEMLIMIT
- Référence externe : https://hsleep.medium.com/optimizing-memory-management-in-go-with-gomemlimit-da8ed23e2dcb Optimizing Memory Management in Go with GOMEMLIMIT
When applying it to the server, GOMEMLIMIT was set at about 80% of the available memory. After setting GOMEMLIMIT, the OOM issues were resolved. Now, the server operates stably even during times of high request volume, providing uninterrupted service to users.
— https://hsleep.medium.com/optimizing-memory-management-in-go-with-gomemlimit-da8ed23e2dcb ()
go maps
- Référence externe : https://go.dev/blog/maps golang go
golang maps are references, like pointers or slices
Map types are reference types, like pointers or slices
golang interface
panic => exit code 2
-
Référence externe : https://www.practical-go-lessons.com/post/how-to-recover-from-a-runtime-failure-panic-in-go-cbl28ojpaeds70g0qrs0 How to recover from a runtime failure (panic) in Go| Practical Go Lessons
Go runtime prints the stack trace. At the top, you can see the file and line where the panic occurred. It’s easy then to debug! Note also that the exit status code is 2. Which signals an error (0 when all is good)
workspace
-
Référence externe : https://github.com/golang/go/issues/53502
-
Référence externe : https://go.googlesource.com/proposal/+/master/design/45713-workspace.md golang go
go.work files should not be checked into version control repos containing modules so that the go.work file in a module does not end up overriding the configuration a user created themselves outside of the module. The go.work documentation should contain clear warnings about this.
— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md
These go.work files should not be checked into the repositories so that they don‘t override the workspaces users explicitly define. Checking in go.work files could also lead to CI/CD systems not testing the actual set of version requirements on a module and that version requirements among the repository’s modules are properly incremented to use changes in the modules
— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md
go.work files should not be checked into version control repos containing modules so that the go.work file in a module does not end up overriding the configuration a user created themselves outside of the module. The go.work documentation should contain clear warnings about this.
— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md
single build list is constructed from the set of workspace modules to give developers consistent results wherever they are in their workspace
— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md
go.work files that checked into repositories would cause confusion for Go users because they change the build configuration without the user explicitly opting in. Because of this they should be strongly discouraged.
— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md
it seems like the common knowledge among Go developers is that the file should never be checked in, because:
GitHub’s default gitignore includes the file since Go: Ignore Go workspace file go.work github/gitignore#3884 Official Go repositories set an example by not checking them in; for example, x/tools does not include one, even though it has two modules connected by a directory replace directive Some third party docs or blog posts echo the recommendation to never check them in, like
https://sebastian-holstein.de/post/2021-11-08-go-1.18-features/
For large monorepos with multiple modules, it likely makes sense to check in go.work, as it makes the setup easier and often has no downsides
We never gave any advice on it, and the community seems to lean on “never check them in”.
We could recommend never checking them in, but I think that’s a bad idea: in some particular scenarios it can make perfect sense to check them in, such as monorepos holding multiple modules.
I would hate to have to teach people in my team how to create a go.work file just so gopls will work as expected for them, so it seems very reasonable to just push it into VCS. That’s why I was very surprised to see the proposal suggested against doing that.
it is possible and perhaps reasonable to check in a go.work file.
For what it’s worth I think it would be fine to fix this issue by updating the docs to say that checking in the file is okay in some cases. Right now we are silent, and there’s widespread “common knowledge” that dictates the file should never be checked in. We should at least clarify that that’s not the official recommendation.
If GOWORK is set to off, the command will be in a single-module context. If it is empty or not provided, the command will search the current working directory, and then successive parent directories, for a file go.work
Notes pointant ici
- cross build with go
- debug golang dap dlv delve emacs
- deno
- discussing type hints, protocols, and ducks in python
- dlv
- do not communicate by sharing memory; instead, share memory by communicating
- embedding interfaces in structs in golang
- get out of nested go for loop with labels (not like goto)
- go modules - How to upgrade the go version in a go mod
- golang context package
- golang see the dependency graph
- gopy generates a CPython extension module from a go package
- gotemplate
- how do I create an OAuth 2.0/OIDC resource server? (blog)
- how to use a gitlab private repository as a go module?
- how to version go module
- Is there a `go uninstall`?
- ko
- Monadic Error Handling in Python ⚠ Write Better Python Code Part 7B - YouTube
- My tools (blog)
- new() vs make() in golang
- tagging a go package makes it stick forever, using the proxy
- tinygo
- tss-lib
- wasm and export in golang
- yaegi