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

121–130 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#121

Post by adra »

adtac wrote: post #31
npalli wrote: post #18

"The Go monorepo is the largest codebase at Uber, comprising 90 million lines of code (and growing)" Is this just a symptom of having a lot of engineers and they keep churning code, Golang being verbose or something else. Hard time wrapping my head around Uber needing 90+ million lines of code(!). What would be some large components of this codebase look like?

Imagine a multidimensional matrix with various payment methods, local regulations, cloud providers, third party dependencies, web/mobile platforms, etc. Then also add more dimensions for internal things like accounting, hiring, payroll, promotions, compliance, security, monitoring, etc. Then double it for Uber Eats or whatever. There's a lot of overlap and some invalid combinations, but you're still left with a huge…

Dang, a little more verbose? Understatement of a lifetime. It's fine, if you like it not whatever, but it is quite a bit more verbose than many languages that I've used. My number 1 qualms go is with such simple building blocks requiring a bunch of redundant boiler plate. You're welcome to disagree with my opinion here.

A lot of people seems to gravitate toward languages with less dense cognitive load. I have learned to love kotlin, but its also a super dense set of syntax to power it's very expressive language.

Re: NilAway: Practical nil panic detection for Go

#122

Post by cedws »

fizx wrote: post #93
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

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.

Re: NilAway: Practical nil panic detection for Go

#123

Post by 65a »

vore wrote: post #106
masklinn wrote: post #34

Earlier quoted context omitted.

> Can this actually manifest? Yes. Per rsc ( https://research.swtch.com/gorace ) > In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program. That races undermine memory safety in go has been used in CTFs: https:…

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

Re: NilAway: Practical nil panic detection for Go

#124

Post by candiddevmike »

aatd86 wrote: post #9

Very interesting work. I wonder what were the difficulties encountered. Aliasing? Variable reassignment wrt short declaration shadowing? Hopefully with time, when exploring union types and perhaps a limited form of generalized subtyping (currently it's only interface types) we'll be able to deal with nil for good. Nil is useful, as long as correctly reined in.

It's really easy to check a field of a pointer struct without first checking the struct is non nil. Would be interesting if go vet or test checked this somehow.

Re: NilAway: Practical nil panic detection for Go

#125

Post by anonacct37 »

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".

Re: NilAway: Practical nil panic detection for Go

#126

Post by robryan »

wg0 wrote: post #89

90 million lines of code to .. call a cab? Genuinely curious what's so much of business logic is for.

A lot of it will be location based. It has come up before here in the discussion of why there is so much in the app. They have to cater for all the different rules in every jurisdiction.

Re: NilAway: Practical nil panic detection for Go

#128

Post by 65a »

triyambakam wrote: post #112
tehjoker wrote: post #105

Earlier quoted context omitted.

speaking from personal experience, i selected go for a project because it is high perf, automatically uses all cores w/ goroutines, and is type checked

> type checked Kinda...

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

Re: NilAway: Practical nil panic detection for Go

#129

Post by maccard »

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…

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.

Re: NilAway: Practical nil panic detection for Go

#130

Post by andreyvit »

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 not how this works in practice. Instead, you define an extra “invalid” value for almost every scalar type, so invalid would be 0, male 1 and female 2. Effectively this makes (almost) every scalar type nullable. It is surprisingly useful, though, and I definitely appreciate this tradeoff most of the time.

(Sometimes your domain type really does have a suitable natural default value, and you just make that the zero value.)

Post reply on HN