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.