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

181–190 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#181

Post by stouset »

pstuart wrote: post #166
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.

And yet it's a productive language with significant adoption, go figure. They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people. The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.

> 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. I’m willing to put money on that belief, given sufficiently agreed upon definitions.

Re: NilAway: Practical nil panic detection for Go

#182

Post by yesiamyourdad »

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…

I honestly have started to wonder if the popularity of languages like Go and JavaScript are due to the lack of features in the base language. JavaScript in particular has had an incredible amount of effort invested in creating fairly limited, scattershot, and duplicative support for features that are "just part of the language" in Kotlin, or Rust, or even Java. It makes a really rich field for people who are interested in compilers, but did all this really make Uber a better company? Would all that effort have been better spent solving problems core to their business?

At my employer we have a pattern of promoting people who have done things like write a proprietary application gateway. The dev got a couple promotions and moved on to another company and we got stuck maintaining a proprietary application gateway with a terribly messy configuration and poor observability.

Re: NilAway: Practical nil panic detection for Go

#184

Post by Seb-C »

I have been thinking about this problem for a long time as well.

But I think that focusing on nils is a wrong analysis. The problem is the default zero-values dogma, and that is not going to change anytime soon.

Sometimes you also need a legitimate empty string or 0 integer, but the language cannot distinguish it from the absence of value.

In my codebase, I was able to improve the readability of those cases a lot by using mo.Option, but that has a readability cost and does not offer the same guarantees than a compiler would. The positive side is that I get a panic and clear stack trace whenever I try to read an absent value, which is better than nothing, but still not as good as having those cases at compile time.

No amount of lint checkers (however smart) will workaround the fact that the language cannot currently express those constraints. And I don't see it evolving past it's current dogmas unfortunately, unless someone forks it or create something like typescript for go.

Re: NilAway: Practical nil panic detection for Go

#185

Post by xyzzy_plugh »

Seb-C wrote: post #184

I have been thinking about this problem for a long time as well. But I think that focusing on nils is a wrong analysis. The problem is the default zero-values dogma, and that is not going to change anytime soon. Sometimes you also need a legitimate empty string or 0 integer, but the language cannot distinguish it from the absence of value. In my codebase, I was able to improve the readability of those cases a lot by…

It's not a dogma it's a breaking change to the language. Removing default zero-values is effectively a different language. Literally none of my code over the past several years (which otherwise all still works perfectly as-is) would work.

The Go team is very careful to avoid breaking changes (cue all the usual Well Actually comments regarding breaking changes that affected exactly zero code bases) and rightfully so. Their reputation as a stable foundation to build large projects upon has been key to the success and growth of the language and its ecosystem.

I have about a million and one other issues I'd like to see resolved first that don't involve breaking changes. It's a known pain point, the core maintainers acknowledge it, but suggestions to fundamentally derail the entire project are ludicrous.

Focusing on nils is fine. NilAway is fine. It's a perfectly reasonable approach and adds a lot of value. This solves a real problem in real code bases today. There is no universe wherein forking to create a new language creates remotely equivalent value.

Re: NilAway: Practical nil panic detection for Go

#187

Post by [deleted] »

Seb-C wrote: post #184

I have been thinking about this problem for a long time as well. But I think that focusing on nils is a wrong analysis. The problem is the default zero-values dogma, and that is not going to change anytime soon. Sometimes you also need a legitimate empty string or 0 integer, but the language cannot distinguish it from the absence of value. In my codebase, I was able to improve the readability of those cases a lot by…

[deleted]

Re: NilAway: Practical nil panic detection for Go

#188

Post by pstuart »

stouset wrote: post #181
pstuart wrote: post #166

Earlier quoted context omitted.

And yet it's a productive language with significant adoption, go figure. They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people. The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.

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

Perl had less competition and also suffered from being more of a "write-only" language.

Lisp, Haskell, OCaml all likely tickle your PL purity needs, but they remain niche languages in the grand scheme of things. Does that make them bad?

I think Go will be the new Java (hopefully without the boilerplate/bloat). It's good enough to do the job in a lot of cases and plenty of problems will be solved with it in a satisfactory manner.

Language wars are only fun to engage with for sport, but it's silly to get upset about them. Most languages have value in different contexts and I believe the real value in this dialog is recognizing when and where a language works and to accept one's preferred choice may not always be "the one".

Re: NilAway: Practical nil panic detection for Go

#189

Post by xyzzy_plugh »

stouset wrote: post #181
pstuart wrote: post #166

Earlier quoted context omitted.

And yet it's a productive language with significant adoption, go figure. They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people. The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.

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

I can't agree with the definitions you're insinuating. To suggest that the creators of Go do not know what the difference is between "writing software" and doing "software engineering" is plainly wrong. Much of the language design was motivated by learnings within Google. What other "modern" language that has more of a focus on software engineering, putting readability and maintainability and stability at the forefront? It's less about novice programmers and more about artificial barriers to entry.

Modern PLT and metaprogramming and more advanced type systems enable the creation of even more complex abstractions and concepts, which are even harder to understand or reason about, let alone maintain. This is the antithesis of whatever software engineering represents. Engineering is almost entirely about process. Wielding maximally expressive code is all science. You don't need to be a computer scientist to be a software engineer.

Re: NilAway: Practical nil panic detection for Go

#190

Post by [deleted] »

pstuart wrote: post #166
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.

And yet it's a productive language with significant adoption, go figure. They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people. The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.

[deleted]
Post reply on HN