[treis]

There's a lot of merit in this. I call Go the Honda Odyssey Minivan of the programming world. It doesn't do anything exceptionally well but it does lots really well and in a way that's simple and reliable. Especially for the backend serving react front end niche.

But it's also a pig to write and comes with a lot of foot guns. Especially the Null handling. Somehow they made it worse than every other language.

[lanstin]

Nilaway linter FTW here.

[a012]

Why the Null handling and in Go is worse than others?

[kevinmgranger]

Another reason why it's worse is how it breaks logical laws thanks to the nil interface bug: https://go.dev/doc/faq#nil_error

Well, they'll call it a design decision, not a bug. I guess I'm being charitable.

[oconnor663]

Some weird nils don't compare equal to other nils. It's surprisingly easy to construct the weird kind by accident, because the conversion is automatic and invisible.

[treis]

It sets primitives to 0, "", false etc. Which is almost always but not always fine. And if they're complex objects you still get NPEs

To get true nullable fields you need to use pointers. That's a whole topic in itself but they're awkward.

It's much worse than true nullable objects that your compiler can check for NPEs. It throws fewer NPEs but at the expense of data integrity where you don't know if your 0 is actually a 0 from the user or a null.

[Lvl999Noob]

What if Go went all the way? Referencing a zero pointer (nil) gives you the zero value of the pointed to type. If you try to access a zero map, it tries to deference the zero pointer to the underlying buffer. The zero pointer gives you the zero slice with zero length. The presence check fails without crashing and you get some pretension of reasonable behaviour.

[clausecker]

Really bad idea.

Silently returning some (the wrong) value is always worse than catching the error right then and their and panicking. A panic is a noticeable symptom of something just having go wrong that is easy to chase after and debug. A silently returned wrong value just causes data corruption down the line, at great pain. It is very annoying to debug, in particular if people start to some times rely on this behaviour as an intentional part of their data flow.

[Lvl999Noob]

I agree. I prefer Optionals over Nulls in any case. This was just a thought of what if Go went all the way instead of just halfway. In my ideal language, you would have explicit assignments and compiler checked (runtime checked if absolutely necessary) pointer validity (with allowed length) at construction. As far as I know, the only time you need to make a pointer and say "trust me" is when doing MMIO so that can given its own mechanism. If it exists in the program state, it's valid.

[ptman]

So what happens when you write through the nil pointer?

[Lvl999Noob]

Well, what happens when you write through an invalid pointer? The runtime can swallow the write or crash the program or allocate new storage and replace the pointer. Depends on the wanted semantics.

[chuckadams]

Nil of course (nothing happens). Not saying it’s a good idea, it would just be consistent.

[MintPaw]

I think there's a large subset of programmers now who consider null checking (or even the existence of null) to be bad, and prefer something else like exceptions or option types. I don't get it personally.

[chuckadams]

The existence of null is not the problem, it’s when null populates every single non-primitive type, making every access into a logic bomb unless explicitly checked. When null is a distinct type, there’s no problem at all.