I agree however it is only valuable under specific circumstances while it can frequently create hidden traps. On balance it causes more problems than it solves. Which is why I suggested it should be an optional flag enabled on the backend rather than the default.

Maybe/Option would be better.

NULL is what we've got though. setting columns to not null is leaps ahead of most programming languages anyway.

> On balance it causes more problems than it solves

This is far from clear

Like everything, it depends on your language and framework. But after 30 years of experience writing software in strictly typed languages, I’ve seen lots of people get caught out with nullable fields.

However if you’re main body of experience is Perl (for example) then NULL isn’t ever an issue.

Right, because no Perl developer has ever used SQL

I get Perl isn’t trendy these days but Perl actually has a very robust set of DB libraries and I have worked in several places were it was the preferred language.

Perl has by far the best DB tooling of any of the many languages I’ve worked with. My point was sarcasm as rebuttal to the idea that a Perl developer might not have encountered a null value

Actually I said NULL isn’t an issue in some languages with looser type systems, not that other developers wouldn’t have encountered a NULL before.

Eg Perl doesn’t have a nil type like Go, so variables passed to DBI which are NULL in the returned SQL query will be undef’ed instead. Effectively a bit like NULL but it only causes a problem if your running with strict flags (which you shouldn’t do on production systems anyway for various reasons; but that’s another topic entirely) otherwise that value falls back to the language default of “”/0/false.

With languages like Go you can easily end up with a panic if you’re not careful (where you’re trying to cast a nil interface{}). Which, I’m guessing, is why this Go library being discussed here does it’s own NULL checking.

> Eg Perl doesn’t have a nil type like Go...

That would be Perl 5. Perl 6 does. From https://docs.perl6.org/type/Nil :

"The value Nil may be used to fill a spot where a value would normally go, and in so doing, explicitly indicate that no value is present."

Right, but Perl 6 is also now a different language in its own right.

> With languages like Go you can easily end up with a panic if you’re not careful (where you’re trying to cast a nil interface{})

How is this any different to the runtime error you’d get in Perl if you attempted a method call on an undefined value you’d expected to be an object?

It’s different because the DBI wouldn’t return an object for a nullable table record. Which is what we are specifically talking about. Sure other parts of your code might fail if you’re trying to use a scalar as an object (or such like) but that would consistently fail regardless of nullable types on the database.

So I’m not going to argue that Perl doesn’t also have its own hidden traps (a great many of them in fact) nor that it’s interpretation of OOP isn’t terrible but the scope of this discussion was about nullable types and not anything else you now want to draw into the argument.