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

131–140 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#131

Post by andreyvit »

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 burden when writing the code, — and it does not result in more bugs or other sorts of problems.

Thing is, I, of course, am always thinking about types, nullability and the like. The mental type model is pretty rich. But the more intricacies of it that I have to explain to the compiler, the more drag I feel on getting things shipped.

And because Go is so simple, idiomatic, and basically things are generally as I expect them to be, maintenance is not an issue either. Yes, occasionally you are left wondering if a particular field can or cannot be nil / invalid-zero-value, but those cases are few enough to not become a problem.

Re: NilAway: Practical nil panic detection for Go

#132

Post by vips7L »

cedws wrote: post #122
fizx wrote: post #93

Earlier quoted context omitted.

There's much I don't love about Rust, but I feel golang could steal the ? operator and keep the spirit of go. Effectively, instead of result, err := doSomething() if err != nil { return nil, err } you'd get the same control flow with result := doSomething()?

That won't work because in Go you often need to wrap errors with additional context. I have worked with Rust Option/Rust types and found them extremely unergonomic and painful. The ?s and method chains are an eyesore. Surely PLT has something better for us.

Do go errors or rust options include stack traces?

Re: NilAway: Practical nil panic detection for Go

#133

Post by codetrotter »

tialaramex wrote: post #120
suremarc wrote: post #90

Earlier quoted context omitted.

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.

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…

> Default Gender = Male is... not great

    enum Gender {
        Unspecified,
        Male,
        Female,
        Other,
    }

    impl Default for Gender {
        default() -> Self {
            Self::Unspecified
        }
    }
or:

    enum Gender {
        Male,
        Female,
        Other,
    }
and use Option instead of Gender directly, with Option::None here meaning the same that we would mean by Gender::Unspecified

Re: NilAway: Practical nil panic detection for Go

#134

Post by vore »

65a wrote: post #123
vore wrote: post #106

Earlier quoted context omitted.

Kind of ironic the raison d'être of Go is a memory safe language for concurrent programming but you can easily footgun yourself into doing something memory unsafe using concurrency...

Go generaly doesn't used shared memory and concurrency, or at least it's been considered an anti-pattern: https://go.dev/blog/codelab-share

Yes, but at the same time shared memory concurrency is not considered an unsafe usage of Go either...

Re: NilAway: Practical nil panic detection for Go

#136

Post by madeofpalk »

65a wrote: post #128
triyambakam wrote: post #112

Earlier quoted context omitted.

> type checked Kinda...

It is a type safe language, not exactly sure what you're hinting at here.

This entire post is a big workaround go's insufficient type system because nil is not modelled in it. That's not safe.

Re: NilAway: Practical nil panic detection for Go

#137

Post by [deleted] »

cedws wrote: post #122
fizx wrote: post #93

Earlier quoted context omitted.

There's much I don't love about Rust, but I feel golang could steal the ? operator and keep the spirit of go. Effectively, instead of result, err := doSomething() if err != nil { return nil, err } you'd get the same control flow with result := doSomething()?

That won't work because in Go you often need to wrap errors with additional context. I have worked with Rust Option/Rust types and found them extremely unergonomic and painful. The ?s and method chains are an eyesore. Surely PLT has something better for us.

[deleted]

Re: NilAway: Practical nil panic detection for Go

#138

Post by unrealhoang »

codetrotter wrote: post #133
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…

> Default Gender = Male is... not great enum Gender { Unspecified, Male, Female, Other, } impl Default for Gender { default() -> Self { Self::Unspecified } } or: enum Gender { Male, Female, Other, } and use Option instead of Gender directly, with Option::None here meaning the same that we would mean by Gender::Unspecified

I think they are talking about the cons of Go allowing zero value. Rust doesn’t have that problem.

Re: NilAway: Practical nil panic detection for Go

#140

Post by steveklabnik »

cedws wrote: post #122
fizx wrote: post #93

Earlier quoted context omitted.

There's much I don't love about Rust, but I feel golang could steal the ? operator and keep the spirit of go. Effectively, instead of result, err := doSomething() if err != nil { return nil, err } you'd get the same control flow with result := doSomething()?

That won't work because in Go you often need to wrap errors with additional context. I have worked with Rust Option/Rust types and found them extremely unergonomic and painful. The ?s and method chains are an eyesore. Surely PLT has something better for us.

In Rust you can wrap a context by chaining a context method on before the ?, at least with libraries like anyhow.
Post reply on HN