Anyone can close an issue without actually fixing it. AI are very good at that. And its not an advantage.
That has happened twice now on https://github.com/kolkov/racedetector/issues/17, which I file, and which is still not fixed after two AI attempts and auto closing it. Its not worth wasting more of my time on such projects. On Thursday, December 18, 2025 at 10:03:20 PM UTC-3 [email protected] wrote: > In 16 years of Go's existence, neither Google nor the community has > solved > > > the race detection problem without CGO. ThreadSanitizer requires > CGO_ENABLED=1, > > > which makes it unusable for Docker scratch images, cloud functions, > > > cross-compilation, and embedded systems. > > > > > > We demonstrated a working concept in pure Go: > > > - Detector is implemented (FastTrack algorithm, vector clocks, shadow > memory) > > > - 359/359 tests pass > > > - Real races are detected > > > > > > Issue #76786 was not a proposal to merge into upstream. We were gauging > > > community reaction to see if anyone actually needs this. And we found > out — > > > yes, they do (rr compatibility, CGO_ENABLED=0, cross-compilation). > > > > > > The problem is not the detector itself, but the integration. The current > > > AST-based approach is a proof of concept. With proper Go runtime > integration, > > > this would work 100% — the compiler already generates > runtime.raceread/racewrite > > > calls. > > > > > > About "AI vibe-slop": AI tools are professional force multipliers for > engineers, > > > not a replacement for expertise. Critics haven't proposed anything > themselves > > > to solve this 16-year-old problem. > > > > > > We're actively improving: > > > - v0.7.1-v0.7.2 fixed issues #15, #16, #17 reported by @glycerine > > > - Phase 2 will improve instrumentation via go/types and SSA > > > > > > Related issues: > > > - #15: Test command flags fix — > https://github.com/kolkov/racedetector/issues/15 > > > - #16: CGO file handling — > https://github.com/kolkov/racedetector/issues/16 > > > - #17: Stack trace display — > https://github.com/kolkov/racedetector/issues/17 > > > - #20: False positives reduction — > https://github.com/kolkov/racedetector/issues/20 > > > > > > Constructive bug reports welcome: > https://github.com/kolkov/racedetector/issues > > On Friday, 19 December 2025 at 03:24:36 UTC+3 Jason E. Aten wrote: > >> the #performance gopher slack channel pointed to this analysis regarding >> the https://github.com/kolkov/racedetector project: >> >> >> https://old.reddit.com/r/golang/comments/1pjx4hh/proposal_runtimerace_purego_implementation/ntk1k69/ >> >> in which hugemang4 starts by saying, >> >> > "While it would be great to have a low-overhead race-detector >> implementation, *this proposal is pure AI vibe-slop*. The race-detector >> implementation they have shared is 100% AI implemented that doesn't even >> work properly. The race-detector implementation they have shared is 100% AI >> implemented that doesn't even work properly. I'm not sure the author has >> even attempt to run the example in the README since it doesn't work as >> `main()` should almost always return before any of the goroutinues even >> begin executing. In fact, this is so broken, that simply unrolling the loop >> causes it to no longer detect the race. >> > >> > "The author claims they pass all of the Go race test, but the first >> test I opened for atomics ( >> https://github.com/kolkov/racedetector/blob/main/internal/race/api/go_race_atomic_test.go >> >> ) is incorrect and demonstrates the author doesn't understand concurrent >> memory models enough to implement this correctly. The tests here ( >> https://github.com/kolkov/racedetector/blob/main/internal/race/api/go_race_atomic_test.go >> >> ) "simulates" atomic operations by using a mutex, but this is incorrect, as >> the lock acts as a full barrier for surrounding non-atomic operations (the >> `simulateAccess` calls), but in Go (and most other languages) an atomic >> Store only acts as a release barrier and Loads as an acquire barrier. So >> these tests cannot detect a race caused by a load being reordered before a >> prior atomic Store." >> >> Sadly, my own evaluation and filed bug reports tend to confirm that this >> is not a serious implementation of a workable all-Go race detector, but >> indeed, at the moment, can indeed be charitable designated "pure AI vibe >> slop". >> >> I hope that the author can address the problems of the current >> implementation, but that will require alot of manual rather than AI effort. >> >> On Thursday, December 18, 2025 at 8:59:56 PM UTC-3 [email protected] >> wrote: >> >>> https://github.com/golang/go/issues/76786 - Read more about the >>> discussion. >>> >>> On Wednesday, 17 December 2025 at 15:47:12 UTC+3 Jason E. Aten wrote: >>> >>>> This looks amazing. Am to understand that the slowdown under >>>> kolkov/racedetectdor is only 22%, rather than 200-500% slower with the C++ >>>> race detector? That is incredible! >>>> >>>> On Friday, November 28, 2025 at 8:07:09 AM UTC-3 [email protected] >>>> wrote: >>>> >>>>> >>>>> 2025 update: This is now possible. >>>>> >>>>> I've built a Pure-Go race detector that works with CGO_ENABLED=0: >>>>> https://github.com/kolkov/racedetector >>>>> >>>>> Works in: >>>>> - Alpine/scratch Docker containers >>>>> - AWS Lambda / Cloud Functions >>>>> - Cross-compilation scenarios >>>>> - Any CGO_ENABLED=0 environment >>>>> >>>>> Usage: >>>>> go install github.com/kolkov/racedetector/cmd/racedetector@latest >>>>> racedetector build -o myapp main.go >>>>> >>>>> It's a standalone tool (not runtime integration yet), but it detects >>>>> races without any CGO dependency. FastTrack algorithm, 15-22% overhead, >>>>> pure Go. >>>>> >>>>> Feedback welcome: https://github.com/kolkov/racedetector/discussions >>>>> >>>>> Best regards! >>>>> On Wednesday, 18 February 2015 at 00:09:22 UTC+3 Blake Caldwell wrote: >>>>> >>>>> I'm building my service without CGO, so ideally, I'd like to run my >>>>> tests with the same settings, and I really like race detection. Is there >>>>> any way to use the race detector with CGO_ENABLED=0? >>>>> >>>>> # testmain >>>>> runtime/race(.text): __libc_malloc: not defined >>>>> runtime/race(.text): getuid: not defined >>>>> runtime/race(.text): pthread_self: not defined >>>>> runtime/race(.text): madvise: not defined >>>>> runtime/race(.text): sleep: not defined >>>>> runtime/race(.text): usleep: not defined >>>>> runtime/race(.text): abort: not defined >>>>> runtime/race(.text): isatty: not defined >>>>> runtime/race(.text): __libc_free: not defined >>>>> runtime/race(.text): getrlimit: not defined >>>>> runtime/race(.text): __libc_stack_end: not defined >>>>> runtime/race(.text): getrlimit: not defined >>>>> runtime/race(.text): setrlimit: not defined >>>>> runtime/race(.text): setrlimit: not defined >>>>> runtime/race(.text): setrlimit: not defined >>>>> runtime/race(.text): exit: not defined >>>>> runtime/race(.text.unlikely): __errno_location: not defined >>>>> runtime/race(.text): undefined: __libc_malloc >>>>> runtime/race(.text): undefined: getuid >>>>> runtime/race(.text): undefined: pthread_self >>>>> runtime/race(.text): undefined: madvise >>>>> too many errors >>>>> >>>>> -- 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/8fbd4bc6-926a-45a1-9128-bac6dcea4d47n%40googlegroups.com.
