Roc language can get away with using only Result because of its novel error handling. It will "infer" the error types for functions. Normally having a lot of error types is kind of cumbersome to handle, but inferring error types makes it easy to add safe error types, then why not replace all Options, etc with a single type as well?
If you are interested more there is a good YouTube from five months ago by Richard Feldman: https://www.youtube.com/watch?v=7R204VUlzGc error handling starts from 28 minutes, at 42 minutes you can see the inferred error types, which is very neat.
>The inventor of the null reference refers to it as his "billion dollar mistake" because it "has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
I've heard this Tony Hoare quote before, and it makes zero sense to me. If your reference is a number, your reference can be zero. How many billions of dollars have been saved by having a reserved constant which indicates "this is not a valid reference"?
How would I know that a pointer was uninitialized if this wasn't a feature?
I was curious about the syntax of this signature:
> List.first : List a -> Result a [ListWasEmpty]
I found this section of the tutorial useful (and the preceding example of calling List.get): https://www.roc-lang.org/tutorial#error-handling
The `a` is the type from the `Ok` constructor (similar to Haskell's Left constructor in Either) and the brackets mean "List", not "optional" as in CLI docs, it's a list of types that might be used in the `Err` constructor (similar to Right). So `List.first` either returns `Ok a` or `Err ListWasEmpty`. For a slightly larger example, the tutorial has a `getLetter` that shows two error types.