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

231–240 of 262 posts

Re: NilAway: Practical nil panic detection for Go

#231

Post by usrbinbash »

ec9ca3928a6b1db wrote: post #228
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…

As someone who is ~3 months out of uni, I don't really understand this amount of concern towards "new hires". I've interned at a place where I was thrown head-first into a industrial-grade Java codebase. The initial few weeks were rough. There were complex class hierarchies, patterns that weren't documented but had to be followed, interfaces from 10 different packages, really hard to grok names, magical DI, Lombok, c…

> There were complex class hierarchies, patterns that weren't documented but had to be followed, interfaces from 10 different packages, really hard to grok names, magical DI, Lombok, complex mock testing all while 10 different linters and code coverage tools yell at you.

And this is exactly what Go avoids, in my opinion and experience.

Unless someone shoehorns Go into an Enterprise Java style (which, sadly, is possible, and sometimes done), the problems you listed with the Java codebase either don't exist in Go, or are orders of magnitude less painful to deal with, even in large Go codebases. Plus, the toolchain is pretty obvious, because most of it ships with the language.

And while my argument mentions new hires specifically, because the impact is most visible with them, this is just as important for mid and senior level developers; yes Go is sometimes more verbose (although enterprise Java and lots of C++ code still runs circles around Go in that regard) than it's contemporaries, it is also obvious. There is little magic, there is little action at a distance, and the opinionated style of the language discourages superfluos abstractions.

I have used quite a few languages so far in my career. Go is the first where I was able to comfortably read and understand std library code within the first week of learning the language.

> Just off the top of my head, for-loop semantics [which to Golang's credit, is being fixed but it is absolutely a breaking change],

It is technically a breaking change. Practically, it isn't, because there simply are no examples of production code in the wild that rely on this unintuitive behavior (As mentioned multiple times in the discussion on Go's issue tracker, the dev team did their research on that), and code that implements the (very easy) fix, will continue to work after the upcoming change.

> Nothing about Golang gives me that confidence.

My experience is different. I know that most of the problems the Rust compiler complains about will be handled by the fact that Go is GC'ed, and most of the rest I avoid by relying on CSP as my concurrency model (Can't accidentially copy a mutex if there's no mutex ;-) )

Re: NilAway: Practical nil panic detection for Go

#232

Post by maccard »

xyzzy_plugh wrote: post #206
stouset wrote: post #203

Earlier quoted context omitted.

The simple existence of the Billion Dollar Mistake of nils would suggest that maybe Rob Pike et al are capable of getting it wrong. > Much of the language design was motivated by learnings within Google. And the main problem Google had at the time was a large pool of bright but green CS graduates who needed to be kept busy without breaking anything important until the mcompany needed to tap into that pool for a bigge…

I doubt we can have a productive debate here as you're harping on issues I didn't even reference. Compared to peers, the language is stable, is readable and maintainable, full stop. - The language has barely changed since inception - most if not all behavior is localized and explicit meaning changes can be made in isolation nearly anywhere with confidence without understanding the whole - localized behavior means rea…

> Go feels like a massive step in the right direction

I agree. Go has it's warts, but given the choice between using net/http in go, tomcat in java, or cpprestsdk in c++, I'll pick Go any day.

In practice: - The toolchain is self contained, meaning install instructions don't start with "ensure you remove all traces of possibly conflicting toolchains" - it entirely removes a class of discussion of "opinion" on style. Tabs or spaces? Import ordering? Alignment? Doesn't matter, use go fmt. It's built into the toolchain, everyone has it. Might it be slightly more optimal to do X? Sure, but there's no discussion here.

- it hits that sweet spot between python and C - compilation is wicked fast, little to no app startup time, and runtime is closer to C than it is to python.

- interfaces are great and allow for extensions of library types.

- it's readable, not overly terse. Compared to rust, e.g. [0], anyone who has any programming experience can probably figure out most of the syntax.

We've got a few internal services and things in Go,vanr we use them for onboarding. Most of my team have had PR's merged with bugfixes on their first day of work, even with no previous go experience. It lets us care about business logic from the get go.

[0] https://github.com/getsentry/symbolicator/blob/master/crates...

Re: NilAway: Practical nil panic detection for Go

#233

Post by maccard »

leftyspook wrote: post #141
maccard wrote: post #129

Earlier quoted context omitted.

I write a decent amount of go - this isn't a defence of the current situation. > All of my code will need to special case this, what a disaster. No, your code should handle the error state first and treat the value as invalid up until that point, e.g. foo, err := getVal() if err != nil { return } // foo can only be used now It's infuriating that there's no compiler support to make this easier, but c'est la vie.

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 go service is cloned, built, tested and deployed in under 5 minutes.

Re: NilAway: Practical nil panic detection for Go

#234

Post by usrbinbash »

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…

> 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 programming language design over the last N decades". And they will still be in the same low-single-percentage-points of overall code produced as their predecessors, waiting for their turn to vanish into obscurity when the next-next-next-next iteration of that principle comes along.

And here is why:

Simple tools don't prevent good engineering, and complex tools don't ensure it. There are arcs that were built in ancient Rome, that are still standing TODAY. There are buildings built 10 years ago that are already crumbling.

Re: NilAway: Practical nil panic detection for Go

#235

Post by aatd86 »

stouset wrote: post #208
Kamq wrote: post #193

Earlier quoted context omitted.

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

Making an analogy between a car with a bowling alley being as useful as having the ability to know you have a valid selection from a list of choices does not exactly reflect well on your priorities.

It's not optimal but one can still implement enums in userland using struct and methods returning a comparable unexported type.

Re: NilAway: Practical nil panic detection for Go

#236

Post by verletx64 »

Conscat wrote: post #107
tuetuopay wrote: post #69

Earlier quoted context omitted.

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?

I think that it’s not just about something being possible with a tool, but people actually using it.

Go, for whatever reasons, has gotten people using it.

Re: NilAway: Practical nil panic detection for Go

#237

Post by Kamq »

stouset wrote: post #208
Kamq wrote: post #193

Earlier quoted context omitted.

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

Making an analogy between a car with a bowling alley being as useful as having the ability to know you have a valid selection from a list of choices does not exactly reflect well on your priorities.

I take it you use enums fairly regularly?

I don't really use them that much, so they're superfluous for the most part. Sort of like a car having a bowling alley. I mean, I'll take them if it doesn't complicate the language or impact compile time, but if they're doing to do either of those, I'd rather just leave them.

Adding default branches into the couple of switch statements and a couple spots for custom json parsing that return errors for values outside the set doesn't seem like a bad tradeoff.

Re: NilAway: Practical nil panic detection for Go

#238

Post by Kamq »

the_gipsy wrote: post #216
Kamq wrote: post #193

Earlier quoted context omitted.

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

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, tops. So that seems like a better analogy to me.

edit: I guess I should bring up that I don't use go's switch statement much either, and when I do, 99% of the time I'm using the naked switch as more of an analog to lisp's cond clause.

Re: NilAway: Practical nil panic detection for Go

#239

Post by the_gipsy »

Kamq wrote: post #238
the_gipsy wrote: post #216

Earlier quoted context omitted.

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.

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.

Re: NilAway: Practical nil panic detection for Go

#240

Post by ParetoOptimal »

Kamq wrote: post #238
the_gipsy wrote: post #216

Earlier quoted context omitted.

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.

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

Post reply on HN