Why doesn't Roc have a Maybe or Option or Optional, or null or nil or undefined? | Hacker News Reader

Why doesn't Roc have a Maybe or Option or Optional, or null or nil or undefined?

roc-lang.org

14 pointsCiantic7 comments

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.

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?

The problem is that `null` is not `None`. `None` is, critically, a SINGLE value that is `None = None`.

Null is whatever. That is the mistake.

Isn't undefined 'whatever'? Usually I see people indeed treating null as none value.

Zero is a perfectly valid memory address.

The ability to have uninitialised pointers is also a terrible mistake.

It doesn't make zero sense to be, but I feel like it is strongly strongly strongly over-rated as a defect.

Yes it probably has lost us a couple billion in productivity by now, but I struggle to think of times this has had impact at any of the orgs I've worked at.

People love flipping out about js's weird implicit casting rules (the "wat") talk, but it too feels like one of these things that people will adoringly latch onto as a defect & use endlessly as some buge mortal flaw, even though it's an issue once or twice early in your codership when you didnt know what you were doign anyways then you are over it (and today, typescript & linters will shield you from harm here).

I don't want to totally write this shit off, but the negative antagonistic fervor & dogmatism people will adopt when they find some leverage to confirm their negarive biases is truly staggering, and an issue of great great social harm in my mind. Better advocacy against these issues would be welcome, but man, the discourse & discussion of these "defects" feels so uncontrolled & Dark Side rooted, not real, decoupled from the situation I feel on the ground.

Reply on news.ycombinator.com