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

71–80 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#71

Post by mcronce »

aatd86 wrote: post #60
technics256 wrote: post #38

Is there any movement in the language spec to address this in the future with Nil types or something?

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 parameters, generics + sum types would get the job done; for that use case, it's one of two steps to solve the problem. I don't foresee Go adding sum types, though.

Re: NilAway: Practical nil panic detection for Go

#72

Post by richbell »

adtac wrote: post #64
richbell wrote: post #49

Earlier 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/

I'm sorry but nearly all of them are along the lines of "I came from language X and in X we did it this way, but Go's syntax is different". That's not a footgun. You know what's a footgun? Uncaught exceptions popping up in places far away from where they were created at which point you have very little context to deal with it robustly. Use after frees. FactoryFactoryFactories.

> I'm sorry but nearly all of them are along the lines of "I came from language X and in X we did it this way, but Go's syntax is different". That's not a footgun.

You're right, I meant to link that in reference to how Go can be difficult to learn despite how it simple it seems. Not sure how I a sentence.

The overview of that site explains its purpose/necessity quite well. Some things are footguns, many are just confusing time-wasters. Nevertheless, they are frustrating and hamper the learning process.

Re: NilAway: Practical nil panic detection for Go

#73

Post by usrbinbash »

tuetuopay wrote: post #69
usrbinbash wrote: post #17

Earlier quoted context omitted.

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

It's funny how I always hear the point about new hires for Go. My team is a Rust shop at $DAYJOB that I created basically from scratch, so I had to onboard every new hire on the codebase. It's amazing how confident they are due to the compiler having their back, and how confident I am their code won't blow up that much in prod. > code is straightforward and easy to read I have to disagree. I don't want to read 3 line…

>It's amazing how confident they are due to the compiler having their back, and how confident I am their code won't blow up that much in prod.

I get what you're saying, and I'm glad you are having such a good experience with it. Disclosure, I am not talking down to any language here...in fact I actually like Rust as a language, even though I don't use it professionally.

I am just saying that Go is incredibly easy to learn, and I don't think there are many people who disagree on this point, proponent of Go or not.

> I have to disagree.

We'll have to agree to disagree then :-) Yes, the code is verbose, but it's not really noise in my opinion. Noise is something like what happens in enterprise Java, where we have superfluous abstractions heaped ontop of one another. Noise doesn't add to the program. The verbose error handling of Go, and the fact that it leaves out a lot of magic from other languages doesn't make it noisy to me.

> I don't think those two are incompatible.

Neither do I, but that's the path Go has chosen. It may also have been poorly worded on my part. A better way of putting it: Go doesn't subscribe to the "add as much as possible" - mode of language development.

> But is it high-value productivity?

Writing the verbose parts of go, like error checking, isn't time consuming, because it's very simple...in fact, these days I leave a lot of that to the LLM integration of my editor :-)

Is is high value? Yes, I think so, because I don't measure productivity by number of lines of code, I measure it by features shipped, and issues solves. And that's where Go's ... how do I say this ... obviousness really puts the language into the spotlight for me.

Re: NilAway: Practical nil panic detection for Go

#74

Post by mcronce »

tuetuopay wrote: post #69
usrbinbash wrote: post #17

Earlier quoted context omitted.

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

It's funny how I always hear the point about new hires for Go. My team is a Rust shop at $DAYJOB that I created basically from scratch, so I had to onboard every new hire on the codebase. It's amazing how confident they are due to the compiler having their back, and how confident I am their code won't blow up that much in prod. > code is straightforward and easy to read I have to disagree. I don't want to read 3 line…

> Also, there may be a false sense of productivity. Go is verbose, and you write a lot. Sure if you spend most of your time typing then yes you are productive. But is it high-value productivity? Some more concise languages leave you more time to think about what you are writing and to write something correct. The feeling of productivity is not there because you are not actively writing code most of the time. IIRC plan9 makes heavy use of the mouse, and people feel less productive compared to a terminal because they are not actively typing. They are not active all the time.

This is my sense. "False sense of productivity" is an accurate statement - I've also found that it seems to be for a very specific (and not necessarily useful) definition of "productive", such as LOC per day.

It's not as bad as dynamic languages like Python, but very frequently Go codebases feel brittle, like any change I make might bring down the whole house of cards at runtime.

Re: NilAway: Practical nil panic detection for Go

#75

Post by foldr »

Philpax wrote: post #61
foldr wrote: post #51

Earlier quoted context omitted.

My link is to the rust repo on github. Does the Rust project not have proper standards for Rust code?

> Do not forget that in some scenarios using unwrap is totally fine if a panic is acceptable. Looking through the first few pages, most of these panics are easy to audit, and are infallible or in contexts where it doesn't matter (internal tooling, etc). That's a pretty stark difference to every single reference being a potential landmine.

Yes, you are probably less likely to get a panic caused by a nil reference in Rust than in Go. My point is that the equivalent software written in Rust (or most other languages with option types) would probably have had at least some of these very same bugs.

Re: NilAway: Practical nil panic detection for Go

#76

Post by [deleted] »

adonovan wrote: post #62
mseepgood wrote: post #6

Earlier quoted context omitted.

I don't think a pure Go program can core dump, unless you use Cgo (wrongly) or unsafe. It can only panic.

There are ways a Go program can fatal: by running out of heap, or stack, by corrupting variables by racing writes, by deadlocking, by misuse of reflect or unsafe, and so on.

[deleted]

Re: NilAway: Practical nil panic detection for Go

#77

Post by foldr »

eviks wrote: post #65
foldr wrote: post #15

Earlier quoted context omitted.

It's worth bearing in mind that some of these runtime panics would have happened anyway even if the code had been implemented in (e.g.) Rust. Ugly real world code tends to make quite frequent use of unwrap() or equivalents. For example: https://github.com/search?q=repo%3Arust-lang%2Frust+.unwrap%...

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.

Re: NilAway: Practical nil panic detection for Go

#78

Post by nirga »

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

Re: NilAway: Practical nil panic detection for Go

#79

Post by adtac »

richbell wrote: post #72
adtac wrote: post #64

Earlier quoted context omitted.

I'm sorry but nearly all of them are along the lines of "I came from language X and in X we did it this way, but Go's syntax is different". That's not a footgun. You know what's a footgun? Uncaught exceptions popping up in places far away from where they were created at which point you have very little context to deal with it robustly. Use after frees. FactoryFactoryFactories.

> I'm sorry but nearly all of them are along the lines of "I came from language X and in X we did it this way, but Go's syntax is different". That's not a footgun. You're right, I meant to link that in reference to how Go can be difficult to learn despite how it simple it seems. Not sure how I a sentence. The overview of that site explains its purpose/necessity quite well. Some things are footguns, many are just conf…

> Nevertheless, they are frustrating and hamper the learning process

But that is the learning process. What else is there to learn in a language if the syntax doesn't count? They're all Turing complete and all of them can do everything. All we need to do is learn the exact magic words.

Re: NilAway: Practical nil panic detection for Go

#80

Post by ikari_pl »

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

The same reason you can't get map keys without a library or looping yourself. "Simplicity" (for go maintainers).
Post reply on HN