| ▲ | Go 1.27 Interactive Tour(victoriametrics.com) |
| 66 points by Hixon10 2 hours ago | 13 comments |
| |
|
| ▲ | chenxiaolong an hour ago | parent | next [-] |
| This release also fixes runtime.findnull() to be compatible with MTE on Android ([1] and [2]). This was the only thing preventing MTE from being enabled for apps that use gomobile on MTE-compatible Android OS's like GrapheneOS. [1] https://go-review.googlesource.com/c/go/+/749062 [2] https://go-review.googlesource.com/c/go/+/751020 |
|
| ▲ | mappu 22 minutes ago | parent | prev | next [-] |
| Automatically draining http response bodies is a risky silent behaviour change. I think it will be an improvement for most applications, but it's very subtle if you were relying on the old behaviour |
|
| ▲ | nu2ycombinator an hour ago | parent | prev | next [-] |
| Those Generics syntax in Golang seems so hard to read. |
|
| ▲ | Hixon10 2 hours ago | parent | prev | next [-] |
| Some examples for the upcoming release https://go.dev/doc/go1.27 |
|
| ▲ | stingraycharles an hour ago | parent | prev | next [-] |
| Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language design, and is much harder to retrofit (backwards compatibility). So what changed? |
| |
| ▲ | bradfitz an hour ago | parent | next [-] | | (I was on the Go team for ages) Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked. Nobody was ever opposed to generics that I saw. | |
| ▲ | amtamt 11 minutes ago | parent | prev | next [-] | | If bug free binary search implementation can take 16 years, I am ready to buy generics implementation could take 20 years. > In his landmark book The Art of Computer Programming, legendary computer scientist Donald Knuth noted that although the first binary search algorithm was published by John Mauchly in 1946, the first bug-free version was not published until 1962—taking a staggering 16 years to get right. | |
| ▲ | throw2ih020 an hour ago | parent | prev | next [-] | | > what changed in the perspectives of the language maintainers? The original maintainers moved on to other projects and the new community maintainers came to a consensus through the proposal and governance process. | | | |
| ▲ | fooster 41 minutes ago | parent | prev [-] | | It’s also not true that because it wasn’t part of the initial design that it was harder to retrofit. I just don’t understand all this go bashing that happens on this site especially when so much is badly informed speculation. I guess it’s easier to tear something down. |
|
|
| ▲ | lilbigdoot an hour ago | parent | prev | next [-] |
| This level of generics actually has me interested a bit in Go now. |
|
| ▲ | drivebyhooting 36 minutes ago | parent | prev [-] |
| Can generics be used to improve error handling and eliminate the if err pattern? |
| |
| ▲ | jerf 5 minutes ago | parent [-] | | No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...)
if err != nil {
// handle error
}
// use val
for val := whatever(...)
if err, isErr := val.Error(); isErr {
// handle error
}
realVal := val.Value()
// use realVal
What you win in nominal safety, you're definitely losing in convenience.There's also no win in trying to offer a monadic interface like finalVal := whatever(...).OnVal(func (val Value) opt.Option[Result] {
// use val
})
because that's the minimal specification of an anonymous function in Go, so it's very inconvenient. Even if that was trimmed down, nested functions are still problematic in other ways. And you still have to unpack finalVal anyhow.Really the solution is, install golangci-lint, turn on errcheck [1], use a pre-commit hook to make it a commit failure if golangci-lint fires, and that pretty much covers the problem in practice. [1]: https://golangci-lint.run/docs/linters/configuration/#errche... |
|