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

191–200 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#191

Post by xyzzy_plugh »

tw061023 wrote: post #174
danenania wrote: post #70

Earlier quoted context omitted.

Go is just making a certain set of tradeoffs. If you try to fix all the "mistakes developers have been doing for decades", you get Rust. And considering that Rust is already Rust, there is not much point in trying to make Go another Rust. The line has to be drawn somewhere. I think everyone has certain things they'd put on the other side of that line, and strict nils are probably at the top of the list for many, but…

The argument is that Go is making a _wrong_ set of trade-offs. It was designed, specifically, as per Rob Pike, for _bad_ developers. Developers who couldn't be productive at Google because they weren't properly taught at unis [0]. Then it caught momentum and then here we are, discussing a bad language designed for bad developers as if there is nothing better we can do with our lives. [0] https://news.ycombinator.com/…

If you think developers at Google are bad and weren't taught fundamentals then we live in different universes.

Pike's point is that peak PLT is too lofty to be productive or even useful for folks who are actually technically competent and literate relative to the rest of the industry. No one will get anything done if they're spending all their time teasing an advanced type system into inferring the required program.

Re: NilAway: Practical nil panic detection for Go

#192

Post by demi56 »

As a language that’s focused on backward compatibility than features oriented this is the best and optimal way to reduce some of Go’s loopholes. The problem of using developer tooling to solve the innate problems is that they lack awareness

I do recommend the Go team to find a way to these tools to run before it complies, just doing go build while going through these tools first goes a long way than just using scripts

Re: NilAway: Practical nil panic detection for Go

#193

Post by Kamq »

stouset wrote: post #179
Kamq wrote: post #177

Earlier quoted context omitted.

type Gender int const ( Unspecified Gender = iota Male Female Other ) Works the same way. Declaring an empty variable of the type Gender (var x Gender) results in unspecified.

…and now you need to check for nonsense values everywhere, instead of ever being able to know through the type system that you have a meaningful value. It’s nil pointers all over again, but for your non-pointer types too! Default zero values are yet another own goal that ought to have been thrown away at the design stage.

> instead of ever being able to know through the type system that you have a meaningful value.

That's... not what I'm looking for out of my type system. I'm mostly looking for autocomplete and possibly better perf because the compiler has size information. I really hate having to be a type astronaut when I work in scala.

So, I mean, valid point. And I do cede that point. But it's kind of like telling me that my car doesn't have a bowling alley.

Re: NilAway: Practical nil panic detection for Go

#194

Post by erik_seaberg »

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…

If a tool is any good I’m going to be using it for years. I’d much rather spend more time studying reusable ways the language can help me solve a problem with less code; that’s what’s productive. A quickly learned language is like a nearly empty toolbox.

Re: NilAway: Practical nil panic detection for Go

#195

Post by Seb-C »

xyzzy_plugh wrote: post #185
Seb-C wrote: post #184

I have been thinking about this problem for a long time as well. But I think that focusing on nils is a wrong analysis. The problem is the default zero-values dogma, and that is not going to change anytime soon. Sometimes you also need a legitimate empty string or 0 integer, but the language cannot distinguish it from the absence of value. In my codebase, I was able to improve the readability of those cases a lot by…

It's not a dogma it's a breaking change to the language. Removing default zero-values is effectively a different language. Literally none of my code over the past several years (which otherwise all still works perfectly as-is) would work. The Go team is very careful to avoid breaking changes (cue all the usual Well Actually comments regarding breaking changes that affected exactly zero code bases) and rightfully so.…

I didn't said that we should remove default values, that is a wrong interpretation of my message.

For example we could have a new non-nilable pointer type (that would not have any default value), or an optional monad natively in the language (or any other thing in-between, there are many possibilities). That would allow the compiler to statically report about missing checks, without breaking backward compatibility.

But we all know that it's not going to happen soon because while not breaking any existing code, it goes against the "everything has a zero-value" dogma. That was the meaning of my message.

Re: NilAway: Practical nil panic detection for Go

#196

Post by eviks »

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.

My basis is the %, not the simple fact that it has irrelevant instances.

So let me charitably ask directly: have you looked through all the examples at least on the first couple of pages? And if you have, what % of instances is relevant to your point?

Re: NilAway: Practical nil panic detection for Go

#197

Post by eviks »

xyzzy_plugh wrote: post #191
tw061023 wrote: post #174

Earlier quoted context omitted.

The argument is that Go is making a _wrong_ set of trade-offs. It was designed, specifically, as per Rob Pike, for _bad_ developers. Developers who couldn't be productive at Google because they weren't properly taught at unis [0]. Then it caught momentum and then here we are, discussing a bad language designed for bad developers as if there is nothing better we can do with our lives. [0] https://news.ycombinator.com/…

If you think developers at Google are bad and weren't taught fundamentals then we live in different universes. Pike's point is that peak PLT is too lofty to be productive or even useful for folks who are actually technically competent and literate relative to the rest of the industry. No one will get anything done if they're spending all their time teasing an advanced type system into inferring the required program.

How does it apply to this specific issue? What is so lofty and unproductive in proper null handling?

Re: NilAway: Practical nil panic detection for Go

#198

Post by ludiludi »

I got a nil pointer deref panic trying to use this tool:

$ nilaway ./...

panic: runtime error: invalid memory address or nil pointer dereference [recovered]

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x100c16a58]

Re: NilAway: Practical nil panic detection for Go

#199

Post by xyzzy_plugh »

eviks wrote: post #197
xyzzy_plugh wrote: post #191

Earlier quoted context omitted.

If you think developers at Google are bad and weren't taught fundamentals then we live in different universes. Pike's point is that peak PLT is too lofty to be productive or even useful for folks who are actually technically competent and literate relative to the rest of the industry. No one will get anything done if they're spending all their time teasing an advanced type system into inferring the required program.

How does it apply to this specific issue? What is so lofty and unproductive in proper null handling?

I did not suggest it applies to this specific issue, I replied to a comment containing inflammatory remarks, but I'll bite: To answer that you need to first produce the minimum change to the language that provides this functionality.

A solution might be optionals, which might require sum types, which might require generics (which Go just learned), which most definitely requires a more complex type system, which almost certainly involves longer compiler times.

Is that all worth it? I don't know. The Go team certainly didn't think so.

Languages that I'm aware of that do solve this are Scala, Rust, Kotlin to some extent, Haskell... languages which do not have a reputation of being stable, easy to learn, easy to read and understand, compile quickly, etc.

Re: NilAway: Practical nil panic detection for Go

#200

Post by xyzzy_plugh »

Seb-C wrote: post #195
xyzzy_plugh wrote: post #185

Earlier quoted context omitted.

It's not a dogma it's a breaking change to the language. Removing default zero-values is effectively a different language. Literally none of my code over the past several years (which otherwise all still works perfectly as-is) would work. The Go team is very careful to avoid breaking changes (cue all the usual Well Actually comments regarding breaking changes that affected exactly zero code bases) and rightfully so.…

I didn't said that we should remove default values, that is a wrong interpretation of my message. For example we could have a new non-nilable pointer type (that would not have any default value), or an optional monad natively in the language (or any other thing in-between, there are many possibilities). That would allow the compiler to statically report about missing checks, without breaking backward compatibility. B…

You are wrong regardless: there is no such dogma. There are numerous ongoing proposals discussing how to accomplish this. You're welcome to contribute. It took me a minute to find these proposals, as examples:

https://github.com/golang/go/issues/57644

https://github.com/golang/go/issues/19412

I interpret your comments as propagating FUD in bad faith.

Post reply on HN