Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Robert Engels]

Code that is subject to null dereferences, it also susceptible to any incorrect dereference - (e.g. look up in a map using the the wrong key (not just type)) - the program may not crash, but produce incorrect results - which is arguably worse.

There is no silver bullet to solve bad dereferences.

-----Original Message-----
From: kloste...@gmail.com
Sent: Feb 18, 2020 9:55 AM
To: golang-nuts
Subject: Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

I'd say that's not solving the problem, but making it bigger. Do not 
recover from nil panics, instead fix the nil dereference bug and avoid 
the panic completely. 

It is never that easy in a medium to big application with a 10+ people team working on it. 

The problem with that reasoning is that you could use it for anything and then we would never improve any programming language or create others. Ideally, the compiler will catch all the bugs it possibly can so that the programmer can spend the thinking energy on resolving the problem. 

For example, Go could have perfectly followed the same approach as C for the arrays: rely on the user to pass the length everywhere and forget about protecting against out-of-bounds accesses. The designers decided not to do so, and thanks to that, you can forget about memory corruption and focus on what matters.

They could have thought: "Hey, fix all the memory corruption bugs and you will not have those problems". But that's something really hard to accomplish.

I would love to be able to forget about nil-pointer dereference errors. Sure! I can add checks everywhere, but this means I need to think about this, and that is precious energy that doesn't go to solving the problem I really want to solve.

Being said this, I know it is not an easy problem to solve and there are always trade-offs. But, hey!, maybe there is a good solution hidden somewhere that fits perfectly in Go. Let's find it out!

El martes, 18 de febrero de 2020, 12:22:38 (UTC), Jan Mercl escribió:

On Tue, Feb 18, 2020 at 12:44 PM <klos...@gmail.com> wrote:

> Well, other languages use the optional/maybe type.

The CPU does not care how humans call the abstraction. It has still to
do the same old thing: check some value for being equal/not equal to a
sentinel value or check a tag value for the same effect. That means
additional cost wrt to memory consumption. Additionally, now the
compiler may enforce the check everywhere when humans may know better.
So it buys more safety, undeniably, but as always, there are no free
lunches.

> The problem with nil-errors struck me hard in Go when I realized that, no matter how many "recovers" I write in my server app, if a goroutine is spawned and hits a nil pointer dereference, the whole server crashes. There is no protection inside the language against this (let me know if there is a way)

I'd say that's not solving the problem, but making it bigger. Do not
recover from nil panics, instead fix the nil dereference bug and avoid
the panic completely.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e6c9b79c-bf3a-413f-8a79-063a3e1da271%40googlegroups.com.

-- 

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/145256857.1124.1582043369067%40wamui-fuzz.atl.sa.earthlink.net.