[nano-erud]

This term is not used much. Most know more about "random testing" or "monkey testing", much more common out there. I think fuzzing is used a lot to find security holes and I think it is kind of old, very used yet though, but it is not something that is seen everywhere by programmers outside of systems programming. Not all programmers work in the same field, so it is not uncommon for someone not to know about this. In my case, I associate the term fuzzing with matching, for example.

[kbenson]

Somewhat. I think it might mostly be that it provides a much greater return for those using languages where incorrectly handled values have a higher chance of causing much worse problems, like C and C++. I think if you write in those languages, or like me you haven't for almost 20 years but you're just still very interested in developments about them because they often seem to illuminate the weird quirks of computing and CPUs, then fuzzing is a much more common thing to have heard about.

Not that fuzzing isn't useful for higher level or managed languages, just that it's extra useful when you throw likely segfaults into the mix.

[smt1]

Fuzzing is ROI efficient (especially for time invested) even if you don't intend to find a segfault, but just want to see how a program works or performs across different input states either in or out of its usual domain (and you can direct the fuzzing many ways derandomizing it or constraining the search space, or using virtualizer like qemu). I like to think of it as "semantics engineering" with spare CPU cycles.

I use fuzzers with a Redex driver usually, which is unusually great at intelligently driving fuzzers: https://docs.racket-lang.org/redex/index.html