Yay new version! Not the most exciting (as Go releases tend to be which is good), but hopefully jsonv2 and greentea can get some testing and be standard in 1.26
I just love how this language marches forward. I have so many colleagues that hate many aspects of it but I sit here combining Go, Goa and SQLc writing mountains of code and having a fairly good compiler behind me. I understand what I’m missing out on by not using stricter languages and so often it’s a totally fine trade off.
> LookupMX and Resolver.LookupMX now return DNS names that look like valid IP address, as well as valid domain names. Previously if a name server returned an IP address as a DNS name, LookupMX would discard it, as required by the RFCs. However, name servers in practice do sometimes return IP addresses.
This one is interesting; which servers return an IP address as a record? Why would they want to do this?
New `encoding/json/v2` package (hidden behind `GOEXPERIMENT=jsonv2` flag)! It brings perf improvements and finally allows devs to implement custom marshalers for external types:
> Alternatively, users can implement functions that match MarshalFunc, MarshalToFunc, UnmarshalFunc, or UnmarshalFromFunc to specify the JSON representation for arbitrary types. This provides callers of JSON functionality with control over how any arbitrary type is serialized as JSON.
Just watch as most libraries now update their go.mod to say 1.25, despite using no 1.25 features, meaning those who want to continue on 1.24 (which will still have patch releases for six months...) are forced to remain on older versions or jump through lots of hoops.
> LookupMX and Resolver.LookupMX now return DNS names that look like valid IP address, as well as valid domain names. Previously if a name server returned an IP address as a DNS name, LookupMX would discard it, as required by the RFCs. However, name servers in practice do sometimes return IP addresses.
Ah, intentionally making code not standards compliant.
> TLS servers now prefer the highest supported protocol version, even if it isn’t the client’s most preferred protocol version.
>Both TLS clients and servers are now stricter in following the specifications and in rejecting off-spec behavior. Connections with compliant peers should be unaffected.
20 comments
[ 2.9 ms ] story [ 48.8 ms ] threadThis one is interesting; which servers return an IP address as a record? Why would they want to do this?
> Alternatively, users can implement functions that match MarshalFunc, MarshalToFunc, UnmarshalFunc, or UnmarshalFromFunc to specify the JSON representation for arbitrary types. This provides callers of JSON functionality with control over how any arbitrary type is serialized as JSON.
Awesome stuff.
[1] https://github.com/golang/go/issues/27179#issuecomment-22899...
[1] https://github.com/golang/go/issues/72991
[2] https://www.datadoghq.com/blog/engineering/go-memory-regress...
[3] https://news.ycombinator.com/item?id=44597550 (24 days ago)
It's a "minimum" version, not a dependency lock!
Ah, intentionally making code not standards compliant.
>Both TLS clients and servers are now stricter in following the specifications and in rejecting off-spec behavior. Connections with compliant peers should be unaffected.
This is nice.