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

211–220 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#211

Post by masklinn »

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

That is dishonest.

Implicitly shared memory is literally the default behaviour of the langage, and you have to be careful to keep that controlled or contained.

Pretty much as in every other shared memory concurrency langage.

The quip about sharing memory by communicating is cute but it’s just that, the langage does not encourage let alone enforce it.

In fact it went out of its way to remove some opportunities e.g. because `go` is a statement there is no handle which could communicate the termination and result of routines.

Re: NilAway: Practical nil panic detection for Go

#212

Post by wg0 »

dkarras wrote: post #151
vore wrote: post #108

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

Microsoft Word is no small software. It's probably around 10 million lines of code.

As for "per locality business rules differ that's why so many lines of code.." seems like you can have a policy engine+DSL (JSON or YAML or custom policy language and engine) thus your code base shouldn't balloon to almost 100 million limes of code...

Re: NilAway: Practical nil panic detection for Go

#213

Post by foldr »

eviks wrote: post #196
foldr wrote: post #77

Earlier quoted context omitted.

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.

My basis is the %, not the simple fact that it has irrelevant instances. So let me charitably ask directly: have you looked through all the examples at least on the first couple of pages? And if you have, what % of instances is relevant to your point?

I think this is covered in my reply to shakow. Unless Rust is absolutely riddled with bugs, it’s obviously going to be hard to find uses of unwrap that are definitely bad. The point is that there’s no way to easily assure yourself that all the uses of unwrap are definitely good.

It would be similarly difficult to trawl through the source of the Go compiler and find definitely bad instances of pointer dereferencing. So does that mean that it’s not actually a problem in Go either?

Re: NilAway: Practical nil panic detection for Go

#214

Post by the_gipsy »

Kamq wrote: post #177
unrealhoang wrote: post #138

Earlier quoted context omitted.

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

type Gender int const ( Unspecified Gender = iota Male Female Other ) Works the same way. Declaring an empty variable of the type Gender (var x Gender) results in unspecified.

But it does not work. It looks like it would, with the indentation and iota keyword, but its just some variables that do not constrain the type. There will be incoming rogue values, from json or sql or something else.

    var g Gender // ok so far.
    if err := json.Unmarshal("99", &g); err != nil { panic(err) }
    // no error and g is Gender(99)!
Now you must validate, remember to validate, and do it in a thousand little steps in a thousand places.

Go is simple and gets you going fast... but later makes you stop and go back too much.

Re: NilAway: Practical nil panic detection for Go

#215

Post by pjmlp »

65a wrote: post #172
madeofpalk wrote: post #136

Earlier quoted context omitted.

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

I agree I probably should have said strongly typed instead of safe, as yes, if you dereference a pointer to nil you are going to crash. That being said, I do think "possesses an untyped nil" is a pretty far cry from "not type checked at all". It's certainly much safer than languages like C or C++ which allow type punning, or Java, where both nullables and runtime exceptions associated with types are generally a more…

Also possible in Go via unsafe.

Re: NilAway: Practical nil panic detection for Go

#216

Post by the_gipsy »

Kamq wrote: post #193
stouset wrote: post #179

Earlier quoted context omitted.

…and now you need to check for nonsense values everywhere, instead of ever being able to know through the type system that you have a meaningful value. It’s nil pointers all over again, but for your non-pointer types too! Default zero values are yet another own goal that ought to have been thrown away at the design stage.

> instead of ever being able to know through the type system that you have a meaningful value. That's... not what I'm looking for out of my type system. I'm mostly looking for autocomplete and possibly better perf because the compiler has size information. I really hate having to be a type astronaut when I work in scala. So, I mean, valid point. And I do cede that point. But it's kind of like telling me that my car d…

More like a car without ABS and no TC. It's cheaper and you can drive just more carefully, but you're more likely to crash.

Re: NilAway: Practical nil panic detection for Go

#217

Post by thiht »

adtac wrote: post #50

I'm not sure if that was the best example to showcase NilAway. I understand there's a lot of context omitted to focus on NilAway's impact, but why is foo returning a channel to bar if bar is just going to block on it anyway? Why not just return a *U? If foo's function signature was func foo() (*U, error) {}, this wouldn't be a problem to begin with.

Not the point.

Re: NilAway: Practical nil panic detection for Go

#218

Post by richbell »

rjh29 wrote: post #202
insanitybit wrote: post #19

Earlier quoted context omitted.

> And judging by the absolute success Go has (measured by contributions to Github), many many many many many developers agree with me on this. Yeah, I truly hate this field

PHP was once an extremely popular language too...

Famously something you could learn in a weekend. It allowed you to start being productive right away, even if you were writing terrible insecure code!

Re: NilAway: Practical nil panic detection for Go

#219

Post by richbell »

xyzzy_plugh wrote: post #199
eviks wrote: 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…

> ...languages which do not have a reputation of being stable, easy to learn, easy to read and understand, compile quickly, etc.

Kotlin is definitely the odd man out in that list.

Re: NilAway: Practical nil panic detection for Go

#220

Post by usrbinbash »

tw061023 wrote: post #174
danenania wrote: post #70

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…

The argument is that Go is making a _wrong_ set of trade-offs. It was designed, specifically, as per Rob Pike, for _bad_ developers. Developers who couldn't be productive at Google because they weren't properly taught at unis [0]. Then it caught momentum and then here we are, discussing a bad language designed for bad developers as if there is nothing better we can do with our lives. [0] https://news.ycombinator.com/…

> It was designed, specifically, as per Rob Pike, for _bad_ developers.

Mind showing us the source for that?

Go wasn't made for incompetent developers. I'm fairly certain that people who land a job as devs at Google are pretty competent.

Go was made to facilitate rapid onboarding, easy digestion of large codebases, and working efficiently in large teams where people are guaranteed to have widely different educational backgrounds, experiences and ideas about programming.

That's why the language has to be simple, obvious, and be focused on readability. That's also why Go is strongly opinionated.

Post reply on HN