On Tue, Feb 18, 2020 at 12:44 PM <kloste...@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/CAA40n-XVWcKk7-zN-5A%3DKTjA2LO7gyhv%2B63%2BB4Ftv1Ssih3NtA%40mail.gmail.com.
