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

101–110 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#101

Post by yencabulator »

tialaramex wrote: post #54
masklinn wrote: post #34

Earlier quoted context omitted.

> Can this actually manifest? Yes. Per rsc ( https://research.swtch.com/gorace ) > In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program. That races undermine memory safety in go has been used in CTFs: https:…

It's interesting that the 2010 article you linked suggests they might consider improving this but nope, Go 1.0 and the Go people use today just basically takes the same attitude as C and C++ albeit with a small nuance. In C and C++ SC/DRF (Sequentially Consistent if Data Race Free) turns into "All data races are Undefined Behaviour, game over, you lose". In Go SC/DRF turns into "All data races on complex types are Un…

Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to, but once you corrupt the map data structure, weird things can happen. Trying to contain that explosion isn't necessarily "better", as it would make maps slower / take up more memory / etc.

Re: NilAway: Practical nil panic detection for Go

#102

Post by pjmlp »

usrbinbash wrote: post #53
nicoburns wrote: post #46

Earlier quoted context omitted.

It could have done both though. It could have explicitly nullable types like Kotlin/C#. Or sum types like zig/rust/Swift. That wouldn’t make the language more complex to learn.

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.

Re: NilAway: Practical nil panic detection for Go

#103

Post by foldr »

shakow wrote: post #86
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.

Then please pinpoint some problematic ones, so that not every reader has to delve into pages to continue the discussion.

The point is precisely that it's not always easy to figure out which instances are problematic.

If you think about it a bit, given that bugs are relatively rare in a mature project, it's going to be difficult to find a use of unwrap that's definitely bad.

Re: NilAway: Practical nil panic detection for Go

#105

Post by tehjoker »

pjmlp wrote: post #100
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

There are several language design problems solved in the 20th century that Go designers decided to ignore, because they require PhD level skills to master, apparently. Hence why the language is full of gotchas like these. Had it not been for Docker and Kubernetes success, and most likely it wouldn't have gotten thus far.

speaking from personal experience, i selected go for a project because it is high perf, automatically uses all cores w/ goroutines, and is type checked

Re: NilAway: Practical nil panic detection for Go

#106

Post by vore »

masklinn wrote: post #34
mutatio wrote: post #14

Earlier quoted context omitted.

Can this actually manifest? Even without the -race flag I think maps are a special case which will panic with a concurrent mutation error if access isn't synchronized.

> Can this actually manifest? Yes. Per rsc ( https://research.swtch.com/gorace ) > In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program. That races undermine memory safety in go has been used in CTFs: https:…

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

Re: NilAway: Practical nil panic detection for Go

#107

Post by Conscat »

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 pioneered a concurrency model and made it available to the masses

Isn't it basically just what Cilk did, but with fewer feaures?

Re: NilAway: Practical nil panic detection for Go

#109

Post by bb88 »

pjmlp wrote: post #100
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

There are several language design problems solved in the 20th century that Go designers decided to ignore, because they require PhD level skills to master, apparently. Hence why the language is full of gotchas like these. Had it not been for Docker and Kubernetes success, and most likely it wouldn't have gotten thus far.

And now they're stuck, since they doubled down on not making any language changes for the 2.0 release.

They made the language easier and quicker to write a compiler, but harder to write programs in, and it doesn't look like that will change in Go 2.0.

Re: NilAway: Practical nil panic detection for Go

#110

Post by pjmlp »

bb88 wrote: post #109
pjmlp wrote: post #100

Earlier quoted context omitted.

There are several language design problems solved in the 20th century that Go designers decided to ignore, because they require PhD level skills to master, apparently. Hence why the language is full of gotchas like these. Had it not been for Docker and Kubernetes success, and most likely it wouldn't have gotten thus far.

And now they're stuck, since they doubled down on not making any language changes for the 2.0 release. They made the language easier and quicker to write a compiler, but harder to write programs in, and it doesn't look like that will change in Go 2.0.

At least many CNCF projects are now adopting Rust, Java, C# and even to a lesser extent C++.
Post reply on HN