It's not a coincidence that Fuzzing is added to Go

Posted Sep 4, 2020 23:43 UTC (Fri) by HelloWorld (guest, #56129)
In reply to: It's not a coincidence that Fuzzing is added to Go by NAR
Parent article: Fuzzing in Go

A decent types system without null pointers and with immutable types, algebraic data types and generics (including higher kinded types, higher-rank types and GADTs). The way to avoid the vast majority of crashes is to make sure that every function and every language construct is total and deterministic, and that is only practical with a sufficiently powerful type system. The future is functional, and it's highly unfortunate that languages like Go are actively pushing people in the wrong direction.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 5, 2020 10:43 UTC (Sat) by NAR (subscriber, #1313) [Link] (2 responses)

Fuzzing is used not only to find crashes, but bugs in general. It doesn't matter that much from the user's perspective if the program crashes or produces a stacktrace (or 500 internal server error) instead of a the expected result.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 5, 2020 10:52 UTC (Sat) by HelloWorld (guest, #56129) [Link] (1 responses)

Oh really. Strange, where did I get the idea that it was about finding crashes? Oh, I know: it was right in the article:

> The basic idea of fuzz testing is to generate random inputs for a function to see if it crashes or raises an exception that is not part of the function's API.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 11, 2020 15:07 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, obviously with a little more work you can search for "misbehaviour in general", as long as you can define it well enough. It's just that crashes are easy to define and detect, so most fuzzers start from there.