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

241–250 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#241

Post by bruh2 »

cedws wrote: post #122
fizx wrote: post #93

Earlier quoted context omitted.

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.

What does PLT mean in this context? I wasn't able to $searchengine it

Re: NilAway: Practical nil panic detection for Go

#242

Post by thwora23__ »

usrbinbash wrote: post #220
tw061023 wrote: post #174

Earlier quoted context omitted.

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…

Here you go: https://www.youtube.com/watch?v=uwajp0g-bY4

I think Go could still work without completely neutering the type system.

Algebraic Data Types and pattern matching are not difficult... python already has them.

Re: NilAway: Practical nil panic detection for Go

#243

Post by xyzzy_plugh »

Seb-C wrote: post #209
xyzzy_plugh wrote: post #207

Earlier quoted context omitted.

What toxicity? This doesn't track for me. > backward compatibility won't be broken. I'm not sure what your point is anymore. You are clearly divested. Your assessment is totally unfounded. What are you trying to accomplish here?

Personal attacks are not welcome and against HN guidelines. You can disagree with me and criticize my points, but I do not feel like it's done in a good faith or is leading to anything constructive. So I'm going to stop the discussion here and let the readers judge by themselves what I meant, and what to conclude about it.

I mean no ill intent, I genuinely have no idea what you're arguing towards. You repeatedly claim dogma and even toxicity (!) where I can find no evidence of either -- that certainly doesn't feel like good faith to me. It feels like FUD.

Re: NilAway: Practical nil panic detection for Go

#244

Post by tome »

usrbinbash wrote: post #222
munchler wrote: post #117

Earlier quoted context omitted.

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…

> And how well did that work out for Haskell?

You know this post is speculative fiction, right? It's actually about what could kill Haskell, not what could kill Rust?

Re: NilAway: Practical nil panic detection for Go

#245

Post by [deleted] »

maccard wrote: post #233
leftyspook wrote: post #141

Earlier quoted context omitted.

Man, if only over 30 odd years of PL research leading up to Go, somebody came up with a way to do it better.

Given the choice between a (objectively) theoretically superior language like Haskell or Rust , and a language that prioritises developer ergonomics at the expense of PL research, I'll take the ergonomics thanks. We have a 1MM line c++ codebase at work, a rust third party dependency, and a go service that's about as big as the rust dependency. Building the Rust app takes almost as long as the c++ app. Meanwhile, our…

[deleted]

Re: NilAway: Practical nil panic detection for Go

#246

Post by mcronce »

maccard wrote: post #233
leftyspook wrote: post #141

Earlier quoted context omitted.

Man, if only over 30 odd years of PL research leading up to Go, somebody came up with a way to do it better.

Given the choice between a (objectively) theoretically superior language like Haskell or Rust , and a language that prioritises developer ergonomics at the expense of PL research, I'll take the ergonomics thanks. We have a 1MM line c++ codebase at work, a rust third party dependency, and a go service that's about as big as the rust dependency. Building the Rust app takes almost as long as the c++ app. Meanwhile, our…

Other than compiling a bit faster, what ergonomics does Go give you that Rust doesn't?

Re: NilAway: Practical nil panic detection for Go

#247

Post by stouset »

usrbinbash wrote: post #234
stouset wrote: post #181

Earlier quoted context omitted.

> And yet it's a productive language with significant adoption, go figure. Perl was also a successful language with significant adoption. At least back then, we didn’t know any better. In twenty years the industry will look back on golang as an avoidable mistake that hampered software development from maturing into an actual engineering discipline, for the false economy of making novice programmers quickly productive…

> In twenty years the industry will look back on golang as an avoidable mistake And here is my opinion: I think in 20 years, Go will still be a mainstream language. As will C and Python. As will Javascript, god help us all. And while all these languages will still be very much workhorses of the industry, we will have the next-next-next iteration of "Languages that incorporate all that we have learned about programmin…

> I think in 20 years, Go will still be a mainstream language. As will C and Python. As will Javascript, god help us all.

And yet the mainstream consensus is that C and JavaScript are terrible languages with deep design flaws. These weren’t as obvious pr avoidable at the time, but they’re realities we live with because they’re entrenched.

My assertion is that in twenty years, we’ll still be stuck with go but the honeymoon will be over and its proponents will finally be able to honestly accept and discuss its design flaws. Further, we’ll for the most part collectively accept that—unlike C and JavaScript—the worst of these flaws were own goals that could have and should have been avoided at the time. I further assert that there will never be another mainstream statically-typed language that makes the mistake of nil.

For that matter I think we’ll be stuck with Rust too. But I think the consensus will be that its flaws were a result of its programming model being somewhat novel and that it was a necessary step towards even better things, rather than a complete misstep.

Re: NilAway: Practical nil panic detection for Go

#248

Post by cedws »

bruh2 wrote: post #241
cedws wrote: post #122

Earlier quoted context omitted.

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.

What does PLT mean in this context? I wasn't able to $searchengine it

Programming Language Theory

Re: NilAway: Practical nil panic detection for Go

#249

Post by Kamq »

ParetoOptimal wrote: post #240
Kamq wrote: post #238

Earlier quoted context omitted.

I think that's a bad analogy because I actually use ABS and TC. I don't really use an enum heavy style of programming. Maybe twice per project or so. Putting a default branch in a couple switch statements also seems to get me back the same safety (although I'd rather detect the error early and return it in a custom UnmarshalJSON method for the type). I also imagine I'd use a bowling alley in my car ~2 times per year,…

> I think that's a bad analogy because I actually use ABS and TC. I don't really use an enum heavy style of programming. The point the others are making is you are using a less safe type of programming equivalent to driving without ABS and TC. From your point of view, "TC and ABS is useful so I use it unlike enums". From their point of view though, you are the person not using ABS and TC insisting that they offer not…

To continue the analogy, since I don't use enums, I'm also the person who isn't driving the car.

Can you explain how owning a car without ABS and not driving it is less safe?

Edit: Wait, or am I not using breaks? I think the analogy changed slightly during this whole process.

Re: NilAway: Practical nil panic detection for Go

#250

Post by Kamq »

the_gipsy wrote: post #239
Kamq wrote: post #238

Earlier quoted context omitted.

I think that's a bad analogy because I actually use ABS and TC. I don't really use an enum heavy style of programming. Maybe twice per project or so. Putting a default branch in a couple switch statements also seems to get me back the same safety (although I'd rather detect the error early and return it in a custom UnmarshalJSON method for the type). I also imagine I'd use a bowling alley in my car ~2 times per year,…

There are still people that swear that they can brake better than ABS. Until they do a side-by-side test. Re: custom UnmarshalJson implementation - you still have to remember, and do it for every serialized format (e.g. sql). A default case in a switch only solves, well, switching. If a rogue value comes in, it will go out somewhere. E.g. json to sql or whatever things are moving.

> A default case in a switch only solves, well, switching. If a rogue value comes in, it will go out somewhere. E.g. json to sql or whatever things are moving.

I mean, yeah, but eventually you have to do something with it. And the only useful thing you can really do with an enum is switch on it...

Post reply on HN