[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