go-nil-why

anno scorsodiscuss

The intention of the password entry dots isn’t to prevent folks with unrestricted physical access to the machine from exfiltrating information, it’s to stop it from appearing in screenshares and casual “over the shoulder” observations.

Honestly I’m surprised they even acknowledged that as a bug, given there are many ways to get a whole lot more info than what you demonstrated, for instance the builtin “eye” button that is purpose built to reveal the full password to anyone with physical access to the machine wishing to see it.

go-nil-why

anno scorsodiscuss

> i don't see many new, small trucks

Right, because the EPA has made them illegal in favor of larger, less fuel efficient trucks. This paper covers the topic well^, you can also see many examples searching online for “EPA Small Truck Footprint”.

^ https://meche.engineering.cmu.edu/_files/images/research-gro...

go-nil-why

anno scorsodiscuss

No, and even if it were to happen car manufacturers can’t make 4+ year plans based on policies the next bonehead in chief might just revert.

We need a mass popular movement to dismantle the EPA as they stand and rebuild them with an actual purpose.

go-nil-why

anno scorsodiscuss

Issue is that isn’t generated by protoc.

Looking at the go ecosystem you’d think static nil traceability is some sort of Very Hard Problem…

go-nil-why

anno scorsodiscuss

We’ll need to fire all the industry plants in the EPA before we can legally have a small (fuel efficient) truck here in US. Our emissions laws were written by Big Truck.

go-nil-why

anno scorsodiscuss

Clearly, we don’t work at the same company.

What I claimed applied to my company, exactly as I said.

If it doesn’t apply to yours… ok? Congrats?

Looking back, maybe you didn’t understand the shell variable syntax?

go-nil-why

anno scorsodiscuss

No… I’m sorry I don’t have time to explain TS now. But that’s not what’s happening at all. What you’re proposing would be the equivalent of ‘var foo = new Foo()’. The default value in TS is undefined, which behaves generally isomorphically to nil.

go-nil-why

anno scorsodiscuss

There is no practical difference between

    function useFoo(f: Foo) { f.Use() }
    var foo: Foo
    useFoo(foo)

and

    func useFoo(f *Foo) { f.Use() }
    var foo *Foo
    useFoo(foo)

in this context. References vs pointers are equivalent here.

go-nil-why

anno scorsodiscuss

The issue isn’t the services that stay up forever, it’s the ones subject to a huge amount of churn where maintainers lose context on what is or isn’t possibly nil, and get loose with their checks.

Edit, responded to pointer vs reference down thread.

go-nil-why

anno scorsodiscuss

The fact that Go is considered a “modern” language and nil pointer exceptions are downright common blows my mind every day. Is there a static checker config that folks use to reduce this risk? Because coming from a TS background it’s legitimately bizarre to me that at $COMP insufficient nil pointer checking regularly causes major production outages.

comments