3 ms·
Yes, it's a design flaw. It means the dev can make a mistake, forget to check for nil, BAM CRASH! I even wrote a blog post about this very thing: https://waka
by welder 3y ago
Yes, it's a design flaw. It means the dev can make a mistake, forget to check for nil, BAM CRASH!
I even wrote a blog post about this very thing:
https://wakatime.com/blog/48-go-desperately-needs-nil-safe-types https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...
Nullable types allow devs to write safe functions (functions that don't allow nullable types as input) and spread that safety through the whole codebase. That safety isn't even an option without having nullable types. Nullable types also mean the compiler knows and warns devs if they forgot to check for nil. There's really no reason why Go sholdn't have nullable types.
- kaashif 3y ago> There's really no reason why Go sholdn't have nullable types. Don't you mean non-nullable types? Go does have nullable types, everything is nullable. The blog post you linked calls them "non-nil types".
- wrs 3y ago“Nullable types” is a phenomenon that occurs when non-nullable types are introduced to a language that started with null and already has libraries that rely on it. When you change the default to be non-nullable, you have to introduce the explicit concept of nullability for backwards compatibility, thus “nullable types”. Like, if you already had type X that could be null, and you change the language so X can’t be null, now you need the type Nullable<X> (often written something like X?) to let it be null again. C# and Swift are examples of this evolutionary process.
- welder 3y agoYea, non-nullable types. Thanks.