Sure. The more things the programmer needs to worry about and explicitly state, then there more pathways there are for error. Using assembly language vs a hig

Sure. The more things the programmer needs to worry about and explicitly state, then there more pathways there are for error. Using assembly language vs a higher level language illustrates this. There are certain classes of errors that are eliminated by the language / compiler / runtime. Examples could be garbage collection preventing you from have page segmentation faults, or accidentally modifying the stack pointer and destroying the return address. Rich types like Maybe / Either offload the exception handling and allow you to write your code for just the happy path while still having the program fully support the unhappy path. Compilers with pattern matching can give you errors when you have not handled all possible inputs to a function (total function). If you just have the "if err != nil" or null-check style code then it's easy to miss them. By tedious, if you constantly have to type the same thing over and over ("if err != nil") then it takes away time and mental energy from focusing on the core problem domain. Being able to express guard conditions to a function allow your functions to be simpler and easier to understand. It basically allow comes down to abstraction and letting the compiler / language do things that it is good at and freeing the programmer from having to worry about every single permutation. It's just not feasible for the human mind to see every possible branch of a program.