I'll keep sharing the articles on the slack channel though. I'm learning a lot by working on 'em too.
On Monday, July 27, 2026 at 3:48:25 AM UTC Jason E. Aten wrote: > I don't think there is any consensus for Go users, but after RSC's > analysis (link? my github search foo is failing me) I think the Go > development team adopted his recommendation to not mention AI use in any > git commit messages, no matter if an LLM was used or not. > > His analysis was long but in short that was, if I recall correctly, to a) > not give the LLM manufacturers free advertising; and b) convey the > expectation that the human whose name is on it is ultimately responsible > for all of it, no matter what percentage of the commit was AI generated. > > Moreover, I would add, c) these days most people will assume most things > have some AI support -- even if there is none. And the accusations and > refutations (seen constantly in some forums like Hacker News) is tiresome > and not particularly interesting. So the same guideline makes sense to me > -- for articles like yours. I expect you will use AI if you like, but > mentioning your own AI in your articles was the only thing that struck me > as a bit crassly commercial. As I said, I'd like to actively encourage > writing on topics of interest to Go users -- I wish other folks were > writing articles such as yours. But you don't need to advertise your AI > model too. I don't want to speak for Duncan, but I have a hard time imaging > the actual content was what he was objecting too. > > Perhaps tangentially, it stikes me that one difficulty is that we most > often use AI when we don't know the actual answer ourselves. That seems to > be the best place (only place?) where it is extremely reasonable to point > out that AI was used. "The AI said X but I have conflicting evidence Y, > what is the right answer?" is something human experts will be doing alot > of. It seems both un avoidable and natural to ask such questions. > > But otherwise I have been favoring just leaving off attribution to any > degree to the LLMs, for the reasons a, b, and c above. I don't want to > advertise, and I need to take full accountability for the content anyway; > and the discussion of whether or not something was LLM supported is boring > and contributes little. To my way of thinking, mentioning AI use as a > disclaimer comes out to the same thing as advertising--so I would avoid it. > That said, if you AI model overlaps with Go in some way (was created with > Go, uses Go, is tuned for Go specifically), then talking about it directly > in one post seems perfectly reasonable. > > On Monday, July 27, 2026 at 12:15:20 AM UTC-3 Cheikh Seck wrote: > >> Also, disclaimer, writing these articles recently started as an >> experiment where I had an agent I built train itself on my most previously >> successful posts (2022) and write in that style, voice and tone. The first >> few went unnoticed lol A friend recommended mentionning it was written by >> said agent as a selling point and case study for it. >> >> On Monday, July 27, 2026 at 3:06:22 AM UTC Cheikh Seck wrote: >> >>> I usually try to fact check the best I can. At the same time, I believe >>> this group is for new package releases and langauge features so it makes >>> sense not to share on here. >>> >>> On Monday, July 27, 2026 at 1:08:53 AM UTC Jason E. Aten wrote: >>> >>>> Nah. To me, these are fine. They are both topical to Go and discuss >>>> novel aspects of Go programming, and are written fairly infrequently. I >>>> for >>>> one appreciate them and have learned about important topics like eBPF from >>>> them. They seems like appropriate use of go-nuts to me. >>>> >>>> I could wish the articles didn't use AI without fact checking... but >>>> meh, humans make plenty of mistakes too. >>>> >>>> >>>> On Sunday, July 26, 2026 at 6:42:25 AM UTC-3 Duncan Harris wrote: >>>> >>>> I think you probably need to stop posting these articles to this group. >>>> It is not scalable. People will get annoyed. >>>> >>>> On Friday, 24 July 2026 at 23:02:37 UTC+1 Cheikh Seck wrote: >>>> >>>> Go 1.26's runtime/secret (GOEXPERIMENT=runtimesecret) tags allocations >>>> inside secret.Do(f) for erasure — the right layer to stop secrets leaking >>>> into crash core dumps. Key takeaway: it marks, doesn't wipe — you must >>>> call >>>> runtime.GC() right after or you still leak, and it's a no-op off >>>> linux/amd64+arm64. >>>> >>>> I built a reproducible harness (canary → SIGSEGV → scan the core): >>>> control leaks, secret doesn't. Repo + Dockerfile: >>>> https://github.com/cheikh2shift/go-snippets/tree/main/secret-demo >>>> >>>> Writeup: >>>> https://towardsdev.com/runtime-secret-go-1-26s-answer-to-secrets-leaking-in-core-dumps-d884615e971f >>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/622cef99-4425-4a44-ab13-972a5f036a8bn%40googlegroups.com.
