Issue 596 of the Golang Weekly newsletter mentions the v1 release of github.com/jub0bs/cors. Nice! #golang

golangweekly.com/issues/596

Therac-25 - Wikipedia The Therac-25 was a computer-controlled radiation therapy machine produced by Atomic Energy of Canada Limited (AECL) in 1982 after the Therac-6 (neptune) and Therac-20 units (the earlier units had been produced in partnership with Compagnie générale de radiologie (CGR) of France).[1]

There are no benign data races. In fact, some are lethal. ☠️

en.wikipedia.org/wiki/Therac-25

$ go install golang.org/dl/go1.26.2@latest $ go1.26.2 download Downloaded 0.0% ( 0 / 63701324 bytes) ... Downloaded 50.0% (31850662 / 63701324 bytes) ... Downloaded 100.0% (63701324 / 63701324 bytes) Unpacking go1.26.2.linux-arm64.tar.gz ... Success. You may now run 'go1.26.2' $ go1.26.2 version go version go1.26.2 linux/arm64

🥳 Go 1.26.2 and 1.25.9 are released!

🔐 Security: Includes 10 security fixes for the standard library and the toolchain.

📢 Announcement: groups.google.com/g/golang-announce/c/0uYb...

⬇️ Download: https://go.dev/dl/#go1.26.2

#golang

Rumour has it that it hurts all over: jub0bs.com/posts/2023-0...

I obviously meant 1 << 9, not 1 >> 9. 😅

GitHub - jub0bs/cors: perhaps the best CORS middleware library for Go perhaps the best CORS middleware library for Go. Contribute to jub0bs/cors development by creating an account on GitHub.

🎉 After a few years of refinement and close to 1 >> 9 commits, I'm pleased to announce the v1 release of my CORS middleware library for Go.

Let me know whether it patches things up between you and CORS!

github.com/jub0bs/cors

#golang #CORS

💯

Is that something you're considering enforcing in gofumpt?

Yes, as far as I understand. Tip is essentially a pre-release version of go1.(n+1), where n is the most recent stable major version of Go.

I too was surprised that such a small change had so much impact on performance. And one more thing: code readability also improved (IMO). 😇

When something tantalising gets merged at tip, you can put code that relies on it in a file guarded by a //go:build go1.27 build constraint and its pre-1.27 counterpart in a file guarded by a //go:build !go1.27 build constraint. No need to update your go.mod's go directive.

I love how the conjunction of #golang's modules system and build constraints lets you have your cake and eat it too! 🍰

You can let users of your library take advantage of the bleeding edge if they so wish without cutting off one of the currently supported Go toolchains.

Even when you cannot eliminate all bounds checks within a loop, eliminating most of them may benefit performance. 😉
#golang

go-review.googlesource.com/c/go/+/759100

Unfortunately, this proposal would require a breaking change. Therefore, I've decided to retract it.

"Marin"? 😅

My point is that, as gc becomes better at BCE, the output of

go build -gcflags '-d=ssa/check_bce/debug=1' <path-to-package>

contains fewer false positives for reachable panics, which eases the attacker's task of identifying true positives due to incorrect indexing. Wouldn't you agree?

Paradoxically (perhaps), as the Go compiler becomes better at eliminating bounds checks, attacker-reachable panics due to incorrect programmer assumptions about indices become easier to find.

#golang

Fewer bounds checks in #golang thanks to Youlin Feng: go-review.googlesource.com/c/go/+/719881

Generic concrete methods may well land in Go 1.27! 🤩
go-review.googlesource.com/c/go/+/746820

//go:fix inline and the source-level inliner - The Go Programming Language How Go 1.26's source-level inliner works, and how it can help you with self-service API migrations.

Find out how the source-level inliner in Go 1.26 can help you with API migrations.
go.dev/blog/inliner

GitHub - dominikh/go-tools: Staticcheck - The advanced Go linter Staticcheck - The advanced Go linter. Contribute to dominikh/go-tools development by creating an account on GitHub.

"Open-source but closed for contributions" is the sweet spot for me. I like @honnef.co's take on this approach: github.com/dominikh/go-...

proposal: spec: make bool an ordered type · Issue #78027 · golang/go Go Programming Experience Experienced Other Languages Experience Python, Haskell, JavaScript, C Related Idea Has this idea, or one like it, been proposed before? Does this affect error handling? Is...

I've just filed a proposal to make bool an ordered type (compatible with operators <, <=, >, and >=) in #golang: github.com/golang/go/is...

Fascinating! Thanks for sharing. 🙇

#golang quiz: What happens if you try to compile and run the following program?

package main

import (
"fmt"
"math"
)

func main() {
fmt.Println(int(math.NaN()))
}

a. It prints 0.
b. It prints -1.
c. It panics.
d. Compilation fails.
e. Something else.

Besides, I welcomed support for ranging over ints. The gain in readability over a classic three-clause loop is real, as explained in the following comment: github.com/golang/go/is...

cmd/compile: poor escape analysis of `strings.SplitSeq` · Issue #73524 · golang/go Go version go version go1.24.2 linux/amd64 Output of go env in your module/workspace: AR='ar' CC='gcc' CGO_CFLAGS='-O2 -g' CGO_CPPFLAGS='' CGO_CXXFLAGS='-O2 -g' CGO_ENABLED='1' CGO_FFLAGS='-O2 -g' ...

One source of complexity surrounding iterators, IMO, is when the iterator is designed as "impure", in the sense that even if the yield function you pass it is a pure function, consuming the iterator has side effects. A subtlety that can trip even seasoned Gophers up: github.com/golang/go/is...

Ranging over a channel too only yields (at most) a single value.

As a consumer of iterators, you're largely isolated from the complexity they deploy under the hood, esp. if those iterators are designed as pure functions. Things are different if you have to implement iterators yourself but, again, not prohibitively so, IMO.

Thanks! Yeah, and the kind of forward compatibility that error types unlocks in comparison to error values is appreciable as well.

Well, generics certainly made the language more complex, but not prohibitively so, IMO. I think Go's agenda of simplicity is as strong as ever.