[flagged]
[deleted]
NilAway: Practical nil panic detection for Go
161–170 of 262 posts
Re: NilAway: Practical nil panic detection for Go
#162It 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
[deleted]
Re: NilAway: Practical nil panic detection for Go
#163Earlier quoted context omitted.
This is a good point. Null pointers are the billion-dollar mistake, but the real billion-dollar mistake is having "zero values" in your language. In addition to the problems with null pointers, zero values make loose constructor semantics like C# and Java tempting, where objects can exist in a not-fully-initialized state, leading to lots of room for confusing bugs. Without zero values to fall back on as a crutch, the…
Yeah technically you can always default init fields to None, but then you have to type everything as an Option and the ergonomics are so bad you're really incentivised not to do that. In that case you bundle that in a transient structure (a builder) and you get rid of it afterwards.
Or you use MaybeUninint, which I think is a great example of how unsafe Rust exposes to potential memory unsafety but grants you control when you need it.
Re: NilAway: Practical nil panic detection for Go
#164Earlier quoted context omitted.
> 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.
Result is in one of two states: It either has value of type T, or error of type E. (*T, error) is either T (non-nil, nil), or error (nil/undefined, non-nil), or both (non-nil, non-nil), or neither (nil, nil). By convention usually only the first two are used, but 1) not always, 2) if you rely on convention why even have type system, I have conventions in Python. Leaving aside pattern matching and all other things whi…
I don't know much Rust, but wouldn't the analogy to (*T, error) be Result, E>, which has 3 states? Or is that not a common construct?
Because *T could be nil or non-nil, it seems like the analogy would be a nullable type in the Result. In Go, (T, error) would only have the states (non-nil, nil) and (non-nil, non-nil) if T is not a pointer. Still, the Result type seems better to me because the type itself is encapsulating all of this (and the error I guess cannot be null).
Re: NilAway: Practical nil panic detection for Go
#165Earlier quoted context omitted.
And billing, and reporting, and regulatory compliance, and inventory management, and abuse detection, and routing, and operations, and...
still, linux kernel is around 30 million lines of code if I'm not mistaken as a reference. most probably they have their reasons, but it smells weird to me.
It's can be difficult to understand by big companies write so much code, but it becomes obvious once you're inside of one: business software can be arbitrarily complex, because businesses can be arbitrarily complex. The guys in suits earn their paychecks by constantly coming up with new things the business could be doing.
"All" a kernel does (for some very large value of "all") is schedule userspace programs and manage the system's physical resources (memory, disk, devices). You can reach a point where a kernel is done, in the sense that it meets those basic needs with an acceptable level of performance. Kernel developers don't make extra money for every new feature they add - if the system is good enough, then it's good enough.
Re: NilAway: Practical nil panic detection for Go
#166Earlier quoted context omitted.
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.
And yet it's a productive language with significant adoption, go figure.
They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people.
The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.
Re: NilAway: Practical nil panic detection for Go
#167cool... what does this mean the best linter / correctness checking is at the moment? I have some code that eventually core dumps and honestly I don't know what I'm doing wrong, and neither do any golang tools I've tried :( maaaaaybe there's something that'll check that your code never closes a channel or always blocks after a specific order of events happens...
I don't think a pure Go program can core dump, unless you use Cgo (wrongly) or unsafe. It can only panic.
I’ve seen it happen before because the stdlib actually directly just makes POSIX syscalls for a lot of things by default instead of using the native Go implementations and so you’re implicitly reliant on C code
Re: NilAway: Practical nil panic detection for Go
#168Earlier 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.
Yes, and go opts to include features that unnecessarily increase complexity in this manner, such as nil values.
> All of these are behavior and operators that are documented in the language spec. So how is any of these a "footgun"?
By this logic, no language with a spec can have footguns. C and C++, notorious for their footguns, both specify their behavior in the spec, so do they not have any footguns?
Re: NilAway: Practical nil panic detection for Go
#169Earlier quoted context omitted.
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.
One answer would be to provide something like a GetPointer() method which, if the inner pointer is nil, creates a new struct of type T and returns a pointer to it.
Re: NilAway: Practical nil panic detection for Go
#170I 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 commo…
In one case, it couldn’t tell that a slice couldn’t go out of bounds because I was iterating through it backwards instead of forwards. In another case, I had a helper method on a type to deal with initializing a named map type, but it couldn’t see that and thought the map was going to explode from being nil. Those are two false positives I remember off the top of my head. I can look it up again later.