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

141–150 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#141

Post by leftyspook »

maccard wrote: post #129
tialaramex wrote: post #120

Earlier quoted context omitted.

This is one of those things which feels like just a small trade off against convenience for the language design, but then in practice it's a big headache you're stuck with in real systems. It's basically mandating Rust's Default trait or the C++ default (no argument) constructor. In some places you can live with a Default but you wish there wasn't one. Default Gender = Male is... not great, but we can live with it, s…

I write a decent amount of go - this isn't a defence of the current situation. > All of my code will need to special case this, what a disaster. No, your code should handle the error state first and treat the value as invalid up until that point, e.g. foo, err := getVal() if err != nil { return } // foo can only be used now It's infuriating that there's no compiler support to make this easier, but c'est la vie.

Man, if only over 30 odd years of PL research leading up to Go, somebody came up with a way to do it better.

Re: NilAway: Practical nil panic detection for Go

#143

Post by lazaroclapp »

anonacct37 wrote: post #125

I do like the approach of static code analysis. I found it a little funny that their big "win" for the nilness checker was some code logging nil panics thousands of time a day. Literally an example where their checker wasn't needed because it was being logged at runtime. It's a good idea but they need some examples where their product beats running "grep panic".

Actually, if we were running into cases where we aren't logging a panic which is actually happening in production, then the first thing to note is that we need to improve our observability. The issue might or might not be recoverable, but it should be logged. If nothing else, it should show up as a service crash somewhere within those logs, which is also something that service owners monitor and get alerts on.

The advantage of NilAway is not just detecting nil panic crashes after the fact (as you note, we should always be able to detect those eventually, once they happen!), but detecting them early enough that they don't make it to users. If the tool had been online when that panic was first introduced, it would have been fixed before ever showing up in the logs (Presumably, at least! The tool is not currently blocking, and developers can mistake a real warning for a false positive, which also exist due to a number of reasons both fundamental and just related to features still being added)

But, on the big picture, this is the same general argument as: "Why do you want a statically typed language if a dynamically typed one will also inform you of the mismatch at runtime and crash?" "Well, because you want to know about the issue before it crashes."

Beyond not making it all the way to prod, there is also a big benefit of detecting issues early on the development lifecycle, simply in terms of the effort required to address them: 'while typing the code' beats 'while compiling and testing locally' beats 'at code review time' beats 'during the deployment flow or in staging' beats 'after the fact, from logs/alerts in production', which itself beats 'after the fact, from user complains after a major outage'. NilAway currently works on the code review stage for most internal users, but it is also fast enough to run during local builds (currently that requires all pre-existing warnings in the code to either be resolved or marked for suppression, though, which is why this mode is less common).

Re: NilAway: Practical nil panic detection for Go

#144

Post by [deleted] »

adtac wrote: post #50

I'm not sure if that was the best example to showcase NilAway. I understand there's a lot of context omitted to focus on NilAway's impact, but why is foo returning a channel to bar if bar is just going to block on it anyway? Why not just return a *U? If foo's function signature was func foo() (*U, error) {}, this wouldn't be a problem to begin with.

[deleted]

Re: NilAway: Practical nil panic detection for Go

#145

Post by anonacct37 »

lazaroclapp wrote: post #143
anonacct37 wrote: post #125

I do like the approach of static code analysis. I found it a little funny that their big "win" for the nilness checker was some code logging nil panics thousands of time a day. Literally an example where their checker wasn't needed because it was being logged at runtime. It's a good idea but they need some examples where their product beats running "grep panic".

Actually, if we were running into cases where we aren't logging a panic which is actually happening in production, then the first thing to note is that we need to improve our observability. The issue might or might not be recoverable, but it should be logged. If nothing else, it should show up as a service crash somewhere within those logs, which is also something that service owners monitor and get alerts on. The ad…

That makes sense. I hope my first comment came across as I intended, which wasn't as criticism of the product but a suggestion about how to talk about the value of the product.

Re: NilAway: Practical nil panic detection for Go

#146

Post by bornfreddy »

andreyvit wrote: post #131
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

I write a lot of Go and used to write a lot of Swift. Swift is what you’ll consider a modern language (optionals, generics, strong focus on value types), while Go is Go. I appreciate both languages, and of course Swift feels like what you’d pick any day. But, after using both nearly side by side and comparing the experience directly, I’ve got to say, I’m so much more productive in Go, there’s SO much less mental burd…

As a single developer? Yes. As part of a team? Give me explicit type checks, please.

Re: NilAway: Practical nil panic detection for Go

#147

Post by lazaroclapp »

earthboundkid wrote: post #135

I tried it but got too many false positives to be useful.

We'd be interested in the general characteristics of the most common ones you are seeing. If you have a chance to file a couple issues (and haven't done so yet): https://github.com/uber-go/nilaway/issues

We definitely have gotten some useful reports there already since the blog post!

We are aware of a number of sources of false positives and actively trying to drive them down (prioritizing the patterns that are common in our codebase, but very much interested in making the tool useful to others too!).

Some sources of false positives are fundamental (any non-trivial type system will forbid some programs which are otherwise safe in ways that can't be proven statically), others need complex in-development features for the tool to understand (e.g. contracts, such as "foo(...) returns nil iff its third argument is nil"), and some are just a matter of adding a library model or similar small change and we just haven't run into it ourselves.

Re: NilAway: Practical nil panic detection for Go

#148

Post by [deleted] »

usrbinbash wrote: post #17
tuetuopay wrote: post #8

Earlier quoted context omitted.

> Insane that Go had decades of programming mistakes to learn from but it chose this path. Yup, every time I write some Go I feel like it's been made in a vaccum, ignoring decades of programming language. null/nil is a solved problem by languages with sum types like haskell and rust, or with quasi-sums like zig. It always feels like a regression when switching from rust to go. Kudos to Uber for the tool, it looks ama…

> ignoring decades of programming language True, and because of this, the language can be learned over a weekend or during onboarding, new hires can rapidly digest codebases and be productive for the company, code is straightforward and easy to read, libraries can be quickly forked and adapted to suit project needs, and working in large teams on the same project is a lot easier than in many other languages, the compi…

[deleted]

Re: NilAway: Practical nil panic detection for Go

#149

Post by insanitybit »

foldr wrote: post #52
insanitybit wrote: post #20

Earlier quoted context omitted.

You can `grep unwrap` for Rust, you need an entire SAT solver for Go.

That's almost literally what I just did, but what use is it? No-one is really going to go through all those unwrap calls and check them.

But... they could. And also, they do? It's not uncommon.

All of those could be checked or irrelevant, I have no idea.

Re: NilAway: Practical nil panic detection for Go

#150

Post by lazaroclapp »

anonacct37 wrote: post #145
lazaroclapp wrote: post #143

Earlier quoted context omitted.

Actually, if we were running into cases where we aren't logging a panic which is actually happening in production, then the first thing to note is that we need to improve our observability. The issue might or might not be recoverable, but it should be logged. If nothing else, it should show up as a service crash somewhere within those logs, which is also something that service owners monitor and get alerts on. The ad…

That makes sense. I hope my first comment came across as I intended, which wasn't as criticism of the product but a suggestion about how to talk about the value of the product.

No worries, that's how I understood it too :) Just adding a bit more context on why we feel the approach does beat "grep panic" for people checking out this thread.
Post reply on HN