I decided that it was about time that I rolled out my own. It's going to be called Deluxe Draw, it's written in Go using Raylilb and it's gonna be #foss. A bit tired of the available choices. Just plain simple drawing, one single native binary, with basic tools, layers, pan, zoom, and little else.
#golang
Helm v3.18.3 and earlier are vulnerable to local code execution via a crafted Chart.yaml and symlinked Chart.lock. Exploit occurs during dependency updates. Patched in v3.18.4.
https://github.com/helm/helm/security/advisories/GHSA-557j-xg8c-q2mm
https://antonz.org/be/ aka https://github.com/nalgeon/be seems to be a great middleground between t.Fatal boilerplate and testify beeing an Excell of a go testing. I like that only is.Err is fatal. This a great place to be opiniated imho.
Comparing gzip, brotli and zstd compression in Go
#golang
https://blog.kowalczyk.info/a-5hum/compressing-for-the-browser-in-go.html
Did you know that we have open monthly meetings to discuss important issues related to the ongoing development of TinyGo? Now you do!
More info here:
https://github.com/tinygo-org/tinygo/wiki/Meetings
Nightingale is an open-source monitoring project emphasizing alerting. Unlike Grafana, which focuses on visualization, Nightingale prioritizes its alerting engine and alarm processing and distribution while also connecting with various data sources.
#golang
A fast, cryptographically safe GUID generator for Go
#golang
A project to capture Go program execution by interacting with the Delve debugger server, retrieving variable values and stack info of all Goroutines at each Go statement.
#golang
Encryption and Decryption in Go: A Hands-On Guide
#golang
https://dev.to/shrsv/encryption-and-decryption-in-go-a-hands-on-guide-3bcl
TIL: go.mod files have the ability to retract a version you've published of the Go module. This is useful for premature releases, test releases, and security-compromised releases. Very cool.
#golang ＞ Release v2.11.0 · goreleaser/goreleaser
https://github.com/goreleaser/goreleaser/releases/tag/v2.11.0
#golang
＞Go 1.25 Release Candidate 2 is released
https://groups.google.com/g/golang-announce/c/VDM1-NOZTQM
#golang
＞[security] Go 1.24.5 and Go 1.23.11 are released
https://groups.google.com/g/golang-announce/c/gTNJnDXmn34/m/rdlFOriABQAJ
TIL: You can have a reference to an unreachable commit in a `go.mod` file and get no warnings or errors in the build process. tl;dr: The build will work until that commit gets GC'd at some point in the future.
Cool story, #golang. Yes, package management is hard. But, come on. You should get a warning from `go mod tidy` if you're pointing to a GC eligible commit. Even if you're vendoring, it's important to know you may be incompatible with upstream in a way that's likely _NOT_ documented since the commit was never merged.
🎊 Go 1.25 Release Candidate 2 is released!
🏖 Run it in dev! Run it in prod! File bugs! https://go.dev/issue/new
📡 Announcement: https://groups.google.com/g/golang-announce/c/VDM1-NOZTQM/m/lxpShNSBBQAJ
📦 Download: https://go.dev/dl/#go1.25rc2
🥳 Go 1.24.5 and 1.23.11 are released!
🔐 Security: Includes a security fix for the Go toolchain (CVE-2025-4674)
📣 Announcement: https://groups.google.com/g/golang-announce/c/gTNJnDXmn34/m/rdlFOriABQAJ
📦 Download: https://go.dev/dl/#go1.24.5
#golang ＞ Release v1.40.4 · sashabaranov/go-openai
https://github.com/sashabaranov/go-openai/releases/tag/v1.40.4
How to leave no traces might be a topic for a spy movie, but software should rather be concerned about how to leave traces—specifically, how to leave the right amount of traces at the right point in time.
Like a flight recorder.
Also in the latest Applied Go Weekly Newsletter issue:
- Go and the 80/20 principle
- Configuration management in web apps
- Improve performance with benchmarks and profiles
#golang
https://newsletter.appliedgo.net/archive/2025-07-06-dont-leave-no-trace/?utm_source=appliedgo-mastodon
e.g., mixups like:
res = SendMsg(sender,receiver)
func SendMsg(receiver,sender)
(a flipped a,b=b,a mistake - I could fix that on some things by strongly typing public vs private keys, or strongly typing self, but the recipient is open ended)
or a for loop in a go worker with scratch that lasts out of scope / previous user's work
The other question is I guess you have some map (user ID -> work), how do you prevent accidentally cross wiring sessions, routines, channels, or results such that work you do for one user accidentally reads or writes to another user's part of the map. Is "share memory by communicating" a strong enough model to avoid cross wiring vs passing around a struct like "this result was meant for this user" and checking it?
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst