Live data from Hacker News

NilAway: Practical nil panic detection for Go

uber.com

221–230 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#221
post #197

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?

Nothing, the question is whether it is important enough to be included in the language.

Just because person A thinks this is hugely important, doesn't mean person B has to agree, or that B is a bad developer.

Re: NilAway: Practical nil panic detection for Go

#222

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…

I don't think anyone is suggesting that Go should be like Rust. It's too late for that. We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead.

> We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead.

And how well did that work out for Haskell?

https://gist.github.com/graninas/22ab535d2913311e47a742c70f1...

Just because one person thinks Functional Programming is the right way to do it, doesn't mean another person has to agree. The same goes for every paradigm, and language feature under the sun. Different people want different things, different projects have different needs.

No single language gets everything right, no single paradigm solves every problem, no feature is a "must have" in every language. A functional approach might be great or a productivity killer depending on the use case. A GC may be the best thing in the world or a performance nightmare. OOP may be a really good idea or a path to unmaintainable crap depending on the implementation.

There are no silver bullets.

The only thing that is ABSOLUTELY certain: When people get told "Our way is better, you should use our way", despite the fact that there are no silver bullets, people will resist. And that resistance can lead to languages vanishing into obscurity.

Re: NilAway: Practical nil panic detection for Go

#223
post #102

Earlier quoted context omitted.

By definition, every bit added to a language makes it more complex to learn. Sure, it could be done. Lots of things could be done to Go. The people who invented it are among the most brilliant computer scientists alive. It's a pretty sure bet that they know about, and in great detail, every single thing people complain Go doesn't have. So every thing that is "missing" from Go isn't in it for a reason. "Perfection is…

It is not like Oberon, Plan 9, Inferno and Limbo were such a huge commercial successes. Had those brilliant computer scientists not been employed at Google, it would have been another Oberon or Limbo.

Yes, having a good backing by a huge entity is a bonus.

But it's not a guarantee for success either. Google+ anyone?

Re: NilAway: Practical nil panic detection for Go

#224

Earlier quoted context omitted.

Not only that but those behaviors are patently not footguns or unreasonable in any way

> "Send and receive operations on a nil channel block forver." I literally can not imagine a worse behavior than my program blocking forever. Of all of the things my program can do, short of giving remote code execution, blocking is literally the worst one I can think of.

Goroutines blocking is normal procedure in a a Go program. It also isn't a problem, unless my code is broken and allows all Goroutines to block simultaneously...in which case the runtime automatically terminates the program with a Deadlock-Panic.

The behavior of nil-channels always blocking is on purpose, and tremendously useful in functions where we receive from multiple channels via `select`. It allows the function to easily manipulate it's own receive behavior simply by setting the local reference to the channel to `nil`.

Since `selects` can also have `default`, the resulting functions don't have to block either.

Re: NilAway: Practical nil panic detection for Go

#225
post #205

Building a type checker on global inference is the kind of thing that sounds romantic in academia - "no type definitions and yet get type checking!" - but ends up being a nightmare to use in practice. Nilability of return values should be part of functions public interface. It shouldn't come as a surprise under certain circumstances of using the code. The problem of global inference is that it targets both the produc…

> Building a type checker on global inference is the kind of thing that sounds romantic in academia - "no type definitions and yet get type checking!" - but ends up being a nightmare to use in practice.

Hi! I use global type inference and I love it.

Re: NilAway: Practical nil panic detection for Go

#227
post #102

Earlier quoted context omitted.

It is not like Oberon, Plan 9, Inferno and Limbo were such a huge commercial successes. Had those brilliant computer scientists not been employed at Google, it would have been another Oberon or Limbo.

Yes, having a good backing by a huge entity is a bonus. But it's not a guarantee for success either. Google+ anyone?

Indeed, yet it helps a lot, as proven by all wannabe C and C++ successor languages.

The only ones that are actually taking off, have the baking of major corps, even if it is only giving money into the project.

Re: NilAway: Practical nil panic detection for Go

#228

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…

As someone who is ~3 months out of uni, I don't really understand this amount of concern towards "new hires". I've interned at a place where I was thrown head-first into a industrial-grade Java codebase. The initial few weeks were rough. There were complex class hierarchies, patterns that weren't documented but had to be followed, interfaces from 10 different packages, really hard to grok names, magical DI, Lombok, complex mock testing all while 10 different linters and code coverage tools yell at you. But I cut through the complexity and finished my task in the end, not through any particular skill but by being stubborn and willing to learn.

None of the Google fresh hires I know personally are stupid. They are talented people who could be just as productive in a C++ or Java codebase. Maybe even better when you have features like Java's streams or C++ templates to throw at non-trivial problems. They might need more time, but it's something easily budgeted for. If new hires have to be productive from the first day, that's a problem the company has created and not the employee. If other languages have too many ways to do something, just enforce only using a few of them, teams have and continue to do that.

I use Golang in my current job. The library ecosystem seems fine. But even as a "new hire", the language frustrates me sometimes. Go's concurrency is "easy", but has a minefield of problems. Just off the top of my head, for-loop semantics [which to Golang's credit, is being fixed but it is absolutely a breaking change], just being able to copy a mutex by accident. These are bugs I've written and not had fun tracking down. In a year I'll have all these footguns memorized, but I could also have spent a year getting better at any other language. Even at my experience level, the Rust compiler gives me enough grief for me to know that when it's happy, whatever I've written will work. Nothing about Golang gives me that confidence.

Re: NilAway: Practical nil panic detection for Go

#229
post #71
post #60

Earlier quoted context omitted.

If you squint really hard, the work on generics is a step toward the future. If you don't squint, then I don't think so.

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…

You can make such a type and it works well in practice.

First we define the type, hiding the pointer/non-existent value:

    type Optional[Value any] struct {
        value  Value
        exists bool
    }
Then we expose it through a method:

    func (o Optional[Value]) Get() (Value, bool) {
        return o.value, o.exists
    }
Accessing the value then has to look like this:

    if value, ok := optional.Get(); ok {
        // value is valid
    }
    // value is invalid
This forces us to handle the nil/optional code path.

Here's a full implementation I wrote a while back: https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e...

Re: NilAway: Practical nil panic detection for Go

#230
post #197

Earlier quoted context omitted.

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 almos…

Thanks, I understand it was more a general inflammatory conversation, that's why I didn't like it and was wondering whether it could be grounded to this specific topic. Although I had in mind what "teasing an advanced type system" would be needed in this case that would lead to a loss of productivity, slower compliation is also relevant.

Though the reputation for those other languages mainly stem from their embrace of way more advanced concepts rather than null handling via optionals, I think that this specific concept makes it easier to learn/read/understand (though not compile quicker)

Post reply on HN