gomodifytags VS go

gomodifytags

https://github.com/fatih/gomodifytags - generate or modify struct tags

I suspect it's because Go's general philosophy is that it's better to be verbose and explicit (than terse and magical). Probably falls under "clear is better than clever" from Rob Pike's Go Proverbs: http://go-proverbs.github.io/

I think if this feature was added, it would not be with struct tags, but with an Encoder.SetFieldTransform(json.SnakeCase) or similar setting.

That might be quite a nice feature, actually. You could provide your own function to transform names when marshaling, and for unmarshaling it would strip punctuation and match case insensitively (because it's hard to do the reverse transform, for example should user_id go to UserId or UserID, and if the latter, how does the transform know?).

In any case, it seems like an issue was opened proposing something like that a couple of years ago (https://github.com/golang/go/issues/23027), and Russ Cox responded that the JSON package is basically done, but you could either fork it and add the feature, or use a tool that modifies struct tags like https://github.com/fatih/gomodifytags

// handle unexported go stdlib error, XXX fix after https://github.com/golang/go/issues/35234

Go without concurrency is fully memory safe. However, once you start using goroutines there can be memory corruption and segfaults: https://github.com/golang/go/issues/37484. Note that these are not recoverable panics (such as "writing to a close channel"), but causes completely arbitrary behavior:

    runtime: pointer 0xc00379ac60 to unused region of span span.base()=0xc001794000 span.limit=0xc001795e00 span.state=1

As for first entry, this has been discussed many times without ever reaching any consensus, see - https://github.com/golang/go/issues/19412

To be fair to those projects, the type was introduced only three years ago:

https://github.com/golang/go/pull/49359/files

Before that, doing a string compare was basically the only way to detect that specific error. That was definitely an omission on the part of the original authors of the stdlib code; I don't it should be classified as "Hyrum's Law".

git clone https://github.com/golang/go OR git clone https://go.googlesource.com/go

I install go.

The difference between types.Implements and types.Satisfies is mainly a history reason, a tradeoff between keeping backward compatibility and theory perfection.

It is pity that Go didn't support the "comparable" interface from the beginning. If it has been supported since Go 1.0, then this tradeoff can be avoided.

There are more limitations in current Go custom generics, much of them could be removed when this proposal (https://github.com/golang/go/issues/70128) is done.

I recommend people to read Go Generics 101 (https://go101.org/generics/101.html, author here) for a thoroughly understanding the status quo of Go custom generics.