This is the main benefit. I've been using go-fuzz for years and compiler upgrades (especially any changes related to modules/GOROOT/GOPATH) was a pain because it always behaved slightly differently.
> It can also work with built-in Go types, in comparison to traditional fuzzing tools that just work with bytes.
This could have been done just as efficiently without upstream integration.
a) A lack of strong typing
b) A custom compiler toolchain
llvm already has instrumentation/ coverage support and generics make it easy to work with higher level constructs than bytes, although you generally do want to just work with bytes when fuzzing imo.
The language is weak, therefor the language has to add more and more batteries-included because extending it is purposefully difficult.
> [...]
> llvm already has instrumentation/ coverage support
I mean, that supports the idea of having fuzzing support in whatever core you have.
Go uses LLVM’s ThreadSanitizer since 1.1.
The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer.
> therefor the language has to add more
Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain.
Sweet, that's a smart approach.
> Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain.
I don't care either because I don't write Go, so just the fact that it's supported is nice for me since it encourages this in languages I do care about.
But if I were a go developer I might care a lot about how my language evolves, what's built in, what's a library, what the capabilities are, what tools I can integrate with, etc.
It sounds like they've done a pretty good job with regards to this implementation though, happy to see it.