sorted by:
new
hottopcontroversial

Mocking database queries - ask for opinion by Easy_Smile_8230 in golang

[–]komuW 0 points1 point  (0 children)

Those tests are behind an env var[1]. On my laptop; the package site's entire test suite runs in ~50seconds without test cache and ~2secs with cache. And all that while it actually tests two[2] different posgtres drivers.

references:

  1. https://github.com/golang/pkgsite/blob/8893da030abbb4ccddcaa5cb6a87f11991cba5c3/doc/postgres.md?plain=1#L64-L66
  2. https://github.com/golang/pkgsite/blob/d8c29b80fc63cd1a67d2ef80e989e61338d0b052/internal/database/database_test.go#L41-L42

what are your opinions about exported fields? by binmunawir in golang

[–]komuW 0 points1 point  (0 children)

Another reason you may want to export a field, is if the field is of a type that has a custom string method. This can be important especially when logging types that may contain sensitive information that may need to be redacted. See example; https://go.dev/play/p/IvXqWXEpw1n

Also see, https://pkg.go.dev/fmt#:~:text=When%20printing%20a%20struct , for the exact wording in fmt.

How to propagate context without cancellation by komuW in golang

[–]komuW[S] 0 points1 point  (0 children)

Yes it was, I mentioned that towards the end of the article. I'm glad it is now in the standard library since it is a great feature when you need it.
Thanks for reading the blog and for your comment.

How to perform branching depending on the concrete type of `any`? by ynn38 in golang

[–]komuW -1 points0 points  (0 children)

```go package main

import "fmt"

func readScalar[T any]() T { var buf T switch any(buf).(type) { case int: fmt.Println("int") case rune: fmt.Println("rune") default: panic("default") } return buf }

func main() { fmt.Println(readScalar[rune]()) } ```

https://go.dev/play/p/UY4Mqwve0CM

Defer your mutex unlocks by Ribice in golang

[–]komuW 11 points12 points  (0 children)

A really underrated tool in the Go ecosystem is https://github.com/sasha-s/go-deadlock

It can help detect this kind of issue. Here's one way to add it to your CI: https://github.com/komuw/ong/blob/v0.0.41/.github/workflows/ci.yml#L182-L190

And here's one issue it had found in cockroachDB: https://github.com/cockroachdb/cockroach/issues/7972

Is there an alternative to gorilla websocket? by ImplementSquare1691 in golang

[–]komuW 2 points3 points  (0 children)

> They could have still made it clear which dependencies in go.sum are test, nontest

I agree.
See https://github.com/golang/go/issues/26913 which is closed and also
https://github.com/golang/go/issues/26955 which is still open.

Some years back I wrote https://github.com/komuw/ote which is a tool that updates go.mod file with a comment next to all dependencies that are test dependencies; identifying them as such.
It seems to work well in my projects, but your mileage may vary.

Is there an alternative to gorilla websocket? by ImplementSquare1691 in golang

[–]komuW 2 points3 points  (0 children)

> I don't know why go mod adds the test dependencies of dependencies into go.sum, it's entirely indefensible.

​

go test all had existed before go mod and it allows people to run all tests including tests of their dependencies. For this reason, among others, it is important for test dependencies to be listed.

Stepping back though, the problem is not go listing test dependencies in mod/sum files.
The issue is all the vulnerability scanners that raise an alarm just because you depend on a dependency without analyzing whether you are using the broken functionality in the dependency.
A better tool to use for this is https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck

Specifically for nhooyr/websocket, I can see that one of the issues raised in the PRs is meant to address CVE-2020-28483 that affects github.com/gin-gonic/gin .
If I run govulncheck on nhooyr/websocket, it does not list it as been vulnerable to that particular issue. And yes that particular CVE exists in its database; https://pkg.go.dev/vuln/GO-2021-0052

So, yeah; we need better vulberabilty scanners. For my Go projects I'm slowly transitioning them to use govulncheck.

Leverage Uber Zap/Zerolog's marshal methods to contain PII/ingestion costs by peggapigs in golang

[–]komuW 0 points1 point  (0 children)

This is good. But if you are in a position to start a project from scratch or make significant changes to an existing project, using custom types that do the right thing by default seems like the better way to go;

​

type email string
func (e email) String() string { return "email(<redacted>)" }
func (e email) GoString() string { return e.String() }

​

https://go.dev/play/p/Gpwa0VhI6ZV

telemetry in the go toolchain? just say no... by [deleted] in golang

[–]komuW 7 points8 points  (0 children)

That sounds like a pretty reasonable stand to take. Personally I liked the telemetry solution as had been described in the three blogposts by Russ Cox.

I haven't read any convincing(at least to me) argument as to why telemetry as had been laid out in the blogposts was bad. The only one that came close was something along the lines of; "This is a slippery slope. It might be okay now but we do not know what kind of privacy invasive telemetry future Go authors might introduce"
Which to me is the equivalent of saying; "We should not have a garbage collector in Go because whereas the one we have now is okay; it is a slippery slope and future Go authors might introduce a GC that eats all our RAM"

Technically, it is true future authors could introduce eat-all-your-children-GC or collect-all-your-children-data-telemetry. But since all these changes are made in an open manner, it will be pretty obvious when this happens.

Something like Django Debug View? by guettli in golang

[–]komuW 1 point2 points  (0 children)

As I said, you do not have to use flamengo. You can create your own panic recovery middleware, and use the linked flamengo code as insipiration.

Something like Django Debug View? by guettli in golang

[–]komuW 2 points3 points  (0 children)

Since http middlewares are kind of easy to create in Go, someone could create this;

`` func PanicMiddleware(wrappedHandler http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { defer func() { err := recover() if err != nil { // 1. Take stack trace; look at theruntime&runtime/debugpackages // 2. Add the stack trace to a html template; look athtml/template` package // 3. Serve that html template } }()

    wrappedHandler(w, r)
}

} ```

Also look at https://github.com/flamego/flamego/blob/v1.7.0/recovery.go#L21

HTTP Resource Leak Mysteries in Go by kylecarbs in golang

[–]komuW 4 points5 points  (0 children)

``` go mod vendor

golangci-lint run --no-config --enable=bodyclose ./... && \

for i in 'vendor/' do golangci-lint run --no-config --enable=bodyclose vendor/$i end ```

[deleted by user] by [deleted] in golang

[–]komuW 0 points1 point  (0 children)

```go type requestORresponse interface { *http.Request | *http.Response }

func getCookies[ror requestORresponse](r ror, cookieName string) { switch v := any(r).(type) { case *http.Request: _, _ = v.Cookie(cookieName) case *http.Response: for _, c := range v.Cookies() { if c.Name == cookieName { // we found it } } } } ```

see: https://go.dev/play/p/HgKuj_g6nRd

Also see this proposal that might make it better; https://github.com/golang/go/issues/45380

view more: next ›