Reading through "roc for elm programmers", and I'm somewhat surprised that there's no "Maybe" type. Requiring developers to make their own custom maybe-ish types (e.g. the [Null | NonNull a] in the example) seems like it would substantially get in the way of code re-use, and making "generic functions" that are usable across domains. Is that on purpose?
(having no tuples makes sense, given that it's so low-friction to create ~anonymous records)
definitely on purpose!
my view is essentially that:
Maybe
in return values is overall worse than Result
with an error type that has no extra info. Much nicer to have all those operations collapsed into using Result
consistently imo.Maybe
as a way to have functions take "optional arguments" is something I think should be done very rarely, and when it is done, there's no benefit to having helper functions (e.g. Maybe.map
) because all you're doing is constructing it right when you pass it to the function (e.g. in Rust, foo(Some(bar))
), so since Roc lets you construct tags on the fly, Maybe
wouldn't have a significant advantage there over an ad-hoc tag union.Maybe
is very often misused for data modeling. The reason is that a lot of people learn languages with null
first, and then they learn "this language doesn't have null
, but it does have Maybe
, so whenever I would use null
I'll just swap in Maybe
," which leads to data model designs that have states which could have easily been ruled out by using a custom tag union instead. Result
is never used in data modeling and doesn't have this problem.so my hope in omitting Maybe
from the standard library is that it will:
:thumbs_up: encourage more functions to consistently return Result
when they might not always have a value to return
:thumbs_up: mean functions with optional arguments use more self-documenting tag unions than Maybe
:thumbs_up: lead to better data modeling due to not importing null
-based habits in the form of "s/null/Maybe
in data models
Last updated: Jul 06 2025 at 12:14 UTC