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

51–60 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#51

Post by foldr »

mariopt wrote: post #24
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%...

Rust is a lot better in this aspect, but this is a symptom of not having proper code review and standards. Do not forget that in some scenarios using unwrap is totally fine if a panic is acceptable. The same could be said for javascript: How many time have we not wrapped JSON.parse inside a try catch? More than we would like to admit. Really appreciate Rust “forces” you to handles all execution paths.

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

Re: NilAway: Practical nil panic detection for Go

#52

Post by foldr »

insanitybit wrote: post #20
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%...

You can `grep unwrap` for Rust, you need an entire SAT solver for Go.

That's almost literally what I just did, but what use is it? No-one is really going to go through all those unwrap calls and check them.

Re: NilAway: Practical nil panic detection for Go

#53

Post by usrbinbash »

nicoburns wrote: post #46
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 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 achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupéry, Airman's Odyssey

Re: NilAway: Practical nil panic detection for Go

#54

Post by tialaramex »

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

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 Undefined Behaviour, game over, you lose". If you race e.g. a simple integer counter, it's damaged and you ought not to use it because it might be anything now, but Go isn't reduced to Undefined Behaviour immediately for this seemingly trivial mishap (whereas C and C++ are)

Re: NilAway: Practical nil panic detection for Go

#55

Post by nicoburns »

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…

Not at all. Otherwise brainfuck would be the simplest language to learn. How do you currently represent a type that is A or B in Go? You have to use an interface. That’s much more complex than using a sum type would be.

Re: NilAway: Practical nil panic detection for Go

#56

Post by ndreas »

usrbinbash wrote: post #17
tuetuopay wrote: post #8

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…

This is the core of the problem. Of course you can learn the language in a weekend, but you're bound to make the same mistakes developers have been doing for decades.

This may be ok, as you say, if you allow errors here and there because you are fine dealing with those problems. But at the other end, it may be a user that is affected by the error. Which may be ok as well, but why should it be? We lament the quality of software all the time.

Compare this to other engineering fields: unless you study the knowledge of those who came before you may not even be allowed to practice in the field. I would not want to use a bridge built by someone who learned bridge building in a weekend.

Software is different though, it's rarely a matter of life or death. Given that, maybe it's ok to not have the highest quality in mind, because the benefit of productivity far outweighs the alternative.

I'm torn.

Re: NilAway: Practical nil panic detection for Go

#57

Post by usrbinbash »

richbell wrote: post #49
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…

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

> This is a false dichotomy. One does not imply the other.

No it isn't, and yes it does. By definition, the more features I add to something, the more complex it becomes. So yes, Go achieves it's simplicity precisely by leaving out features.

> this great list of issues

I just picked three examples at random:

"Sending to an Unbuffered Channel Returns As Soon As the Target Receiver Is Ready"

"Send and receive operations on a nil channel block forver."

"Many languages have increment and decrement operators. Unlike other languages, Go doesn't support the prefix version of the operations."

All of these are behavior and operators that are documented in the language spec. So how is any of these a "footgun"?

Re: NilAway: Practical nil panic detection for Go

#58

Post by foobiekr »

vrosas wrote: post #28
npalli wrote: post #18

"The Go monorepo is the largest codebase at Uber, comprising 90 million lines of code (and growing)" Is this just a symptom of having a lot of engineers and they keep churning code, Golang being verbose or something else. Hard time wrapping my head around Uber needing 90+ million lines of code(!). What would be some large components of this codebase look like?

Uber is famous for NIH syndrome. You can tell by their open source projects they've basically built every part of their infra from scratch. So it's not just the application code but everything else that helps run it.

Basically exactly this. Also, a lot of their "in production" open source projects are not "in production" but were generated and released as part of their broken promotion process.

Re: NilAway: Practical nil panic detection for Go

#59

Post by eviks »

usrbinbash wrote: post #17
tuetuopay wrote: post #8

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…

> And judging by the absolute success Go has (measured by contributions to Github), many many many many many developers agree with me on this

You can't make up that other devs' opinions / preferences are identical to yours just because they use the same language, there are other important factors in play (e.g., if your company is using Go, then you'd be more productive in it and be more likely to choose to contribute in it even it Go is less productive as a language)

Post reply on HN