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

NilAway: Practical nil panic detection for Go

uber.com

Post reply on HN
Print view View original

81–90 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#81

Post by richbell »

usrbinbash wrote: post #57
richbell wrote: post #49

Earlier quoted context omitted.

> True, and because of this... This is a false dichotomy. One does not imply the other. Go is also not a simple language. It is deceptively difficult with _many_ footguns that could have easily been avoided had it not ignored decades of basic programming language design. Many things also aren't straightforward or intuitive. For instance, this great list of issues for beginners: http://golang50shad.es/

> This is a false dichotomy. One does not imply the other. No it isn't, and yes it does. By definition, the more features I add to something, the more complex it becomes. So yes, Go achieves it's simplicity precisely by leaving out features. > this great list of issues I just picked three examples at random: "Sending to an Unbuffered Channel Returns As Soon As the Target Receiver Is Ready" "Send and receive operation…

> No it isn't, and yes it does. By definition, the more features I add to something, the more complex it becomes. So yes, Go achieves it's simplicity precisely by leaving out features.

More complex for whom? Not having generics made the compiler simple, but having to copy and paste and maintain identical implementations of a function (or use interface) adds more complexity for users.

Similarly, adding a better default HTTP client arguably makes Go more complex, but the "simple" approach results in lots of complexity and frustration for users.

> All of these are behavior and operators that are documented in the language spec. So how is any of these a "footgun"?

Perhaps I could have been clearer. I didn't mean that the entire list was of footguns, just that there are lots of confusing and unintuitive things beginners need to learn.

Some actual footguns off the top of my head:

- using Defer in a loop

- having to redeclare variables in a loop

- having to manually close the body of a http response even if you don't need it

Re: NilAway: Practical nil panic detection for Go

#82

Post by adtac »

nirga wrote: post #78

It amazes me that in 2023 this is not a solved problem by design of the language. Why go doesn’t adapt the “optional” notion of other languages so that if you have a variable you either know it is not null or know that you must check for nullness. The technology exists

That's what the `func foo() (*T, error)` pattern is for. It's actually better than syntactic sugar for optional values because now you also have a descriptive reason for why the value is nil.

But if you really cannot afford to return more than one bit of information, do `func foo() (*T, bool)`.

Re: NilAway: Practical nil panic detection for Go

#83

Post by richbell »

adtac wrote: post #79
richbell wrote: post #72

Earlier quoted context omitted.

> I'm sorry but nearly all of them are along the lines of "I came from language X and in X we did it this way, but Go's syntax is different". That's not a footgun. You're right, I meant to link that in reference to how Go can be difficult to learn despite how it simple it seems. Not sure how I a sentence. The overview of that site explains its purpose/necessity quite well. Some things are footguns, many are just conf…

> Nevertheless, they are frustrating and hamper the learning process But that is the learning process. What else is there to learn in a language if the syntax doesn't count? They're all Turing complete and all of them can do everything. All we need to do is learn the exact magic words.

I never said otherwise. My point is that Go is far harder to learn than they're implying. It certainly can't be learned over the weekend — well, maybe it can be, but the code you end up writing will Inevitably be full of resources leaks, panics, nil pointer issues, improperly handled errors, etc. You may be able to put together some basic logic, but you are far from understanding the language.

I don't think it's honest to parade Go as a language that's the paragon of simplicity that's easy to learn when that's simply not true. I also don't think it's honest for people to argue that addressing any of Go's countless warts would somehow make the language more complex or harder to learn.

Re: NilAway: Practical nil panic detection for Go

#84

Post by kortex »

adtac wrote: post #82
nirga wrote: post #78

It amazes me that in 2023 this is not a solved problem by design of the language. Why go doesn’t adapt the “optional” notion of other languages so that if you have a variable you either know it is not null or know that you must check for nullness. The technology exists

That's what the `func foo() (*T, error)` pattern is for. It's actually better than syntactic sugar for optional values because now you also have a descriptive reason for why the value is nil. But if you really cannot afford to return more than one bit of information, do `func foo() (*T, bool)`.

> a descriptive reason for why the value is nil.

Result does this. I forget exactly why Result is actually different from, and in fact superior to, `func foo() (*T, error)` but IIRC it has to do with function composition and concrete vs generic types.

Re: NilAway: Practical nil panic detection for Go

#85

Post by luxurytent »

Plenty of Go commentary in this thread but can I just say I'm glad to have learned about nilness? Suffered through a few nil pointer dereferences after deploying and having this analyser enabled in gopls (off by default for me at least) is a nice change.

Tested via vim and looks good!

Re: NilAway: Practical nil panic detection for Go

#86

Post by shakow »

foldr wrote: post #77
eviks wrote: post #65

Earlier quoted context omitted.

It's also worth reading the examples you post Like, one of the first files has only .unwraps in the comments (like a dozen of them in a file), some are infallible uses, some are irrelevant-to-runtime tooling, etc. But anyway, "some" is a lot smaller than "all". Just like some of memory safety issues would also have happened since you can still use unsafe in Rust, yet it's still a big step forward in reducing those is…

It's a list of all instances of ".unwrap()" in the project, so of course it includes instances irrelevant to my point. Seems uncharitable to assume that I haven't looked through it on that basis.

Then please pinpoint some problematic ones, so that not every reader has to delve into pages to continue the discussion.

Re: NilAway: Practical nil panic detection for Go

#87

Post by [deleted] »

pigeonhole123 wrote: post #67
usrbinbash wrote: post #57

Earlier quoted context omitted.

> This is a false dichotomy. One does not imply the other. No it isn't, and yes it does. By definition, the more features I add to something, the more complex it becomes. So yes, Go achieves it's simplicity precisely by leaving out features. > this great list of issues I just picked three examples at random: "Sending to an Unbuffered Channel Returns As Soon As the Target Receiver Is Ready" "Send and receive operation…

Not only that but those behaviors are patently not footguns or unreasonable in any way

[deleted]

Re: NilAway: Practical nil panic detection for Go

#88

Post by adtac »

richbell wrote: post #83
adtac wrote: post #79

Earlier quoted context omitted.

> Nevertheless, they are frustrating and hamper the learning process But that is the learning process. What else is there to learn in a language if the syntax doesn't count? They're all Turing complete and all of them can do everything. All we need to do is learn the exact magic words.

I never said otherwise. My point is that Go is far harder to learn than they're implying. It certainly can't be learned over the weekend — well, maybe it can be, but the code you end up writing will Inevitably be full of resources leaks, panics, nil pointer issues, improperly handled errors, etc. You may be able to put together some basic logic, but you are far from understanding the language. I don't think it's hone…

I agree that it's very unlikely for someone to learn Go in a week and start writing flawless code.

But Go's real strength is in its readability, not writability. I think it's very much possible to learn Go in a week, then read clean Go code like the standard library and understand exactly what's going on. At least that's my interpretation of what it means for a new grad to be productive in Go in less than a week. Nobody is expecting someone new to write production-grade libraries with intricate concurrency bits in their first week, but they're already productive if they can read and understand it.

As a rule of thumb we spend 10x more time reading code than we do writing it (code reviews, debugging, refactors). So why not optimise for it?

Re: NilAway: Practical nil panic detection for Go

#90

Post by suremarc »

mcronce wrote: post #71
aatd86 wrote: post #60

Earlier quoted context omitted.

If you squint really hard, the work on generics is a step toward the future. If you don't squint, then I don't think so.

With generics, can you not make a NonNil struct in Go, where the contents of the struct are only a *T that has been checked at construction time to not be nil, and doesn't expose its inner pointer mutably to the public? I would think that would get the job done, but I also haven't really done much Go since prior to generics being introduced Otherwise, since pointers are frequently used to represent optional parameter…

Every type in Go has a zero value. The zero value for pointers is nil. So you can't do it with regular pointers, because users can always create an instance of the zero value.
Post reply on HN