Hacker News Reader

> This is just a work around for:

> [...]

> llvm already has instrumentation/ coverage support

I mean, that supports the idea of having fuzzing support in whatever core you have.

My point is that between Go's custom compiler backend and inexpressive typing there's much more need to build things like this in directly vs what other languages can do by just using llvm/gcc. Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves, although that won't have the same issue with inexpressive types.

> Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves

Go uses LLVM’s ThreadSanitizer since 1.1.

I don't think that really addresses my point, it just shows that they did the work for one sanitizer already.

Reply on news.ycombinator.com