Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excessive nil pointer checks in Go

konradreiche.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: Excessive nil pointer checks in Go

#111

Post by saghm »

Joker_vD wrote: post #40

> You may attempt to address this by pushing the problem up one layer. You now check for nil and return an error to flag the nil dependency as an invalid state. > It’s better, but it’s still not correct. Why not? Because we still allowed the invalid state to enter our system. A nil pointer is still being passed to our function, which puts the burden of deciding whether to trust the input on code that should have rece…

> Wait... is the author operating under an assumption that I control (almost) the whole of my codebase, so there is no need to have the boundaries inside of it?

Do you just use all global variables in your code or something? I'm pretty sure you probably have some stuff you use boundaries for even when your control everything, because they're useful.

Re: Excessive nil pointer checks in Go

#112

Post by ktpsns »

Zambyte wrote: post #107
ktpsns wrote: post #106

Earlier quoted context omitted.

Honest question, what is the zig version of goroutines these days? They removed async from the spec. Honestly the only reason why I stick to golang for some projects are goroutines.

Zig 0.16.0 was the big, recent async update. Go channels are handled as std.Io.Queue, the select keyword is handled with std.Io.Select, and goroutines are handled with std.Io.async and std.Io.concurrent. The difference between async and concurrent calls are essentially: async calls may be called concurrently, or they may not (the execution of the async function is not dependent on the caller continuing to execute - l…

Thank you for this valuable comment!

I remember having read somewhere that zig now requires to pass the Io argument around, which one can interpret again as "colored functions". IMHO it is a missed opportunity not to implement a more polished syntax and make a message passing paradigm a "first class citizen" in zig. Anyway, I like the fact that zig is iteratively "improved" and not a virtually "dead" language compared to golang :-)

Re: Excessive nil pointer checks in Go

#113

Post by yencabulator »

turtleyacht wrote: post #2

What about wrapping nil in a Maybe or Option type?

Go fundamentally cannot not have a zero value. For Option that could be fine, you can say zero value is None and solve the superficial issue, but you have no way of preventing the x in Some(x) from being a zero value.

For Result, zero value being Ok(zero_value) seems like a very bad idea.

Go's idea of zero values is everywhere in the language spec. Removing it would be Go2, not the same language.

Re: Excessive nil pointer checks in Go

#114

Post by bvrmn »

uecker wrote: post #100
bvrmn wrote: post #95

Earlier quoted context omitted.

That's the reason language/compiler should directly support optionality. You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3

So it seems exactly the same to me?

Nice one. gcc/clang are smart enough to get .ok condition statically. I'm very curios how complex an expression could be.

Re: Excessive nil pointer checks in Go

#115

Post by zarzavat »

saghm wrote: post #110
zarzavat wrote: post #52

Earlier quoted context omitted.

There's nothing particularly special about null pointers: you can also have an invalid non-null pointer, e.g. through pointer arithmetic. When you write `int& ref = *ptr;` you are dereferencing the pointer with `*ptr` therefore you have promised that it's valid. The compiler doesn't need to do anything to validate ptr because it already has your assurance. It's really no different than if you were to write `printf("%…

> When you write `int& ref = ptr;` you are dereferencing the pointer with ` ptr` therefore you have promised that it's valid. Yes, that's exactly the problem. "I promise I didn't make a mistake when reasoning about this code" is tied for worst strategy in the world for preventing bugs, along with every other strategy that doesn't actually prevent bugs.

The danger and utility of pointer are two sides of the same coin. You can reduce the need for pointers but not eliminate them completely if you want to be able to call C functions or build low-level data structures.

The real problem is that references are not good enough in C++, so some C++ developers end up using pointers for everything. Rust's references are good enough that you can avoid using pointers most of the time.

Re: Excessive nil pointer checks in Go

#116

Post by ignoramous »

Fire-Dragon-DoL wrote: post #60
ignoramous wrote: post #57

Earlier quoted context omitted.

> Don't use pointers at all, always allocate structs on the stack Unless one makes the rookie mistake of passing these structs to pkg log (which box to any/interface{}) instead of slog [0]... then they escape to heap. If a project relies on avoiding heap allocs, prudent to 'go build -gcflags="-m"' on every check-in, and review the diff from that too. [0] https://go.dev/blog/slog

Good to know, but wouldn't that be something that pops up when profiling?

Runtime profiling / tracing (runtime.MemProfile & debug.FlightRecoder)? Yes... At test time (go bench -benchmem), also yes.
Post reply on HN